Tầm quan trọng của sơ đồ ER

Tôi là một sinh viên và tôi đang phát triển một số dự án như là một phần của học viện của tôi.

Trong khi phát triển cơ sở dữ liệu cho một trong các dự án, chúng tôi đã gặp một tình huống mà chúng tôi nghĩ về việc liệu ERD có cần thiết hay không. Ngay bây giờ, không phải ai trong chúng ta cũng đồng ý phát triển ERD trước, và sau đó phát triển cơ sở dữ liệu từ nó.

Phần lớn mọi người thích phát triển cơ sở dữ liệu nhanh chóng theo yêu cầu hệ thống trên giấy trực tiếp.

Bây giờ, tôi là người theo dõi nghiêm ngặt các nguyên tắc cơ sở dữ liệu. Tôi nghĩ rằng cơ sở dữ liệu chỉ nên được phát triển từ ERD. Vì vậy, tôi chỉ muốn biết những điều sau đây:

• Là ngành công nghiệp theo những nguyên tắc này?
• Có phải tôi đang lãng phí thời gian để phát triển ERD?
• Những lợi ích của việc phát triển ERD là gì?

Rõ ràng và đơn giản, hãy nghĩ đến việc phát triển cơ sở dữ liệu mà không cần ERD như xây dựng một ngôi nhà mà không có kế hoạch xây dựng. Có thể là có thể bởi vì bạn nghĩ rằng chỉ cần đặt một viên gạch lên nhau là đủ để xây dựng một cái gì đó, tuy nhiên thời điểm ai đó chịu trách nhiệm về dự án có tiềm năng thảm họa.

Theo kinh nghiệm của tôi, bạn sẽ không được hưởng lợi nhiều từ ERD trừ khi bạn sử dụng chúng cùng với các công cụ CASE (ERWin, MySQL Workbench, v.v.) sẽ cho phép bạn thực hiện một số thao tác thực sự hữu ích như kỹ thuật chuyển tiếp và đảo ngược. Ngay cả khi không có các hàm này có sơ đồ tập trung của cơ sở dữ liệu hoàn chỉnh là hữu ích vì đôi khi các ràng buộc được triển khai trong cơ sở dữ liệu không đủ để kể câu chuyện đầy đủ về mối quan hệ giữa các thực thể cơ sở dữ liệu cụ thể.

Dưới đây là một ví dụ liên quan đến MySQL, như bạn có thể biết, thực hiện một số công cụ lưu trữ nội bộ, đáng chú ý nhất là MyISAM và InnoDB. Có một số khác biệt đáng kể giữa chúng, một trong những điều quan trọng nhất là MyISAM không hỗ trợ các ràng buộc. Mặc dù thực tế đó, MyISAM được sử dụng nhiều cho các ứng dụng web, điều đó có nghĩa là logic quan hệ cần được triển khai thông qua logic nghiệp vụ (mã ứng dụng) hoặc theo một cách khác. Vấn đề là khi bạn chuyển tiếp một ERD với các bảng (thực thể) MyISAM, MySQL sẽ âm thầm bỏ qua các ràng buộc do ERD đặt ra và bạn sẽ kết thúc với một cơ sở dữ liệu không xác định rõ bản chất của các mối quan hệ giữa các thực thể. Nói cách khác, sau khi bạn phát triển bố cục cơ sở dữ liệu, không có cách nào để các nhà phát triển mã thực hiện logic nghiệp vụ phù hợp mà không có ERD.

ERD thực sự rất hay để có một bức tranh rõ ràng về cấu trúc cơ sở dữ liệu của bạn. Bên cạnh việc là một tài liệu quan trọng cho dự án của bạn, nó giảm bớt khi bạn cần thực hiện các truy vấn, đặc biệt là tham gia giữa các bảng. Hãy tưởng tượng nó tốt như thế nào khi có cấu hình màn hình kép, ở bên trái bạn có ERD và ở bên phải trình soạn thảo truy vấn của bạn. Bạn có thể thấy rõ mối quan hệ giữa các bảng và viết các truy vấn của bạn dựa trên đó. Nếu dự án cơ sở dữ liệu của bạn khá đơn giản và dự án của bạn không yêu cầu nó, có lẽ bạn vẫn sống được nếu không có nó.

ERD sẽ giúp bạn tiết kiệm nhiều thời gian hơn bạn nghĩ, Nếu bạn làm mọi thứ một cách nhanh chóng thì bạn sẽ bị mắc kẹt khi bạn muốn tạo các bảng nối.

Nếu bạn bắt gặp cơ sở dữ liệu một vài năm sau đó mà không có ERD, bạn phải dành nhiều thời gian để xem những gì đang diễn ra trong dự án của bạn.

Tôi có công ty và chúng tôi thiết kế ERD, đừng bao giờ nghĩ về cơ sở dữ liệu mà không có ERD. (Thực ra đây là thử nghiệm cá nhân của riêng tôi)

ERD đã từng là chủ đạo hơn một thời gian trước đây. IMO bây giờ họ ít nhiều tùy chọn.

Hiện tại, một số nhóm rất thành công hoàn toàn không bận tâm đến ERD, nhưng vẫn cung cấp các hệ thống tuyệt vời: mạnh mẽ, hiệu quả và dễ bảo trì trong thời gian dài. Điều này đặc biệt đúng trong phát triển Agile, khi chúng ta bắt đầu nhỏ, với một bộ công cụ tối giản.

ERD là một cách tốt để giao tiếp, tất nhiên, nhưng không có nghĩa là cách duy nhất, hoặc tốt nhất trong mọi trường hợp. Một số đội thích những cách khác của tài liệu và truyền thông.

Không có quy tắc chăn trong ngành công nghiệp này.

Điều quan trọng là phải thiết kế trước khi viết mã sản xuất. Nó cũng quan trọng đối với nguyên mẫu; người cơ sở dữ liệu phát triển các nguyên mẫu bằng cách viết SQL. (Hãy nhớ những gì Fred Brooks nói về nguyên mẫu?)

Các ngôn ngữ đồ họa, trong đó ER chỉ là một, chưa được chứng minh là rất giỏi trong việc nắm bắt tất cả các ngữ nghĩa của cơ sở dữ liệu theo cách dễ hiểu và đơn giản.

Chúng cũng chưa được chứng minh là công cụ giao tiếp rất hiệu quả, ngoại trừ giữa các nhà phát triển. Nhưng trong việc thiết kế cơ sở dữ liệu, giao tiếp quan trọng không phải là giữa các nhà phát triển; đó là giữa nhà phát triển và chuyên gia tên miền (giữa nhà phát triển và doanh nhân).

Mô hình hóa vai trò đối tượng (ORM) có ngôn ngữ đồ họa, nhưng nó dựa trên "fact" (câu đơn giản). Người kinh doanh có thể xác nhận sự thật khá dễ dàng. Người kinh doanh không thể dễ dàng xác nhận sơ đồ ER hoặc sơ đồ ORM.