NoQuery trong SQL Server

Câu hỏi này không phải là về sự khác biệt giữa SQL và NoQuery. Tôi đang tìm kiếm một số lý do cho một cái gì đó thực sự không có ý nghĩa với tôi tại thời điểm này (có thể vì sự thiếu hiểu biết hoặc đánh giá cao của tôi).

Chúng tôi đã bắt đầu một dự án mới từ đầu bằng cách sử dụng MVC5, mã Entity framework 6 và SQL Server 2008. Khi kiến ​​trúc sư xem xét lược đồ cơ sở dữ liệu, cần phải loại bỏ tất cả các khóa ngoại và các ràng buộc khác như vậy vì đây là logic kinh doanh. nên được áp dụng trong lớp nghiệp vụ của mã ứng dụng.

Ý kiến ​​của tôi là các khóa ngoại tạo thành một phần của tính toàn vẹn dữ liệu / tham chiếu và không thực sự bắt chước logic kinh doanh. Tôi thấy logic kinh doanh khi nhiều quá trình và xác nhận kiểm soát những gì / khi / làm thế nào / tại sao các tham chiếu được áp dụng. Tôi có thể hiểu rằng các ràng buộc duy nhất là các quy trình kinh doanh có thể tranh cãi, nhưng đối với tôi điều này chỉ bổ sung cho logic và tạo thành một phần của tính toàn vẹn.

Đối số thứ hai là mục đích là áp dụng cách tiếp cận dữ liệu của NoQuery. Tôi thấy điều này thực sự bất thường và không chính thống: xem xét việc sử dụng SQL-Server 2008, nhu cầu báo cáo, dữ liệu không mở rộng đến terabyte và thiếu cân nhắc đối với các công nghệ như Mongo, Raven, v.v.

Có ai đã gặp một kịch bản như vậy trước đây? Tại sao mọi người sẽ áp dụng cách tiếp cận NoQuery trong Máy chủ SQL được thiết kế cho dữ liệu tham chiếu và không muốn khóa ngoại?

Khi ông xem xét lược đồ cơ sở dữ liệu, ông nói rằng tất cả các khóa ngoại và các ràng buộc khác phải được loại bỏ vì đây là logic nghiệp vụ và nên được áp dụng trong lớp nghiệp vụ.

Sau đó, anh ta là một thằng ngốc và một số trích đoạn từ cơ sở mã của bạn có thể sẽ kết thúc trên Daily WTF một ngày nào đó. Bạn hoàn toàn đúng khi cho rằng cách tiếp cận của anh ấy không có ý nghĩa, và thẳng thắn cũng không giải thích.

Hãy thử giải thích với anh ta rằng các ràng buộc toàn vẹn tham chiếu không phải là "logic kinh doanh"; chúng là một tiêu chuẩn chính xác với xác minh tích hợp sẵn. Logic kinh doanh là về những gì bạn làm với dữ liệu; tính toàn vẹn là về việc đảm bảo rằng dữ liệu không bị hỏng. Và nếu điều đó không hiệu quả ... tốt, anh ấy sẽ chịu trách nhiệm. Bạn có thể đi cùng với kế hoạch của anh ta và cố gắng giảm thiểu thiệt hại phần nào, hoặc bắt đầu tìm kiếm một nơi tốt hơn để làm việc. (Hoặc cả hai.)

Tôi vẫn chưa có lý do để tạo khóa ngoại

- Joel Spolsky

Bỏ các tuyên bố sang một bên, đáng để thừa nhận có những lý do chính đáng và mạnh mẽ để chọn không sử dụng tính duy nhất hoặc các ràng buộc khóa ngoại. Hầu hết đi một cái gì đó như thế này:

• Hiệu suất. Thực hiện kiểm tra tính toàn vẹn với các giao dịch nguyên tử không phải là miễn phí. Và thường xuyên, cơ sở dữ liệu là phần khó nhất trong kiến ​​trúc của bạn để mở rộng quy mô. Có lẽ bạn đã thực hiện các kiểm tra trong logic ứng dụng của mình và không muốn thực hiện cú đánh hiệu suất thứ hai.
• Thiếu nhu cầu. Có lẽ dữ liệu của bạn là bẩn, và bạn ổn với điều đó. Điều này phụ thuộc rất nhiều vào những gì bạn đang làm.

Xem thêm Có gì sai với khóa ngoại?

Nhưng những điều đó không phù hợp với lý do trong câu hỏi của bạn.

Đây là logic kinh doanh và nên được áp dụng trong lớp kinh doanh.

Lý do này hơi kỳ quặc. Tính duy nhất và các ràng buộc toàn vẹn khác là rất nhiều miền của cơ sở dữ liệu ACID. Mã ứng dụng của bạn không thể tiếp cận các đảm bảo tính nguyên vẹn và toàn vẹn của SQLServer. Nếu bạn cần toàn vẹn dữ liệu, bạn sẽ thật ngu ngốc khi bỏ qua cơ sở dữ liệu.

Một lập luận thứ hai là họ muốn áp dụng cách tiếp cận NoQuery vào việc lưu trữ dữ liệu của họ và do đó không muốn có những hạn chế như vậy.

Lý do thứ hai không thực sự là một lý do; đó là một kết luận. Mặc dù sự thật là các ràng buộc là sự đánh đổi giữa tính chính xác và hiệu năng và cơ sở dữ liệu NoQuery thiên về hướng sau.

Có lẽ kiến ​​trúc sư hệ thống của bạn có những lý do chính đáng này trong đầu, và bạn nghe nhầm. Hoặc có thể anh ta là một thằng ngốc.

Trong mọi trường hợp, có những lý do hợp lệ (mặc dù không phổ biến) để hạn chế sử dụng tính duy nhất và các ràng buộc khóa ngoài.

PS Nếu bạn kết luận rằng bạn không muốn có khóa ngoại, bạn vẫn có thể sử dụng cơ sở dữ liệu quan hệ. Là một khái quát, các cơ sở dữ liệu quan hệ đã trưởng thành hơn so với các đối tác NoQuery của họ. Là một nút duy nhất, chúng thậm chí có thể nhanh hơn và một bản tóm tắt NoQuery có thể được xây dựng trên đầu chúng .