Ai thiết kế cơ sở dữ liệu trong phát triển web? [đóng cửa]

Trong bối cảnh phát triển web, ai thiết kế cơ sở dữ liệu? Mặc dù có rất nhiều thông tin liên quan đến nhà phát triển web back-end với xử lý phía máy chủ, mô hình hóa dữ liệu và tương tự, khía cạnh thiết kế cơ sở dữ liệu của phương trình dường như vắng mặt một cách bí ẩn.

Tôi không nói về việc ai thiết lập cơ sở dữ liệu vật lý, tôi đang đề cập đến ai là người thiết kế mô hình logic của cơ sở dữ liệu, thực hiện các cuộc phỏng vấn câu chuyện của người dùng để có được thông tin về những lĩnh vực nào là cần thiết, những thông số kỹ thuật của trường đó, v.v. .

Tôi đã nhận ra rằng thiết kế ( PROPER ) của cơ sở dữ liệu không phải là nhiệm vụ nhỏ (tôi đang đọc máy nhắn tin 672 này ) và có thể dễ dàng trở thành một nghề nghiệp. Tuy nhiên, việc tìm kiếm lên xuống internet đã dẫn đến kết quả nhỏ đáng ngạc nhiên cho những người được cho là sẽ xử lý công việc này trong bối cảnh của nhà phát triển web.

Câu hỏi của bạn không chỉ phù hợp với ứng dụng web, mà còn cho tất cả các loại ứng dụng sử dụng phụ trợ cơ sở dữ liệu.

Theo kinh nghiệm của tôi

• Thiết kế của cơ sở dữ liệu là công việc kết hợp của các nhà phát triển và DBA.
• Các nhà phát triển thực hiện các thiết kế cơ sở dữ liệu thô, hoặc thường rất tốt. Tất cả phụ thuộc vào kinh nghiệm của các lập trình viên.
• Thông thường các nhà phát triển tạo các bảng trong cơ sở dữ liệu phát triển của họ và một mô hình khái niệm được thiết kế ngược từ nó.
• Thông thường các sơ đồ ER khái niệm được thảo luận với các thành viên khác trong nhóm, thường là khách hàng. Trong giai đoạn này, các lỗi khái niệm rõ ràng được phát hiện và hy vọng tìm ra và sửa chữa.
• Công việc của DBA là xem xét một thiết kế như vậy và tinh chỉnh nó để phát hiện các vi phạm của các hình thức thông thường.
• Ngoài ra, DBA thi hành các quy ước đặt tên của bảng và cột
• Ngoài ra, DBA hình dung các tắc nghẽn hiệu suất có thể có và cố gắng hiểu làm thế nào dữ liệu sẽ được truy vấn để tạo các chỉ mục thích hợp sau này.
• Chu kỳ sửa đổi / kiểm tra / sửa lỗi giữa nhà phát triển / nhà thiết kế ứng dụng và các DBA trải qua nhiều lần lặp cho đến khi mô hình đủ trưởng thành để tạo ra một mô hình vật lý.
• Thông thường một công cụ thiết kế cơ sở dữ liệu được sử dụng trong tất cả các cơ sở dữ liệu rất nhỏ để giúp quá trình này.

Dòng dưới cùng:

• Các nhà phát triển biết lĩnh vực kinh doanh và vấn đề tốt hơn các DBA, vì vậy họ thực hiện hầu hết các thiết kế ban đầu và, tùy thuộc vào kinh nghiệm của nhà phát triển, một thiết kế như vậy có thể rất gần với thiết kế cuối cùng.
• Vai trò của DBA chủ yếu là đảm bảo NF, quy ước đặt tên, cân nhắc hiệu năng, sửa lỗi rõ ràng và cuối cùng là tạo mô hình vật lý, sau đó là tập lệnh cụ thể của cơ sở dữ liệu và chạy chúng để tạo cơ sở dữ liệu.
• Tôi muốn nói rằng đó là công việc phân tích yêu cầu và phát triển 80% và công việc DBA 20%.

CẬP NHẬT:

Có 3 loại DBA:

• các DBA phát triển biết mô hình hóa dữ liệu, là các chuyên gia SQL và có thể viết các thủ tục được lưu trữ, họ thường là các nhà phát triển trước đây;
• sản xuất các DBA chuyên cài đặt, điều chỉnh hiệu năng, sao lưu và khôi phục, v.v.
• và các DBA chuyên nghiệp đã làm tất cả những việc đó và như vậy có thể làm được hầu hết (chúng rất ít).

Hầu hết các DBA là các DBA sản xuất, điều này rất tốt vì họ là những người phục hồi cơ sở dữ liệu bị mất từ ​​các mảng đĩa bị lỗi trong nửa đêm. Nhưng họ không tham gia tích cực vào quá trình thiết kế.

Nó phụ thuộc vào cơ sở dữ liệu được sử dụng để làm gì.

Trong nhiều ứng dụng (ứng dụng web hay không), cơ sở dữ liệu được liên kết chặt chẽ với ứng dụng đó vì nó đóng vai trò là kho lưu trữ liên tục cho nó. Sau đó, cơ sở dữ liệu là một phần của ứng dụng, do đó được thiết kế cùng nhau (và bạn cho rằng không có chương trình nào khác có thể truy cập hoặc cập nhật đáng kể cơ sở dữ liệu đó). BTW, sự bền bỉ có thể đạt được bằng các phương tiện khác ngoài cơ sở dữ liệu, ví dụ: tệp văn bản thuần túy, tệp nhị phân (đáng chú ý là các tệp được gọi là GDBM ), kho git (hoặc các VCS khác), thư mục hoặc cây tệp, phân vùng đĩa thô, phần cứng chuyên dụng (ví dụ flash), hệ thống tập tin từ xa, điểm kiểm trakỹ thuật. Đối với các cơ sở dữ liệu được thiết kế cho và với một ứng dụng, bạn nên quan tâm đến các mẫu truy xuất & cập nhật chung và thiết kế lược đồ cơ sở dữ liệu (và lập chỉ mục!) Với chúng trong tâm trí.

Trong một số trường hợp, cơ sở dữ liệu tự nó là một tài sản chính và độc lập, và được thiết kế một ưu tiên để được sử dụng bởi một số ứng dụng khác nhau (và thậm chí cả những ứng dụng trong tương lai). Sau đó, nó nên được thiết kế độc lập (và cẩn thận hơn nhiều).

Cụ thể, một số ứng dụng web chỉ là giao diện web cho cơ sở dữ liệu hiện có.

Trong nhiều trường hợp (nghĩ về một số wiki làm ví dụ), dữ liệu quan trọng hơn và có giá trị hơn so với (các) ứng dụng sử dụng nó. Bạn có thể quan tâm làm thế nào để làm cho nó trở thành bằng chứng trong tương lai và có thể phát triển nó một cách dễ dàng (ví dụ: bằng cách sử dụng hoặc xác định các định dạng văn bản và đa năng - được chuẩn hóa và định dạng tài liệu để sao lưu và khôi phục nó).

Tôi đã nhận ra rằng thiết kế (PROPER) của cơ sở dữ liệu không phải là nhiệm vụ nhỏ ...

Đọc thêm về NoQuery , cơ sở dữ liệu định hướng tài liệu , cơ sở dữ liệu khóa giá trị , quản lý kiến thức , trình bày kiến ​​thức và lý luận , bản thể luận , hệ thống chuyên gia , phương pháp tiếp cận quy tắc kinh doanh , ERP , CMS . Có lẽ cân nhắc sử dụng REDIS , MongoDB , v.v.