Quy tắc kinh doanh có nên được thực thi ở cả cấp ứng dụng và tầng cơ sở dữ liệu hay chỉ một trong hai quy tắc này không?

Question

Tôi đã thực thi các quy tắc nghiệp vụ trong cả tầng ứng dụng (mô hình) và tầng cơ sở dữ liệu của tôi (các thủ tục được lưu trữ gây ra lỗi).

Tôi đã sao chép kiểm chứng thực của tôi ở cả hai nơi trong một vài lý do:

1. Nếu các điều kiện thay đổi giữa khi họ được kiểm tra trong mã ứng dụng và khi họ kiểm tra trong cơ sở dữ liệu, kiểm tra quy tắc kinh doanh trong cơ sở dữ liệu sẽ tiết kiệm trong ngày. Cơ sở dữ liệu cũng cho phép tôi khóa các bản ghi khác nhau theo cách đơn giản hơn trong mã số ứng dụng của tôi, vì vậy dường như tự nhiên làm như vậy tại đây.
2. Nếu chúng ta có để làm một số dữ liệu hàng loạt chèn/cập nhật cơ sở dữ liệu trực tiếp, nếu tuyến đường tôi tất cả các hoạt động này thông qua thủ tục lưu trữ của tôi/chức năng mà đang làm quy tắc kinh doanh hợp lệ, không có cơ hội của tôi đưa vào dữ liệu xấu mặc dù tôi thiếu sự bảo vệ mà tôi sẽ nhận được nếu tôi đang thực hiện nhập liệu đơn thông qua ứng dụng.
3. Trong khi thực thi những điều này chỉ trong cơ sở dữ liệu sẽ có tác dụng tương tự trên các dữ liệu thực tế, có vẻ như không đúng chỉ ném dữ liệu ở cơ sở dữ liệu trước khi lần đầu tiên thực hiện một nỗ lực tốt để xác nhận rằng nó phù hợp với để các ràng buộc và quy tắc kinh doanh.

Số dư chính xác là gì?

Answer 1

Bạn cần thực thi ở cấp dữ liệu để đảm bảo tính toàn vẹn của dữ liệu. Đó là tuyến phòng thủ cuối cùng của bạn, và đó là công việc của DB, để giúp thực thi quan điểm của thế giới về dữ liệu.

Điều đó nói rằng, ném dữ liệu rác vào DB để xác thực là một kỹ thuật thô. Thông thường các lỗi được thiết kế để có thể đọc được con người chứ không phải là máy có thể đọc được, do đó, nó không hiệu quả cho chương trình để xử lý lỗi từ DB và làm cho đầu hoặc đuôi ra khỏi nó.

Thủ tục lưu trữ là một vấn đề khác. Quay trở lại trong ngày, Thủ tục lưu trữ là Cách xử lý các quy tắc kinh doanh trên các tầng dữ liệu, v.v.

Nhưng ngày nay, với môi trường máy chủ ứng dụng hiện đại, chúng trở thành một nơi tốt hơn để đặt logic này. Chúng cung cấp nhiều cách để truy cập và hiển thị dữ liệu (web, dịch vụ web, giao thức từ xa, API, v.v.). Ngoài ra, nếu các quy tắc của bạn là CPU nặng (đáng kể nhất là không) thì việc quy mô các máy chủ ứng dụng dễ dàng hơn các máy chủ DB.

Mảng lớn các tính năng trong máy chủ ứng dụng cung cấp cho họ sự linh hoạt ngoài những gì các máy chủ DB có thể thực hiện, và do đó phần lớn những gì đã từng được đẩy trở lại vào DBs đang được kéo ra với máy chủ DB bị xuống hạng " câm dai dẳng ". Điều đó nói rằng, chắc chắn có lợi thế về hiệu suất sử dụng Procs được lưu trữ và như vậy, nhưng bây giờ đó là một điều chỉnh mà câu hỏi trở thành "là nó có giá trị mất khả năng máy chủ ứng dụng để đạt được chúng tôi nhận được bằng cách đặt nó vào máy chủ DB ".

Và bởi máy chủ ứng dụng, tôi không chỉ đơn giản là nói chuyện Java, nhưng NET và thậm chí PHP vv

Answer 2

logic kinh doanh của bạn có thể ngồi ở một trong hai vị trí, nhưng không phải ở trong cả hai. Logic KHÔNG được sao chép vì rất dễ mắc lỗi khi cố giữ cả hai đồng bộ. Nếu bạn đặt nó trong mô hình, bạn sẽ muốn tất cả các truy cập dữ liệu đi qua các mô hình của bạn, bao gồm các cập nhật hàng loạt.

Sẽ có thỏa hiệp để đặt nó trong cơ sở dữ liệu vs các mô hình ứng dụng (đây là một vài trong số các đỉnh đầu của tôi):

• Cơ sở dữ liệu có thể khó duy trì và cập nhật hơn các ứng dụng
• nó dễ dàng hơn để phân phối tải nếu nó trong tầng ứng dụng
• Nhiều, dbs khác nhau có thể yêu cầu quy tắc kinh doanh tách (có thể không thực hiện được)

Answer 3

Nếu sự cai trị phải thực thi bất cứ lúc nào bất kể dữ liệu đến từ đâu hoặc cách dữ liệu được cập nhật, cơ sở dữ liệu là nơi cần. Hãy nhớ rằng cơ sở dữ liệu bị ảnh hưởng bởi truy vấn trực tiếp để thực hiện các thay đổi ảnh hưởng đến nhiều bản ghi hoặc để làm một cái gì đó mà ứng dụng sẽ không bình thường làm. Đây là những thứ như sửa một nhóm hồ sơ khi khách hàng được mua bởi khách hàng khác và họ muốn thay đổi tất cả dữ liệu lịch sử, áp dụng thuế suất mới cho các đơn đặt hàng chưa được xử lý, sửa chữa một số dữ liệu đầu vào xấu. Đôi khi chúng cũng bị ảnh hưởng bởi các ứng dụng khác không sử dụng lớp dữ liệu của bạn. Chúng cũng có thể bị ảnh hưởng bởi việc nhập khẩu chạy qua các chương trình ETL mà cũng không thể sử dụng lớp dữ liệu của bạn. Vì vậy, nếu các quy tắc phải trong tất cả các trường hợp được theo sau, nó phải có trong cơ sở dữ liệu.

Nếu quy tắc chỉ dành cho các trường hợp đặc biệt liên quan đến cách trang đầu vào cụ thể này hoạt động, thì nó cần phải có trong ứng dụng. Vì vậy, nếu người quản lý bán hàng chỉ có những thứ cụ thể mà anh ấy có thể thực hiện từ giao diện người dùng của mình, những điều này có thể được chỉ định trong ứng dụng.

Điều gì đó hữu ích khi thực hiện ở cả hai nơi. Ví dụ, nó là ngớ ngẩn để cho phép người dùng đặt một ngày không trong một hộp nhập liệu sẽ liên quan đến một trường ngày tháng. Kiểu dữ liệu trong cơ sở dữ liệu vẫn phải là một kiểu dữ liệu datetime, nhưng tốt nhất là kiểm tra một số công cụ này trước khi bạn gửi đi.