Mã đầu tiên so với cơ sở dữ liệu đầu tiên

Khi tôi thiết kế và tạo phần mềm tôi làm việc, tôi thường thiết kế và tạo các bảng SQL back-end trước rồi sau đó chuyển sang lập trình thực tế. Dự án tôi đang làm đang khiến tôi rất bối rối. Điều này có lẽ là do thiếu các yêu cầu tốt, vững chắc, nhưng thật không may tôi có thể làm được điều đó vào lúc này. Đó là một tình huống "cứ làm đi", nhưng tôi lạc đề.

Tôi đang nghĩ đến việc lật dòng công việc của mình lên đầu và tạo ra các lớp mô hình dữ liệu và giao diện người dùng trước tiên với hy vọng rằng việc giải quyết nó sẽ cho tôi thấy rõ lược đồ cơ sở dữ liệu của tôi cuối cùng sẽ như thế nào. Đây có phải là một ý tưởng tốt? Tôi lo lắng rằng tôi sẽ kết thúc với một UI và vẫn không biết làm thế nào để cấu trúc db.

Nếu có ai tò mò, tôi đang sử dụng SQL Server làm phụ trợ và MS Access làm ứng dụng giao diện người dùng. (Truy cập không phải là lựa chọn của tôi hoặc ... vì vậy xin đừng ghét nó quá tệ.)

Điều gì đến đầu tiên, quá trình hoặc dữ liệu được sử dụng bởi quá trình đó? Tôi biết đây là một câu hỏi "con gà hay quả trứng", nhưng trong trường hợp phần mềm, tôi tin rằng đó là quá trình.

Chẳng hạn, bạn có thể tăng dần mô hình dữ liệu của mình bằng cách triển khai một trường hợp sử dụng duy nhất tại một thời điểm chỉ với sự kiên trì trong bộ nhớ (hoặc bất cứ điều gì dễ thực hiện). Khi bạn cảm thấy bạn đã triển khai đủ các trường hợp sử dụng để phác thảo các thực thể cơ bản, bạn có thể thay thế tính bền vững trong bộ nhớ bằng cơ sở dữ liệu thực, sau đó tiếp tục tinh chỉnh lược đồ khi bạn tiếp tục, mỗi trường hợp sử dụng một lần.

Điều này lấy trọng tâm ra khỏi cơ sở dữ liệu và chuyển nó vào cốt lõi của vấn đề: các quy tắc kinh doanh. Nếu bạn bắt đầu bằng cách thực hiện các quy tắc kinh doanh, cuối cùng bạn sẽ tìm thấy (theo một quy trình rất giống với Chọn lọc tự nhiên, nhân tiện), dữ liệu nào thực sự cần thiết cho doanh nghiệp. Nếu bạn bắt đầu bằng cách lập mô hình cơ sở dữ liệu, không có phản hồi về việc liệu dữ liệu đó có thực sự cần thiết (hoặc ở định dạng đó hoặc ở mức độ chuẩn hóa đó, v.v ...), bạn sẽ kết thúc nhiều điều chỉnh muộn trong lược đồ (có thể yêu cầu các thủ tục di chuyển nặng nề, nếu doanh nghiệp đang chạy với nó) hoặc bạn sẽ phải thực hiện "giải quyết công việc" trong các quy tắc kinh doanh để bù cho mô hình dữ liệu không phù hợp.

TL; DR: Cơ sở dữ liệu phụ thuộc vào doanh nghiệp - nó được xác định bởi họ. Bạn sẽ không cần dữ liệu trừ khi bạn có một quy trình hoạt động với dữ liệu đó (báo cáo cũng là một quy trình). Thực hiện quy trình trước và bạn sẽ tìm thấy dữ liệu nào cần. Mô hình hóa dữ liệu trước và bạn có thể đếm được có bao nhiêu giả định sai khi lần đầu tiên mô hình hóa nó.

Một chút ngoài chủ đề nhưng rất quan trọng: quy trình công việc tôi mô tả thường được sử dụng cùng với các thực tiễn rất quan trọng như "Điều đơn giản nhất có thể làm việc", phát triển dựa trên thử nghiệm và tập trung vào việc tách rời kiến ​​trúc của bạn khỏi các chi tiết theo cách của bạn (gợi ý: cơ sở dữ liệu). Về người cuối cùng, bài nói chuyện này tổng hợp ý tưởng khá tốt.

Một phân tích nguyên nhân gốc rễ cho thấy vấn đề này không phải là một trong những phương pháp, mà là thiếu một đặc tả. Không có ai, điều đó thực sự không quan trọng với những gì bạn viết trước - dù sao bạn cũng sẽ vứt nó đi.

Tự mình làm và phân tích một số hệ thống cơ bản - xác định một số người dùng ở nhiều cấp độ khác nhau, tạo một bảng câu hỏi nhanh và bẩn sau đó tắt máy, lấy một ít cà phê và bánh quy / bánh rán (hoặc bất cứ thứ gì bôi trơn bánh xe) sau đó đi bộ đến bàn của họ, hỏi họ những gì họ làm và những gì họ cần biết / ghi lại để thực hiện công việc của họ ngay cả khi điều đó có vẻ hiển nhiên - vẫn hỏi. Đừng lo lắng về việc họ quan trọng như thế nào, nếu họ quá bận rộn thì hãy sắp xếp để quay lại vào lúc khác hoặc để lại với họ.

Một khi bạn đã có điều đó, bạn sẽ có thể bắt đầu xây dựng bất cứ điều gì bạn nghĩ sẽ mang lại cho bạn kết quả tốt nhất và chờ phần còn lại của thông số kỹ thuật đi vào.

Kinh nghiệm của tôi là như sau:

• Trong hầu hết các dự án tôi đã làm việc, chúng tôi đã thiết kế cơ sở dữ liệu trước tiên.
• Thông thường dữ liệu đã tồn tại trong bảng tính, cơ sở dữ liệu cũ, giấy, v.v. Dữ liệu đó sẽ cho bạn gợi ý về các bảng bạn cần giữ.
• Thông thường, một quy trình đã được sử dụng, nhưng theo cách thủ công hoặc sử dụng một số công cụ khác nhau không được tự động hóa, không hoạt động liên tục và / hoặc không tuân thủ các tiêu chuẩn.
• Khi bạn có một mô hình cơ sở dữ liệu bán thành thục, bạn có thể bắt đầu thiết kế các biểu mẫu nguyên mẫu, cửa sổ, v.v., đọc và ghi vào cơ sở dữ liệu đó.
• Khi bạn tiếp tục, một số thay đổi sẽ là cần thiết để phù hợp với những thứ không được dự tính lúc đầu.

Cũng nhớ:

• Nó không còn là thế giới một ứng dụng <-> một cơ sở dữ liệu. Có thể ứng dụng của bạn sẽ phải đọc hoặc ghi dữ liệu từ nhiều cơ sở dữ liệu hoặc giải pháp của bạn sẽ bao gồm nhiều ứng dụng sử dụng cùng một cơ sở dữ liệu.

Kết luận: Tôi khuyên bạn nên thiết kế cơ sở dữ liệu trước.

Tôi sẽ nói Cơ sở dữ liệu Đầu tiên vì tôi có nhiều kinh nghiệm với các dự án lớn và bạn thực sự cần một mô hình dữ liệu vững chắc nếu bạn có nhiều nhà phát triển làm việc song song.

Nhưng sau đó tôi nghĩ về nó nhiều hơn một chút và tôi nhận ra rằng những gì chúng tôi đang thực sự làm cho các dự án lớn thành công hơn là "yêu cầu đầu tiên".

Một tập hợp tốt các yêu cầu kinh doanh được chỉ định tốt, dẫn đến một tập hợp tốt các yêu cầu chức năng. Nếu bạn có một tập hợp tốt các yêu cầu chức năng thì mô hình dữ liệu và thông số mô-đun sẽ rơi vào vị trí mà không cần nỗ lực nhiều.

Vì điều này có vẻ rất lỏng lẻo / không xác định, trước tiên tôi nên làm GUI giao diện - nghe có vẻ giống như những gì bạn cần để nhận được phản hồi, hỗ trợ, thời gian và phản hồi từ các bên liên quan, phải không? Họ không quan tâm đến các bảng được chuẩn hóa tuyệt vời của bạn và các ràng buộc khóa ngoài và xóa tầng. Nhưng một GUI tuyệt vời với nhiều màu sắc sáng bóng - tốt, đó là đỉnh cao!

Đối với "cơ sở dữ liệu" phụ trợ ban đầu, hãy sử dụng một cái gì đó cực kỳ đơn giản, có thể chỉ là các khóa / giá trị được lưu trữ vào một tệp. Tôi không quen với MS Access, vì vậy không biết phần phụ trợ "nhẹ nhất" sẽ là gì. (một cái bàn trải rộng?) Bất cứ điều gì nhanh chóng và bẩn thỉu, hãy lên kế hoạch vứt nó đi.

Nếu bạn có thể, hãy sử dụng giao diện hài hước trong GUI để làm rõ rằng đó là nguyên mẫu. Nếu vẫn thất bại, sử dụng thẻ chỉ mục.

Bây giờ, có thể các bên liên quan của bạn là các chuyên gia DB - đôi khi đó là trường hợp của tôi! - trong trường hợp đó, làm một số thiết kế DB.

Vì các yêu cầu không rõ ràng, người ta có thể bắt đầu với một mô hình dữ liệu rất thô sơ với các yếu tố chính bạn sẽ biết bạn cần, có thể chỉ cần các bảng và PK cơ bản để bắt đầu. Phần còn lại của dữ liệu, tuần tự hóa thành nhị phân hoặc XML và lưu trữ BLOB trong cơ sở dữ liệu để bắt đầu. Điều đó sẽ cho phép một người phát triển giao diện người dùng và lớp doanh nghiệp (tầng giữa) mà không cần mô hình quan hệ đầy đủ nhưng bạn vẫn sẽ kiên trì lưu và truy xuất và tra cứu khóa đơn giản khi cần.

Ví dụ, có thể bạn có một Người, vì vậy bạn có PK Id Người. Phần còn lại của các thuộc tính không được biết đến, vì vậy chỉ cần bắt đầu với bảng Person với PK Person Id và một cột khác sẽ lưu trữ Blob, tất cả dữ liệu về người.

Khi các yêu cầu được củng cố, hãy lấy Blobs của bạn và trích xuất tất cả các bảng và cột cần thiết và làm cho mô hình trở nên quan hệ. Sau đó, vấn đề chỉ là thay đổi tính bền bỉ từ BLOB sang quan hệ trong lớp truy cập dữ liệu. Nhưng mọi thứ khác, quy tắc kinh doanh UI vv vẫn sẽ hoạt động. Lưu ý, điều này thêm một chút thời gian cho dự án nhưng cho phép hoàn toàn linh hoạt để thêm và bỏ mọi thứ khi cần mà không thay đổi mô hình quan hệ cho đến khi mọi thứ trở nên vững chắc hơn

Việc tìm kiếm có thể bị trì hoãn vì bạn không thể truy vấn BLOB để mô hình ổn định, bắt đầu lưu trữ dữ liệu của bạn cần tìm kiếm trong các cột quan hệ.

Về cơ bản, bạn bắt đầu với một mô hình dạng bảng và chuyển sang mô hình quan hệ khi dự án tiến triển.

Hoặc, củng cố các yêu cầu trước khi bắt đầu bất kỳ công việc nào để có thể phát triển mô hình quan hệ ban đầu.

Nói chung tôi nghĩ rằng mã đến sau dữ liệu vì mã sẽ thao túng dữ liệu.

Nếu các yêu cầu không rõ ràng, bạn có thể tạo một mô hình dữ liệu về việc giải thích các yêu cầu của bạn. Tốt nhất có thể là viết ra một số yêu cầu và gửi nó cho chủ nhân của bạn, sau đó họ có một cái gì đó để bắn vào. Hoặc tạo một gui trước, nó phụ thuộc vào loại nhà tuyển dụng hoạt động tốt nhất :)