Điều gì đã xảy ra với các ràng buộc cơ sở dữ liệu?

Khi tôi xem xét các mô hình cơ sở dữ liệu cho RDBMS, tôi thường ngạc nhiên khi thấy ít hoặc không có ràng buộc nào (dành PK / FK). Ví dụ, phần trăm thường được lưu trữ trong một cột loại int(trong khi tinyintsẽ phù hợp hơn) và không có CHECKràng buộc nào để giới hạn giá trị trong phạm vi 0..100. Tương tự như vậy trên SE.SE, các câu trả lời gợi ý các ràng buộc kiểm tra thường nhận được các bình luận cho thấy rằng cơ sở dữ liệu là vị trí sai cho các ràng buộc.

Khi tôi hỏi về quyết định không thực hiện các ràng buộc, các thành viên trong nhóm trả lời:

• Hoặc là họ thậm chí không biết rằng các tính năng như vậy tồn tại trong cơ sở dữ liệu yêu thích của họ. Có thể hiểu được từ các lập trình viên chỉ sử dụng ORM, nhưng ít hơn nhiều từ các DBA, những người tuyên bố có hơn 5 năm kinh nghiệm với một RDBMS nhất định.

• Hoặc họ thực thi các ràng buộc như vậy ở cấp ứng dụng và sao chép các quy tắc đó trong cơ sở dữ liệu không phải là ý tưởng hay, vi phạm SSOT.

Gần đây, tôi thấy ngày càng nhiều dự án mà thậm chí không sử dụng khóa ngoại. Tương tự, tôi đã thấy một vài bình luận ở đây trên SE.SE cho thấy rằng người dùng không quan tâm nhiều đến tính toàn vẹn tham chiếu, hãy để ứng dụng xử lý nó.

Khi hỏi các đội về lựa chọn không sử dụng FK, họ nói rằng:

• Chẳng hạn, đó là PITA khi người ta phải loại bỏ một phần tử được tham chiếu trong các bảng khác.

• Đá NoQuery, và không có khóa ngoại ở đó. Do đó, chúng tôi không cần chúng trong RDBMS.

• Đó không phải là vấn đề lớn về hiệu năng (bối cảnh thường là các ứng dụng web mạng nội bộ nhỏ hoạt động trên các tập dữ liệu nhỏ, do đó, ngay cả các chỉ mục cũng không quan trọng lắm; không ai quan tâm nếu hiệu suất của một truy vấn nhất định vượt qua từ 1,5 giây đến 20 ms.)

Khi tôi nhìn vào ứng dụng, tôi nhận thấy một cách có hệ thống hai mẫu:

• Ứng dụng vệ sinh dữ liệu đúng cách và kiểm tra nó trước khi gửi đến cơ sở dữ liệu. Chẳng hạn, không có cách nào để lưu trữ một giá trị 102dưới dạng phần trăm thông qua ứng dụng.

• Ứng dụng giả định rằng tất cả dữ liệu từ cơ sở dữ liệu là hoàn toàn hợp lệ. Đó là, nếu 102đến như một tỷ lệ phần trăm, một cái gì đó, một nơi nào đó sẽ sụp đổ, hoặc nó sẽ chỉ đơn giản được hiển thị như là cho người dùng, dẫn đến tình huống kỳ lạ.

• Mặc dù hơn 99% các truy vấn được thực hiện bởi một ứng dụng, theo thời gian, các tập lệnh bắt đầu xuất hiện một trong hai tập lệnh được chạy bằng tay khi cần hoặc các công việc định kỳ. Một số thao tác dữ liệu cũng được thực hiện bằng tay trên chính cơ sở dữ liệu. Cả tập lệnh và truy vấn SQL thủ công đều có rủi ro cao khi đưa ra các giá trị không hợp lệ.

Và đây là câu hỏi của tôi:

Các lý do để mô hình hóa cơ sở dữ liệu quan hệ mà không có ràng buộc kiểm tra và cuối cùng thậm chí không có khóa ngoại?

Đối với những gì nó có giá trị, câu hỏi này và câu trả lời tôi nhận được (đặc biệt là cuộc thảo luận thú vị với Thomas Kilian) đã khiến tôi viết một bài báo với kết luận của tôi về chủ đề hạn chế cơ sở dữ liệu .

Điều quan trọng là phải phân biệt giữa các trường hợp sử dụng khác nhau cho cơ sở dữ liệu.

Cơ sở dữ liệu kinh doanh truyền thống được truy cập bởi nhiều ứng dụng và dịch vụ độc lập và có lẽ trực tiếp bởi người dùng được ủy quyền. Điều quan trọng là phải có một lược đồ và các ràng buộc được suy nghĩ kỹ ở cấp cơ sở dữ liệu, do đó, một lỗi hoặc giám sát trong một ứng dụng không làm hỏng cơ sở dữ liệu. Cơ sở dữ liệu quan trọng trong kinh doanh, có nghĩa là dữ liệu không nhất quán hoặc bị hỏng có thể có kết quả thảm hại cho doanh nghiệp. Dữ liệu sẽ tồn tại mãi mãi trong khi các ứng dụng đến và đi. Đây là những nơi có thể có một DBA chuyên dụng để đảm bảo tính nhất quán và sức khỏe của cơ sở dữ liệu.

Nhưng cũng có những hệ thống mà cơ sở dữ liệu được tích hợp chặt chẽ với một ứng dụng duy nhất. Các ứng dụng độc lập hoặc ứng dụng web với một cơ sở dữ liệu nhúng duy nhất. Miễn là cơ sở dữ liệu được truy cập độc quyền bởi một ứng dụng duy nhất, bạn có thể xem xét các ràng buộc dư thừa - miễn là ứng dụng hoạt động chính xác. Các hệ thống này thường được phát triển bởi các lập trình viên tập trung vào mã ứng dụng và có lẽ không hiểu sâu về mô hình quan hệ. Nếu ứng dụng sử dụng ORM, các ràng buộc có thể được khai báo ở cấp ORM ở dạng quen thuộc hơn với các lập trình viên ứng dụng. Ở cấp thấp, chúng tôi có các ứng dụng PHP sử dụng MySQL và trong một thời gian dài, MySQL không hỗ trợ các ràng buộc cơ bản nào cả, vì vậy bạn phải dựa vào lớp ứng dụng để đảm bảo tính nhất quán.

Khi các nhà phát triển từ những nền tảng khác nhau gặp nhau, bạn sẽ có một cuộc đụng độ về văn hóa.

Trong hỗn hợp này, chúng ta có được làn sóng cơ sở dữ liệu "lưu trữ đám mây" phân tán mới. Rất khó để giữ một cơ sở dữ liệu phân tán nhất quán mà không làm mất lợi ích hiệu năng, vì vậy những cơ sở dữ liệu này thường tránh kiểm tra tính nhất quán ở cấp cơ sở dữ liệu và về cơ bản cho phép các lập trình viên xử lý nó ở cấp ứng dụng. Các ứng dụng khác nhau có các yêu cầu về tính nhất quán khác nhau và trong khi công cụ tìm kiếm của Google ưu tiên tính sẵn sàng hơn tính nhất quán trên các máy chủ của họ, tôi sẵn sàng đặt cược hệ thống bảng lương của họ chạy trên cơ sở dữ liệu quan hệ với nhiều ràng buộc.

Ngày càng có nhiều hệ thống đang chạy trong môi trường phân tán, trên đám mây và áp dụng kỹ thuật này để "mở rộng quy mô", thay vì "mở rộng quy mô". Điều đó thậm chí còn quan trọng hơn nếu bạn đang xử lý các ứng dụng trực tuyến trên internet, chẳng hạn như các ứng dụng thương mại điện tử.

Điều đó đang được nói, tất cả các ứng dụng được cho là mở rộng đều bị ràng buộc bởi Định lý CAP , trong đó bạn phải chọn 2 trong 3: Tính nhất quán, Tính khả dụng và Dung sai phân vùng (khả năng chịu lỗi mạng).

Bằng cách nghiên cứu Định lý CAP, bạn sẽ thấy rằng không có nhiều sự lựa chọn, nhưng chọn mất Tính khả dụng hoặc Tính nhất quán, vì bạn KHÔNG BAO GIỜ có thể thực sự tin tưởng vào Mạng 100% thời gian.

Nói chung, một số ứng dụng có thể đủ khả năng không nhất quán trong một khoảng thời gian hợp lý, nhưng không thể đủ khả năng để không có sẵn cho người dùng. Ví dụ: dòng thời gian hơi không được sắp xếp trong Facebook hoặc Twitter tốt hơn là không có quyền truy cập vào dòng thời gian.

Vì vậy, một số ứng dụng đang chọn cách loại bỏ các ràng buộc cơ sở dữ liệu quan hệ, vì các cơ sở dữ liệu quan hệ thực sự tốt về tính nhất quán, nhưng với chi phí khả dụng.

Lưu ý cá nhân: Tôi cũng lỗi thời và tôi đã làm việc với một số hệ thống tài chính thực sự cũ, trong đó, tính nhất quán dữ liệu là yêu cầu hạng nhất trong hầu hết thời gian và tôi là một fan hâm mộ lớn của các ràng buộc cơ sở dữ liệu. Các hạn chế cơ sở dữ liệu là tuyến phòng thủ cuối cùng chống lại nhiều năm và năm phát triển tồi tệ và các nhóm các nhà phát triển đến và đi.

"Est modus in rebus". Hãy tiếp tục sử dụng tính nhất quán DB "mức thấp" trong đó tính nhất quán là yêu cầu hạng nhất. Nhưng đôi khi, để nó đi không phải là một tội lỗi lớn.

-- BIÊN TẬP: --

Vì có một chỉnh sửa nhỏ trong câu hỏi, có một lý do chính đáng khác để loại bỏ các ràng buộc trong cơ sở dữ liệu, IMO. Nếu bạn thiết kế một sản phẩm từ đầu, nơi bạn thiết kế hệ thống của mình để hỗ trợ công nghệ đa cơ sở dữ liệu, bạn có thể giải quyết mẫu số ít phổ biến nhất trong số các cơ sở dữ liệu được hỗ trợ và cuối cùng bỏ qua việc sử dụng bất kỳ ràng buộc nào, để lại tất cả logic điều khiển cho ứng dụng của bạn.

Mặc dù nó hợp pháp, nhưng đó cũng là một khu vực màu xám đối với tôi, vì tôi không thể tìm thấy bất kỳ công cụ cơ sở dữ liệu nào ngày nay không hỗ trợ các ràng buộc đơn giản như một đề xuất trong câu hỏi ban đầu.

Các lý do để mô hình hóa cơ sở dữ liệu quan hệ mà không có ràng buộc kiểm tra và cuối cùng thậm chí không có khóa ngoại?

Trước tiên, hãy làm rõ rằng tôi chỉ nói ở đây về RDBM, không phải về cơ sở dữ liệu không có SQL.

Tôi đã thấy một vài cơ sở dữ liệu không có FK hoặc PK, chứ đừng nói đến việc kiểm tra các ràng buộc nhưng thành thật mà nói chúng là thiểu số. Có lẽ vì tôi làm việc trong một công ty lớn.

Theo kinh nghiệm của tôi qua nhiều năm tôi có thể nói rằng một số lý do có thể là:

• Trong trường hợp người mới bắt đầu hoặc lập trình viên sở thích , rất nhiều kỹ năng người mẫu
• Việc sử dụng rộng rãi hoặc gần như độc quyền các ORM không có liên hệ thực sự với thế giới cơ sở dữ liệu
• Vắng mặt một DBA hoặc chuyên gia mô hình dữ liệu khác trong một nhóm hoặc dự án nhỏ
• Thiếu sự tham gia của DBA hoặc chuyên gia mô hình dữ liệu trong các giai đoạn đầu tiên của sự phát triển
• Cố ý các quyết định thiết kế của một bộ phận trong cộng đồng nhà phát triển cho rằng ngay cả một ràng buộc kiểm tra thực thi rằng một cột nhất định chỉ có thể có 1,2 or 3giá trị hoặc cột "tuổi" phải >= 0là "có logic nghiệp vụ trong cơ sở dữ liệu" . Ngay cả các mệnh đề mặc định cũng được một số người coi là logic kinh doanh không thuộc về cơ sở dữ liệu, như bạn có thể thấy trong một số câu hỏi và câu trả lời gần đây trong chính trang web này. Nhà phát triển này rất cân nhắc, rõ ràng sẽ sử dụng càng ít ràng buộc càng tốt và sẽ làm mọi thứ trong mã, thậm chí là toàn vẹn tham chiếu và / hoặc duy nhất. Tôi nghĩ rằng đây là một vị trí cực đoan.
• Sử dụng RDBM làm kho lưu trữ giá trị khóa , để mô phỏng hành vi không có SQL vì các yêu cầu đủ đơn giản để được thỏa mãn bằng cách sử dụng các bảng RDBMS để cách ly kho lưu trữ khóa-giá trị.
• Giả sử rằng cơ sở dữ liệu sẽ luôn được ghi bởi "ứng dụng" và không ai cần phải tải dữ liệu lớn, hoặc chỉnh sửa hoặc chèn các hàng qua máy khách SQL (trong nhiều trường hợp để sửa dữ liệu xấu mà ứng dụng đã chèn). Trong trường hợp tốt nhất escenario, sẽ luôn có một ứng dụng khác (ngoài "ứng dụng") ban hành các hướng dẫn DML cho cơ sở dữ liệu: máy khách SQL.
• Không nhận ra rằng dữ liệu thuộc về chủ doanh nghiệp , không thuộc về ứng dụng.

Điều đó nói rằng, tôi muốn nói rằng RDBMS là những phần mềm rất tiên tiến được xây dựng trên vai của những người khổng lồ và đã tỏ ra rất hiệu quả đối với nhiều yêu cầu kinh doanh, giải phóng các lập trình viên về các nhiệm vụ trần tục trong việc thực thi tính toàn vẹn tham chiếu trên một loạt của tệp nhị phân hoặc tệp văn bản. Như tôi luôn nói "chúng ta không còn sống trong một thế giới cơ sở dữ liệu một ứng dụng" . Ít nhất một máy khách SQL sẽ phát hành các DML bên cạnh "ứng dụng". Vì vậy, cơ sở dữ liệu nên tự bảo vệ mình khỏi các lỗi của con người hoặc lập trình ở mức độ hợp lý

Trong các loại yêu cầu nổi tiếng trong đó RDBMS sẽ không mở rộng quy mô, bằng mọi cách có thể nắm lấy công nghệ không có SQL . Nhưng điều đáng lo ngại là sự phổ biến của các cơ sở dữ liệu quan hệ không có ràng buộc trong đó hàng ngàn dòng mã (được tạo hoặc gõ) dành để thực thi những gì RDBMS nên thi hành cho bạn theo những cách hiệu quả hơn.

Có những hạn chế bên ngoài thúc đẩy các quyết định công nghệ. Chỉ có một vài tình huống mà bạn có nhu cầu và hoặc sử dụng các ràng buộc trường cơ sở dữ liệu một cách thường xuyên.

1. Các doanh nghiệp có nhà phát triển cho cả ứng dụng và cơ sở dữ liệu cùng với DBA, nhưng hầu hết các nhà phát triển không hoạt động trong loại môi trường này. Họ làm nhiều nhất có thể trong mã. Ngoài ra, một số về phía cơ sở dữ liệu không tham gia vào các quy tắc kinh doanh. Họ chủ yếu ở đó để giữ cho mọi thứ chạy. Họ sẽ không bao giờ thúc đẩy các ràng buộc trong db. Phải đối phó với các ứng dụng cũ, tích hợp, di chuyển, sáp nhập, mua lại một ràng buộc db có thể là giải pháp tốt nhất.
2. Quá tải db có thể tạo ra một nút cổ chai không dễ giải quyết bằng cách ném thêm máy vào vấn đề. Có một số tình huống trong đó ngôn ngữ db không xử lý một số vấn đề lập trình mà không có hiệu năng lớn, vì vậy bạn không thể lên kế hoạch sử dụng một ràng buộc cho mọi thứ. Stackoverflow có một máy chủ cơ sở dữ liệu vì ném 2 vào một vấn đề là một thách thức.
3. Kiểm thử tự động - họ đang đến đó nhưng nhiều nhà phát triển db đã đến dự tiệc cùng với IDE / khung kiểm tra.
4. Triển khai - nhiều công cụ db làm cho nó phức tạp hơn. Điều gì xảy ra khi một bản cập nhật cho cơ sở dữ liệu của khách hàng không được phép vì có dữ liệu vi phạm ràng buộc? Trò chơi kết thúc trừ khi bạn có một cách để giải quyết điều này. Trong ứng dụng của bạn, bạn có thể quyết định cho phép người dùng xử lý việc này khi cần hoặc hướng dẫn một số quản trị viên thực hiện theo lô.
5. Chỉ có ứng dụng / api / dịch vụ mới ghi dữ liệu vào cơ sở dữ liệu, vậy tại sao phải bận tâm? Điều này chiếm phần lớn thời gian, đó là lý do tại sao nó không phổ biến.
6. Xử lý lỗi db là đủ khó mà không có hàng trăm vi phạm ràng buộc phải xử lý nếu mọi thứ thoát khỏi whack. Hầu hết đều vui lòng thực hiện kết nối và đặt tên bảng chính xác.

Nhiều nhóm phát triển không muốn cung cấp quá nhiều quyền kiểm soát cho nhà phát triển db. Bạn thật may mắn nếu bạn nhận được nhiều hơn một, vì vậy kỳ nghỉ rất nhiều niềm vui. Không nhiều người yêu cầu quyền kiểm soát tuyệt đối đối với miền cơ sở dữ liệu và chịu trách nhiệm cho mọi truy vấn, quy tắc kinh doanh, hiệu suất, tính khả dụng, bảo mật và dữ liệu nào đi đến RAID nào. Dưới đây là các thủ tục được lưu trữ mà bạn được phép thực hiện. Chúc vui vẻ. Thậm chí đừng nghĩ đến việc chạm vào một cái bàn.

Đây là một vấn đề mà tôi đã đấu tranh với tất cả sự nghiệp của mình (gần 40 năm) và cả khi viết DBMS. Mô tả về điểm cuối của tôi ở đây: http://unibase.zenucom.com . Vì vậy, đây là suy nghĩ của tôi.

1. Nói chung, hầu hết các ràng buộc được xử lý tốt hơn trong ứng dụng để các phần khác nhau của ứng dụng có thể thực thi các ràng buộc khác nhau. ví dụ một mã tiểu bang có thể không áp dụng trong tất cả các khu vực pháp lý.
2. Như một cảnh giác của%. Đánh dấu là> 100% hoặc bạn đã phá vỡ :)
3. Các ràng buộc được mô tả tốt nhất tiêu cực. tức là những gì họ không thể, không phải là những gì họ nên được. Nó luôn luôn là một danh sách đơn giản hơn.
4. Khóa ngoại luôn tốt và nên được sử dụng. Dấu chấm. FK là một trong số ít các cấu trúc ngữ nghĩa trong RDBMS và rất hữu ích. Khó khăn lớn nhất là quyết định xem có nên để giá trị treo lủng lẳng hay không nếu FK bị xóa hoặc sử dụng các hàng phụ thuộc làm lý do không xóa bản ghi FK.
5. Các ràng buộc trong thế giới thực thường phức tạp hơn một hạn chế giá trị trường đơn lẻ.
6. Một số hạn chế, thậm chí ở cấp ứng dụng, hoạt động chống lại các hoạt động tốt. ví dụ: kiểm tra ngày tích cực che giấu lỗi trong những ngày rõ ràng tốt. Bạn cần lỗi vận hành để có được số đo lỗi trong các ngày tìm kiếm hợp lý.

Các ràng buộc cơ sở dữ liệu có thể là một ý tưởng thông minh, nhưng còn việc sử dụng thực tế cho chúng thì sao? Hãy hạn chế tỷ lệ phần trăm của bạn. Nếu bạn áp dụng điều đó, DB của bạn sẽ vui vẻ từ chối tỷ lệ phần trăm không hợp lệ. Và sau đó? Bạn sẽ cần logic kinh doanh để xử lý ngoại lệ. Điều đó thực sự có nghĩa là logic kinh doanh viết sai phần trăm đã thất bại ở nơi khác. Vì vậy, trong ngắn hạn: hạn chế thực tế duy nhất còn lại là những hạn chế bạn nhìn thấy (như PK / FK).

Thường xuyên hơn những ngày này, mọi người đang sử dụng phần mềm (ví dụ Entity Framework) để tạo bảng và cột tự động. Ý tưởng là họ không cần các kỹ năng SQL, giải phóng năng lực não bộ.

Kỳ vọng rằng phần mềm sẽ "giải quyết mọi việc" thường không thực tế và nó không tạo ra những hạn chế mà con người sẽ làm.

Để có kết quả tốt nhất, hãy tạo các bảng bằng SQL và thêm các ràng buộc theo cách thủ công, nhưng đôi khi mọi người không thể làm điều này.