Là thời đại của logic miền trong cơ sở dữ liệu hơn? [đóng cửa]

Gần đây tôi đã vấp phải ý kiến này từ năm 2016 nói rằng vẫn còn trường hợp logic miền trong cơ sở dữ liệu.

Tôi nghĩ rằng điều này là hoàn toàn lỗi thời. Tôi chỉ tự hỏi liệu anh chàng vẫn còn sống trong những năm 90 hay điều này có thể thực sự đúng. Đặt các hệ thống di sản sang một bên.

Điều gì về việc có logic miền trong cơ sở dữ liệu vì yêu cầu bảo mật. Đó thực sự là một điều để làm?

Các lập trình viên ngày nay dường như suy nghĩ rất giáo điều, đặc biệt là khi họ đọc những suy nghĩ mà người khác viết trên blog của họ.

Lấy ví dụ về blog Clean Coding của Bob Martin. Theo quan sát chung, tôi thấy các tác phẩm của Bob Martin khá rõ ràng và sáng suốt, vì vậy nó gây khó khăn cho tôi rằng mọi người liên tục bị nhầm lẫn bởi những điều ông viết, chẳng hạn như các nguyên tắc RẮN. Họ bị treo lên về "Trách nhiệm duy nhất" là gì, hoặc tại sao một số lớp vi phạm nguyên tắc của Liskov, khi điều họ có thể nên làm chỉ đơn giản là cố gắng viết mã tốt hơn và có được một số kinh nghiệm trước tiên, để họ đọc được blog có một số bối cảnh.

Về cơ bản những gì bạn đang nói là cơ sở dữ liệu nên chứa các bảng và dữ liệu, và đó là tất cả những gì nó nên chứa. Nhưng cơ sở dữ liệu rất phù hợp để thực hiện một số điều mà ... tốt, cơ sở dữ liệu rất tốt.

Bài báo trích dẫn những điều sau:

• Tính toàn vẹn và xác thực dữ liệu (ví dụ: các ràng buộc null và duy nhất)
• Bảo mật cấp hàng
• Viết API bằng thủ tục lưu trữ
• Tính toán số dư
• Đặt câu hỏi cho cơ sở dữ liệu (nghĩa là truy vấn và báo cáo)
• Tránh các vấn đề ORM như N + 1

như những điều phù hợp để đưa vào cơ sở dữ liệu. Tôi tình cờ đồng ý với anh.

Những lý do bạn không đưa logic kinh doanh (nói chung) vào cơ sở dữ liệu:

• Nhà cung cấp khóa
• Cơ sở dữ liệu của bạn không phải là cơ quan trung ương
• Nhóm của bạn không suy nghĩ liên quan
• Dụng cụ kém hơn.

Nhưng những điều này thường chỉ áp dụng cho những kỹ thuật, công cụ và đào tạo mà cơ sở dữ liệu không phù hợp nhất.

Vì vậy, như với bất kỳ kỹ thuật khác trong phát triển phần mềm, nó phụ thuộc. Bạn đánh giá các lựa chọn thay thế của mình và đưa ra quyết định dựa trên những gì bạn tin là hướng hành động tốt nhất có thể cho ứng dụng cụ thể của bạn.

Thời đại của ngựa và lỗi đã qua, nhưng bạn vẫn có thể mua roi buggy.

Tại sao? Khi xe ô tô nhanh hơn, rẻ hơn để bảo dưỡng và bỏ bê chúng sẽ không tạo ra các chuyến thăm từ xã hội nhân đạo, tại sao con ngựa và xe kéo vẫn ở quanh?

Bởi vì đôi khi bạn có những lý do khác nhau để làm một cái gì đó bên cạnh những lý do phổ biến.

Những gì bạn nên học là tại sao logic miền trong cơ sở dữ liệu gây ra vấn đề và bất cứ ai cũng có thể thoát khỏi nó. Sau đó tạo nên tâm trí của riêng bạn.

Quan điểm cá nhân của tôi:

Logic miền là về hành vi. Cơ sở dữ liệu là về sự bền bỉ, các mối quan hệ, và, tốt, dữ liệu. Khi bạn nhìn thấy nó theo cách này, các quy tắc kinh doanh không nên có trong cơ sở dữ liệu.

Mặt khác, ai cho biết cơ sở dữ liệu không thể có hành vi? Tôi đã xây dựng cơ sở dữ liệu văn phòng bằng cách sử dụng Filemaker. Mọi người gọi nó là cơ sở dữ liệu nhưng nó thực sự là một môi trường phát triển ứng dụng. Tất cả mọi thứ tích hợp liền mạch thành một, và được gọi là cơ sở dữ liệu.

Wizdom thường được tìm thấy giữa các quan điểm cực đoan. Tôi không nghi ngờ gì cả có thể được thực hiện để làm việc. Khi cố gắng tìm trung gian, thật hấp dẫn khi chỉ đi theo bầy đàn. Tôi sẽ thận trọng chống lại nó ở đây.

Một hệ thống giữ logic miền trong cơ sở dữ liệu có thể hoạt động tốt. Một hệ thống giữ logic miền ra khỏi cơ sở dữ liệu có thể hoạt động tốt. Một hệ thống kết hợp logic miền ở cả hai nơi sẽ khiến tôi phát điên. Tôi sẽ không biết nơi để đặt hành vi mới. Tôi sẽ không chắc chắn nơi để tìm hành vi cũ.

Nếu bạn vẫn không thể quyết định lật một đồng xu và lấy quyết định của nó làm phúc âm cho bất kỳ dự án cụ thể nào. Theo như tôi có thể nói rằng đồng xu biết những gì tốt nhất cũng như bất cứ ai khác.

Tôi đã có một trường hợp giải quyết nó trong lớp kinh doanh sẽ là một kẻ giết người hiệu suất thực sự.

Ứng dụng của chúng tôi khái niệm bảo mật OO bao gồm các vai trò VÀ nhóm. Và cả hai đều là cấu trúc đệ quy. Chúng tôi đã viết một thủ tục được lưu trữ để giải quyết sự cho phép của người dùng trên một đối tượng miền.

Có rất ít nhu cầu quay trở lại logic cơ sở dữ liệu. Nhưng trong trường hợp này tôi quyết định đi theo cách đó. Nhưng điều bạn luôn phải cân nhắc: Bạn từ bỏ sự trừu tượng. Ngay khi bạn có logic nghiệp vụ trong cơ sở dữ liệu, bạn có một ngày khó khăn để thay đổi lớp kiên trì của mình. Vì vậy, rất rất cẩn thận.