Các ràng buộc trong cơ sở dữ liệu quan hệ - Tại sao không loại bỏ chúng hoàn toàn?

Có bất kỳ lý do để xây dựng các ràng buộc giữa các bảng (bên trong SQLserver) ngày nay không? Nếu sau đó? Hầu hết các ứng dụng trong khu vực của tôi được xây dựng trên các nguyên tắc đối tượng và các bảng được nối theo yêu cầu. Nhu cầu dựa trên nhu cầu từ ứng dụng. Tôi sẽ không tải một loạt các bảng bị ràng buộc để tìm kiếm đơn giản, do đó (sau khi hành động) yêu cầu một tra cứu đơn giản khác.

Các công cụ ORM như EntityContext, Linq2Data, NHibernate cũng tự xử lý các ràng buộc, ít nhất bạn biết bảng nào cần nhau. Làm các ràng buộc bên trong máy chủ chỉ là thực hiện (buộc) thay đổi tương tự hai lần?

Đây thường không phải là một câu hỏi cho quyết định, nhưng cơ sở dữ liệu này được thiết kế khá khác nhau. Thiết kế có vẻ tốt thường xuyên, chủ yếu là nhân đôi các đối tượng được sử dụng bởi các ứng dụng. Điều làm tôi băn khoăn là tất cả các ràng buộc được cấu hình bên trong SQLserver với "không phải tầng". Điều đó có nghĩa là bạn phải chơi "tìm và tìm" khi mã hóa các truy vấn cơ sở dữ liệu mới. Một số trường hợp yêu cầu tối đa 10 cấp của một đơn đặt hàng chính xác để thực hiện xóa một lần.

Điều này làm tôi ngạc nhiên và tôi không biết phải xử lý thế nào.

Trong thế giới đơn giản của tôi, cài đặt đó làm cho các ràng buộc mất đi phần lớn mục đích. OK nếu cơ sở dữ liệu được truy cập từ máy chủ mà không có kiến ​​thức về thiết kế.

Làm thế nào bạn sẽ hành động trong kịch bản này?
Tại sao không loại bỏ tất cả các ràng buộc khỏi db và giữ chúng ở mức ứng dụng?

Hai lý do chung để không loại bỏ các mâu thuẫn khỏi DB :

• Nó có thể được truy cập bởi nhiều ứng dụng hơn, ngay bây giờ hoặc trong tương lai , có thể hoặc không thể sử dụng ORM. Ngay cả khi các nhà phát triển của các ứng dụng đó sao chép một cách trung thực tất cả các ràng buộc ở đó (có thể khó khăn hơn đáng kể khi sử dụng các giải pháp phi ORM cấp thấp hơn), thì đó vẫn luôn là công việc phụ. Và nếu không, ngay cả một thiếu sót nhỏ cũng đủ để phá vỡ tính toàn vẹn của lược đồ ... đó là điều bạn không muốn mạo hiểm. Trong hầu hết các công ty, dữ liệu được lưu trữ trong DB của họ là huyết mạch trong hoạt động kinh doanh của họ, vì vậy tính toàn vẹn của nó phải được đảm bảo bằng bất kỳ phương tiện nào. Và phương tiện tốt nhất đã được thử nghiệm và chứng minh để đạt được điều này là thực hiện càng nhiều ràng buộc trong DB càng tốt.
• Trình tối ưu hóa truy vấn phụ thuộc rất nhiều vào các ràng buộc được biết ở cấp độ DB. Nếu bạn loại bỏ các ràng buộc, hiệu suất truy vấn có thể bắt đầu xấu đi . Bạn có thể không nhận ra ngay lập tức, nhưng một ngày nào đó nó sẽ đánh bạn, và sau đó có thể là quá muộn để khắc phục nó một cách dễ dàng. Bản chất của mọi thứ là hiệu suất DB có xu hướng bị hỏng ở thời điểm tải cao nhất, khi có ít khả năng thực hiện các cải tiến thiết kế cẩn thận, cẩn thận, được hỗ trợ bởi các phép đo hiệu suất chính xác và phân tích chi tiết để xác định nguyên nhân gốc rễ.

Trường hợp cụ thể của bạn nghe có vẻ như lược đồ DB có thể được tạo ra ban đầu bởi một công cụ ORM (hoặc được thiết kế bởi một người không có nhiều kinh nghiệm với thế giới quan hệ), do đó, nó là tối ưu theo quan điểm quan hệ. Có lẽ tốt hơn để phân tích và cải thiện nó theo hướng thiết kế quan hệ "tự nhiên" hơn, trong khi vẫn giữ cho nó phù hợp với các quan điểm ORM. Nó có thể hữu ích khi liên quan đến một chuyên gia DB trong phân tích này.

Các ứng dụng có thể đến và đi nhưng dữ liệu sống mãi mãi. Trong công ty của tôi, DB đã hơn 30 - 40 tuổi, nó sẽ tồn tại chừng nào công ty còn tồn tại. Các ứng dụng thay đổi, các nhà phát triển đến và đi. Nó là tốt hơn để có tính toàn vẹn và một mô hình dữ liệu logic tốt. Bằng cách đó, ai đó có thể xem dữ liệu và hiểu được ý nghĩa mà không cần phải thông qua một cơ sở mã phức tạp. Điều này cũng giúp báo cáo đáng kể. Ngoài ra các ứng dụng có thể và sẽ có lỗi và ràng buộc DB là một biện pháp bảo vệ chống lại điều đó. Vị trí mặc định của tôi là có càng nhiều ràng buộc (FK và kiểm tra) càng tốt.
Lý do duy nhất để không có ràng buộc là nếu mẫu thiết kế của bạn không cho phép điều đó, ví dụ như các vấn đề về Bảng phân cấp hoặc hiệu suất.

Điều làm tôi băn khoăn là tất cả các ràng buộc được cấu hình bên trong SQLserver với "không phải tầng".

Điều đó không làm phiền tôi, điều đó có nghĩa là ai đó đã thể hiện ý thức tốt. Xóa tầng thường rất xấu cho cơ sở dữ liệu. Trước tiên, đôi khi bạn muốn xóa thất bại nếu bạn có dữ liệu trong các bảng liên quan. Chẳng hạn, nếu bạn có một khách hàng có đơn đặt hàng trong quá khứ, bạn không muốn anh ta bị xóa hoặc bạn mất dữ liệu về đơn đặt hàng đó và một thác xóa sẽ xóa bỏ hồ sơ sẽ gây rối cho bạn báo cáo tài chính .

Bạn dường như nghĩ rằng sự dễ dàng phát triển là điều quan trọng nhất. Trong thế giới cơ sở dữ liệu, điều này không đúng. Tính toàn vẹn dữ liệu là điều quan trọng nhất đầu tiên được theo sát bởi hiệu suất và bảo mật dữ liệu. Nếu nó mất nhiều thời gian hơn để viết các truy vấn thì vậy.

Cơ sở dữ liệu thường được tác động bởi nhiều ứng dụng = một hoặc nhiều trang web hoặc ứng dụng máy tính để bàn, ứng dụng báo cáo, dịch vụ web, cửa sổ truy vấn, quy trình ETL, v.v. Nếu bạn không thực thi các ràng buộc ở cấp cơ sở dữ liệu, trước tiên bạn sẽ mất tính toàn vẹn dữ liệu là một trong những ứng dụng đó có thể không tuân theo tất cả các quy tắc. Thứ hai, bạn phải mã hóa các chống chỉ định đó nhiều lần và viết lại nếu bạn quyết định sử dụng một ứng dụng khác sau này. Thứ ba, bạn không thể kiểm soát trước liệu có cần thực hiện một số loại nhiệm vụ bảo trì dữ liệu sẽ không xảy ra thông qua ứng dụng hay không (chẳng hạn sửa dữ liệu từ nhập dữ liệu khách hàng xấu hoặc thay đổi tất cả 10.000.000 bản ghi từ một khách hàng cho một khách hàng khác khi công ty được mua bởi một đối thủ cạnh tranh). Điển hình là các nhà phát triển ứng dụng don '

Tôi đã đọc ở đâu đó một lần về cơ bản: Dữ liệu là chìa khóa của ứng dụng của bạn . Nếu bạn sẽ chỉ truy cập BAO GIỜ dữ liệu thông qua giao diện người dùng của bạn (và tôi có nghĩa bao giờ hết , như trong bây giờ và mãi mãi, vĩnh viễn ... hoặc thời gian tồn tại của ứng dụng của bạn, dù sao) hạn chế cơ sở dữ liệu sau đó bạn không cần. Nhưng có thể có một thứ gì đó không phải là ứng dụng sẽ cần chạm vào dữ liệu, ví dụ như dịch vụ web, API công khai, tác vụ cào / lệnh SQL / cron / tập lệnh tự động, sau đó bạn sẽ tự cứu mình rất nhiều rắc rối tiềm ẩn đường bằng cách giữ các ràng buộc DB.

Tôi tin chắc rằng đây là một lĩnh vực phát triển phần mềm mà bạn không nên áp dụng DRY (và tôi hoàn toàn mong đợi một loạt các downvote cho tuyên bố đó). Dữ liệu của bạn là trái tim và linh hồn của ứng dụng của bạn - nếu nó bị hỏng ngoài sửa chữa, thì đó là: trò chơi kết thúc. IMO đáng để thực thi các ràng buộc ở mọi nơi họ cần. Nếu điều đó có nghĩa là ở dạng Kích hoạt và ràng buộc ở cấp độ DB, xác thực phía máy chủ trên phần mềm trung gian và Javascript phía máy khách trên UI (đối với ứng dụng web), thì IMO là một điều ác cần thiết để đảm bảo dữ liệu luôn luôn nguyên sơ .

Bạn có biết ORM nghĩa là gì không? Bản đồ quan hệ giữa các đối tượng. Trích dẫn Wikipedia "kỹ thuật chuyển đổi dữ liệu giữa các hệ thống loại không tương thích ". Các mô hình đối tượng, quan hệ và đối tượng không khớp với nhau. Các ORM thực hiện chuyển đổi khá tốt, bằng cách tôn trọng các quy tắc của cả hai hệ thống loại. RDBMS được tổ chức theo cách như vậy, rằng bạn đạt được tính toàn vẹn dữ liệu bằng cách sử dụng các ràng buộc. Nói chung, tính toàn vẹn là điều rất tốt để có, vì vậy các ORM có xu hướng sử dụng chúng khi tạo mô hình dữ liệu để lưu trữ dữ liệu đối tượng. ORM của bạn có thể có một lý do chính đáng để sử dụng các ràng buộc "không xếp tầng". Và nếu điều này buộc bạn phải thực hiện các truy vấn phức tạp thay vì chỉ tạo / cập nhật / thả một số đối tượng nhất định, thì có gì đó không đúng với thiết lập ORM của bạn.

Nếu bạn coi khái niệm quan hệ là gây phiền nhiễu, thì tại sao bạn không sử dụng cơ sở dữ liệu đối tượng? Cách đây một thời gian, chúng rất chậm (đó là lý do tại sao hầu hết mọi người vẫn sử dụng RDBMS) nhưng từ những gì tôi nghe được thì mọi thứ đã thay đổi một chút. Bạn sẽ thoát khỏi tất cả các nitpicks quan hệ. Đơn giản là đối tượng trong, đối tượng ra.

Đó là những gì eBay đã làm và họ có thể có một trong những cơ sở dữ liệu lớn nhất trên thế giới:

http://www.dba-oracle.com/oracle_news/news_ebay_massive_oracle.htmlm http://www.addsimplicity.com/doads/eBaySDForum2006-11-29.pdf

Mặc dù những gì đã nói ở trên về hiệu suất được tăng lên bởi tính toàn vẹn tham chiếu, nó thực sự có thể bị suy giảm; đó là lý do tại sao các cơ sở dữ liệu lớn đã giảm các ràng buộc và thực hiện công việc trong lớp ứng dụng. Và theo như tôi có thể nói đó là lý do thực sự tốt duy nhất.

Bằng cách loại bỏ những ràng buộc đó, về cơ bản, bạn sẽ mất mạng lưới an toàn để giữ dữ liệu sạch sẽ và điều đó mang lại những vấn đề riêng. Vì vậy, như với tất cả mọi thứ nó là một hành động cân bằng. Tôi đoán rằng nói chung duy trì tính toàn vẹn tham chiếu là điều nên làm.

Đã làm việc trong một môi trường phát triển với tính toàn vẹn tham chiếu mạnh mẽ, tôi biết rằng từ quan điểm của một nhà phát triển rằng nó có thể là một nỗi đau tổng thể; thông thường trong môi trường phát triển, một chút dữ liệu bẩn không thành vấn đề và tìm ra cách xóa một hàng có thể mất một giờ hoặc hơn. Tuy nhiên, nó cũng có thể rất hữu ích, vì các ràng buộc làm cho lược đồ rõ ràng.

Đầu tiên - câu trả lời của tôi: Không, bạn không nên chỉ dựa vào ứng dụng để chăm sóc dữ liệu của mình.

Điều này chỉ ra một cuộc tranh luận lớn hơn: Các ORM đã khuyến khích văn hóa coi thường tương tác DB "trực tiếp", thường phải trả giá bằng sự bình thường hóa / toàn vẹn tham chiếu. Các bảng được ánh xạ cưỡng bức thành các hệ thống phân cấp đối tượng tùy ý, với chi phí thiết kế ẩn trong mô hình quan hệ. Việc tách rời được ưa thích bởi OOP được cho là hy sinh ở đây vì ứng dụng làm cho thiết kế của nó cảm thấy trong cấu trúc dữ liệu. Mặc dù ORM đã chứng minh tiện ích tuyệt vời, nó dường như được dựa trên sự lạm dụng hoặc không tin tưởng của SQL.

Các mô hình mới đang (tái) xuất hiện, lấy chương trình Chức năng làm ví dụ. Nếu nhóm nhà phát triển quyết định áp dụng một phương pháp lập trình mới thì điều này sẽ có ý nghĩa gì đối với dữ liệu đã được cấu trúc theo yêu cầu của ORM?

Tôi đồng ý với @Jacek Prucia - Tôi nghĩ ORM là một kết quả không phù hợp với RDBMS, cá nhân tôi đã chọn DBAL trên RDBMS hoặc đi đến một 3MB với ORM.

Các ràng buộc là đảm bảo duy nhất của bạn rằng bạn có tính nhất quán và toàn vẹn dữ liệu ở cấp cơ sở dữ liệu. Chắc chắn, bạn có thể thực thi các ràng buộc bằng mã ứng dụng của mình, nhưng nếu trong tương lai, bạn cần sửa đổi dữ liệu trực tiếp thì sao? Bạn có thể hiểu làm thế nào để duy trì tính toàn vẹn dữ liệu, nhưng người khác có thể không. Giữ các ràng buộc ở mức dữ liệu đảm bảo rằng tính toàn vẹn được đảm bảo ngay cả khi ai đó đang lẩn quẩn ở những nơi họ không hiểu.

Hơn nữa, giả sử ứng dụng của bạn cần phải được viết lại, nhưng với cùng một cơ sở dữ liệu. Tất cả những ràng buộc trong mã chỉ là cầu xin các lỗi ngăn chặn một số mục nhập trong khi cho phép dữ liệu sai sót thông qua.

Khi phát triển, giữ cho nó đơn giản. Những ràng buộc cho phép bạn làm điều đó. (Điều đó nói rằng, khi một ràng buộc ném lỗi, đừng nhổ lại lỗi tương tự cho người dùng. Làm cho lỗi dễ hiểu.)

. trong thực tế

Một vấn đề với các ràng buộc trong cơ sở dữ liệu là chúng cung cấp cho chương trình thông tin hạn chế về những gì không thành công và cách khắc phục. Điều này có nghĩa là, để xử lý trơn tru, thường cần lặp lại kiểm tra ràng buộc trong ứng dụng và do đó kiểm tra ràng buộc cơ sở dữ liệu bị lãng phí công sức.

Điều này có nguy cơ ảnh hưởng đến tính toàn vẹn dữ liệu, vì vậy chúng tôi đã có sự đánh đổi ở đây. Đối với dữ liệu quan trọng, việc đảm bảo tính toàn vẹn dữ liệu hầu như luôn quan trọng hơn hiệu suất và tốt hơn hết là thất bại trong giao dịch ngay cả khi nó trông có vẻ độc đoán hơn là làm xáo trộn dữ liệu.

Do đó, để loại bỏ các ràng buộc một cách an toàn, điều quan trọng là phải bảo mật truy cập cơ sở dữ liệu để không có gì có thể thay đổi cơ sở dữ liệu mà không cần kiểm tra các ràng buộc. Điều này không đáng tin cậy khi viết các ứng dụng mới hoặc đưa ra các cách xử lý dữ liệu đột xuất, vì tất cả chỉ cần một lỗi và cơ sở dữ liệu bị hỏng.

Do đó, để phân phối các ràng buộc cơ sở dữ liệu, cần phải thiết lập những gì có thể và những gì không thể được thực hiện với cơ sở dữ liệu trước để tất cả các ứng dụng có thể được viết, xem xét và kiểm tra rộng rãi. Tất cả các yêu cầu cơ sở dữ liệu phải được thiết lập trước và bất kỳ thay đổi nào đối với các yêu cầu cơ sở dữ liệu sẽ yêu cầu công việc rộng rãi. Đây là một cái gì đó của một phương pháp thác nước đóng băng, chỉ hoạt động trong các trường hợp rất cụ thể. (Thiết kế, thực hiện và duy trì các yêu cầu cũng giống như đi bộ trên mặt nước. Trước tiên, một cái gì đó phải được đông lạnh và nếu nó không được đông lạnh đủ thì kết quả có thể là thảm họa.)

Một trường hợp hoạt động là các ứng dụng doanh nghiệp lớn như PeopleSoft và SAP, nơi ứng dụng đã thực hiện hầu hết mọi thứ và có nhiều cách được xác định cẩn thận để mở rộng nó. Có những khả năng khác, rất hiếm.

Vì vậy, trừ khi bạn làm việc trong một dự án doanh nghiệp rất lớn (và tôi không muốn) hoặc có thể đi trên nước lỏng, hãy để lại những hạn chế đó trong cơ sở dữ liệu.