Tính toàn vẹn dữ liệu tham chiếu: Sự cần thiết, đẹp hay có, hoặc mũ cũ?

Question

Các khung như Rails đã khuyến khích di chuyển rất nhiều logic, ngay cả những thứ như ràng buộc và khóa ngoài, ngoài cơ sở dữ liệu - theo ý kiến ​​của tôi. cho tốt hơn, vì nó dễ quản lý và dễ thay đổi hơn. Mặc dù vậy, một số thao tác dễ dàng hơn nhanh hơn, hoặc chỉ đơn giản là có thể trong SQL.

Sự bùng nổ gần đây về cơ sở dữ liệu NoSQL như MongoDB, Cassandra, vv, đã thay đổi cách tiếp cận thực tiễn tốt nhất trong phát triển cơ sở dữ liệu thậm chí triệt để hơn.

Câu hỏi của tôi: là tính toàn vẹn dữ liệu tham chiếu không còn là điều cần thiết?

Tôi nhận ra nó thường đi xuống để chọn công cụ tốt nhất cho công việc, nhưng hãy loại trừ các ứng dụng tài chính và ứng dụng loại tương tự trong đó giao dịch là phải có và tập trung vào các ứng dụng tiêu biểu hơn kiếm tiền nhưng không yêu cầu tính toàn vẹn ở mức ngân hàng.

Mức độ toàn vẹn dữ liệu tham chiếu cần thiết như thế nào? Ai đó có thể liệt kê một số vấn đề họ đã có khi họ không sử dụng nó?

Đang sử dụng cơ sở dữ liệu như PostgreSQL để có thêm dữ liệu quan trọng và MongoDB cho dữ liệu ít quan trọng nhưng được yêu cầu cao, chiến lược thông minh? Làm cách nào bạn đề xuất xác định chính xác dữ liệu nào là "quan trọng" và "không quan trọng" là gì?

Answer 1

Tôi đã làm việc trong một công ty (ebay.com), nơi cơ sở dữ liệu rất lớn. Chúng tôi không được sử dụng bất kỳ tính toàn vẹn tham chiếu nào trong cơ sở dữ liệu. Hạn chế này đã được đưa ra trong tâm trí giữ các yếu tố hiệu suất một mình. Chúng ta thậm chí sẽ không định nghĩa bất cứ thứ gì trong ORM (Object Relational Mapping). Mọi thứ phải được xử lý hợp lý. Tôi biết nó có một chút khó khăn để thậm chí tưởng tượng, nhưng vẫn là thats những gì cung cấp một hiệu suất tốt hơn.

Bây giờ cho câu hỏi của bạn, với quá nhiều trừu tượng xảy ra ở cấp ORM, mọi người thậm chí không quan tâm đến những gì đang xảy ra ở phía cơ sở dữ liệu. Ít nhất những cái mới sắp ra để mã hóa hầu như không chăm sóc viết Triggers, tuyên bố tính toàn vẹn tham chiếu trực tiếp trong một cơ sở dữ liệu (như oracle), nơi bạn có thể làm rất nhiều bằng cách viết các thủ tục lưu trữ. Nhưng mọi người vẫn thích và cảm thấy dễ dàng hơn khi mã hóa mọi thứ ở cấp ORM. Vì vậy, IMO, tôi cảm thấy rằng nó trở thành một chiếc mũ cũ.

Answer 2

Tôi nghĩ nhận xét cuối cùng của bạn về việc có hai kho dữ liệu là tương lai cho hầu hết các ứng dụng cỡ trung mới sắp ra mắt. Một phụ trợ với tính toàn vẹn tham chiếu cho những thứ như kết nối các thành phần cốt lõi của trang web và một phần khác cho dữ liệu quy mô lớn hơn trên Internet.

Các công ty cũ như eBay không nên được sử dụng làm so sánh vì chúng có nguồn lực để thực hiện QA nghiêm ngặt và suy nghĩ thông qua các tác động của mọi thứ mà nhà phát triển thực hiện. Một điển hình nhỏ cỡ trung khởi động không có những nguồn lực và giữ dữ liệu quan trọng trong một cửa hàng với tính toàn vẹn tham chiếu ngăn ngừa rất nhiều lỗi ứng dụng từ việc có thể ngồi âm thầm trong trang web của bạn trong một thời gian dài.

Kiểm tra Django's support for multiple databases. Hãy nhớ rằng việc chuyển từ kho dữ liệu ACID đến kho dữ liệu CRUD dễ dàng hơn nhiều so với cách khác.

Answer 3

Nếu bạn muốn liên kết và tham chiếu đến dữ liệu, tính toàn vẹn tham chiếu sẽ luôn là mối quan tâm hợp lệ. Câu hỏi hiện đại không phải là liệu nó có cần thiết hay không, nhưng có nên quản lý nó trong thời cơ sở dữ liệu sql truyền thống của việc xác nhận các trường khóa ngoài thông qua các chỉ mục được quản lý bởi các lập trình viên và quản trị cơ sở dữ liệu. Các cơ sở dữ liệu đơn giản phù hợp với truy cập đối tượng có thể ẩn các phương thức toàn vẹn dữ liệu truyền thống hoặc có thể cho phép quản lý các vấn đề theo lập trình như ngoại lệ hoặc các mối quan tâm đó có thể được quản lý theo cách thủ công.

Điều đó đang được nói, các phương pháp truyền thống hoạt động tốt cho hầu hết các ứng dụng (mặc dù dường như không phải eBay). Tính toàn vẹn tham chiếu có vẻ ngớ ngẩn cho đến khi bạn gặp vấn đề về tính toàn vẹn khó khôi phục. Vì nó là tầm thường để thực hiện, bạn nên bắt đầu với nó và chỉ loại bỏ nó khi nhu cầu thực hiện trở nên rõ ràng mà không thể được đáp ứng bằng các phương tiện khác.

Đối với mongo, hãy sử dụng nó khi ứng dụng giúp ứng dụng dễ triển khai và bảo trì hơn. Bạn chắc chắn có thể sử dụng cả hai nếu cần thiết.

Answer 4

Tôi nghĩ điều khác cần xem xét là vòng đời của ứng dụng và lưu trữ dữ liệu. Nếu lưu trữ dữ liệu hữu ích cho doanh nghiệp, bạn sẽ được truy cập nhiều hơn sau đó một ứng dụng và/hoặc có giao diện với các kho dữ liệu khác. Càng gần với dữ liệu mà tính toàn vẹn tham chiếu càng ít rủi ro của một giao diện hoặc cái gì khác làm cho một bản cập nhật xấu.

Và trong khi ứng dụng bạn đang làm việc bây giờ có thể có giao diện khoảng 7 năm xuống theo dõi? (Dường như ứng dụng kinh doanh trung bình được giữ lại trong 7 năm) Khi doanh nghiệp phát triển các công cụ khác sẽ được sử dụng (ví dụ, hoặc bằng cách thực hiện cùng một doanh nghiệp hoặc mua lại doanh nghiệp khác)

Answer 5

Tôi nghĩ câu hỏi và hầu hết các câu trả lời ở đây dường như đang nói cùng một điều: rằng tính toàn vẹn dữ liệu (RI chỉ là một khía cạnh phổ biến của toàn vẹn dữ liệu) chắc chắn là cần thiết và vẫn quan trọng đối với ngày bao giờ hết. Tính toàn vẹn dữ liệu có lẽ còn quan trọng hơn ngày hôm nay so với trước đây do những lo ngại ngày càng tăng về quản trị, điều chỉnh và bảo vệ dữ liệu. Nó chỉ xảy ra khi mọi người thấy rằng DBMS không cung cấp các cơ sở mà họ cần để họ xem xét thực hiện các quy tắc toàn vẹn ở nơi khác. Điều này là lạ, bởi vì sau khi tất cả các DBMS là gần nhất với dữ liệu và do đó nên được đặt tốt nhất để thực hiện các quy tắc kinh doanh một cách hiệu quả. Các quy tắc khai báo phải dễ bảo trì và xác thực hơn các quy tắc thủ tục. Việc duy trì các quy tắc tập trung trong cơ sở dữ liệu cũng phải hiệu quả về chi phí hơn là phân phối các quy tắc trên nhiều lớp và ứng dụng khác.

Kết luận của tôi là nếu những điều này không phải là chứng minh là đúng đối với một số người, thì điều đó thực sự nói rất nhiều về sự thiếu sót của phần mềm cơ sở dữ liệu ngày nay. Nó không không ngụ ý rằng tính toàn vẹn là không quan trọng - hoàn toàn ngược lại.