Việc xác thực dữ liệu có nên được thực hiện ở cấp cơ sở dữ liệu không?

Question

Tôi đang viết một số thủ tục được lưu trữ để tạo bảng và thêm dữ liệu. Một trong các trường là cột chỉ ra phần trăm. Giá trị phải là 0-100. Tôi bắt đầu suy nghĩ, "nơi xác nhận dữ liệu cho việc này được thực hiện ở đâu? Xác thực dữ liệu được thực hiện nói chung ở đâu? Có phải là trường hợp của tình huống hay không?"

Nó xảy ra với tôi rằng mặc dù hôm nay tôi đã quyết định rằng 0-100 là một giá trị hợp lệ cho tỷ lệ phần trăm, ngày mai, tôi có thể quyết định rằng bất kỳ giá trị tích cực nào là hợp lệ. Vì vậy, đây có thể là một quy tắc kinh doanh, phải không? Quy tắc kinh doanh có nên được thực hiện ở cấp cơ sở dữ liệu không?

Chỉ cần tìm hướng dẫn, chúng tôi không có dba ở đây nữa.

Answer 1

Nói chung, tôi sẽ làm kiểm chứng thực ở nhiều nơi:

1. phía khách hàng sử dụng xác nhận trên trang aspx
2. kiểm chứng thực máy chủ bên trong mã đằng sau

tôi sử dụng kiểm chứng thực cơ sở dữ liệu như một cuối cùng vì các chuyến đi cơ sở dữ liệu thường đắt hơn hai lần xác thực được thảo luận ở trên.

Tôi chắc chắn không nói "không đặt xác thực trong cơ sở dữ liệu", nhưng tôi sẽ nói, đừng để đó là nơi duy nhất bạn đặt xác thực.

Nếu dữ liệu của bạn được nhiều ứng dụng tiêu thụ, thì vị trí thích hợp nhất sẽ là tầng giữa (nên) được nhiều ứng dụng tiêu thụ.

Những gì bạn đang yêu cầu về quy tắc kinh doanh, có một chiều hướng hoàn toàn khác khi bạn bắt đầu nghĩ về toàn bộ ứng dụng của mình về quy tắc kinh doanh. Nếu câu hỏi về xác nhận đủ nhỏ, hãy làm điều đó ở những nơi riêng lẻ thay vì xây dựng một hệ thống quy tắc nghiệp vụ tập trung. Nếu nó là một hệ thống khá lớn, họ có thể xem xét một công cụ quy tắc kinh doanh cho việc này.

Answer 2

Bạn có thể hạn chế hợp lý cơ sở dữ liệu để dữ liệu luôn có ý nghĩa. Một cơ sở dữ liệu sẽ hỗ trợ nhiều ứng dụng sử dụng cùng một dữ liệu để một số hạn chế có ý nghĩa.

Tôi nghĩ rằng chi phí thực sự duy nhất khi làm như vậy sẽ là thời gian. Tôi nghĩ rằng những hạn chế như vậy không phải là một vấn đề lớn trừ khi bạn đang làm điều gì đó điên rồ. Và, bạn có thể thay đổi các quy tắc sau này nếu cần (mặc dù một số thay đổi rõ ràng là khó hơn những người khác)

Answer 3

Nó sẽ phụ thuộc vào cách bạn tương tác với cơ sở dữ liệu, IMO. Ví dụ, nếu cách duy nhất để cơ sở dữ liệu là thông qua ứng dụng của bạn, sau đó chỉ cần làm xác nhận ở đó.

Nếu bạn định cho phép các ứng dụng khác cập nhật cơ sở dữ liệu, bạn có thể muốn xác thực trong cơ sở dữ liệu, cho dù dữ liệu ở đó được xác nhận ở mức thấp nhất.

Tuy nhiên, xác thực phải tiếp tục ở các cấp khác nhau, để cung cấp cho người dùng cơ hội nhanh nhất có thể biết rằng có sự cố.

Bạn không đề cập đến phiên bản SQL Server nào, nhưng bạn có thể xem các kiểu dữ liệu do người dùng xác định và xem điều đó có giúp ích cho bạn hay không, vì bạn có thể tập trung xác thực.

Answer 4

Tôi đã làm việc cho một cơ quan chính phủ và chúng tôi có một quy tắc kinh doanh. Tôi là một trong những DBA, và chúng tôi đã triển khai một số lượng lớn các quy tắc nghiệp vụ trong cơ sở dữ liệu; tuy nhiên, chúng tôi phải giữ chúng khá đơn giản để tránh lỗi 'đột biến' của Oracle. Mọi thứ trở nên phức tạp rất nhanh nếu bạn muốn sử dụng các trình kích hoạt để thực hiện các quy tắc nghiệp vụ trải dài trên nhiều bảng.

Quyết định của chúng tôi là triển khai các quy tắc kinh doanh trong cơ sở dữ liệu nơi chúng tôi có thể vì dữ liệu được đưa vào thông qua ứng dụng - và thông qua các tập lệnh di chuyển dữ liệu. Việc duy trì các quy tắc nghiệp vụ chỉ trong ứng dụng sẽ không làm tốt lắm khi dữ liệu cần được di trú vào cơ sở dữ liệu mới.

Tôi khuyên bạn nên triển khai quy tắc kinh doanh trong ứng dụng nhiều nhất, trừ khi bạn có dữ liệu bị sửa đổi ở nơi khác ngoài ứng dụng. Nó có thể được dễ dàng hơn để duy trì và sửa đổi các quy tắc kinh doanh của bạn theo cách đó.

Answer 5

Nói chung, tôi sẽ nghĩ rằng xác thực gần hơn là dữ liệu, thì càng tốt. Bằng cách này, nếu bạn cần phải viết lại một ứng dụng cấp cao nhất hoặc bạn có một ứng dụng thứ hai thực hiện truy cập dữ liệu, bạn không có hai bản sao của mã (có khả năng khác) hoạt động trên cùng một dữ liệu.

Answer 6

Người ta có thể làm cho một trường hợp cho:

• Trong cơ sở dữ liệu thực hiện đủ để đảm bảo tính toàn vẹn dữ liệu tổng thể (ví dụ trong SO này có thể là mọi câu hỏi/câu trả lời có ít nhất một phiên bản).

• Trong ranh giới giữa trình bày và lớp logic kinh doanh đảm bảo dữ liệu có ý nghĩa cho các logic kinh doanh (ví dụ trong SO đảm bảo đánh dấu không chứa thẻ nguy hiểm)

Nhưng người ta có thể dễ dàng thực hiện một trường hợp cho các địa điểm khác nhau trong các lớp ứng dụng cho mọi trường hợp. Triết lý tổng thể về những gì cơ sở dữ liệu ở đó có thể ảnh hưởng đến điều này (ví dụ: là phần cơ sở dữ liệu của ứng dụng nói chung, hoặc là kho dữ liệu được chia sẻ cho nhiều khách hàng).

Điều duy nhất tôi cố gắng tránh là sử dụng Trình kích hoạt trong cơ sở dữ liệu, trong khi chúng có thể giải quyết các vấn đề cũ (nếu bạn không thể thay đổi máy khách ...) chúng là trường hợp Hành động ở dạng chống mẫu.

Answer 7

Tôi nghĩ rằng xác thực dữ liệu cơ bản như bạn đã mô tả đảm bảo rằng dữ liệu đã nhập là chính xác. Các ứng dụng nên xác nhận hợp lệ dữ liệu, nhưng nó không làm tổn thương để dữ liệu được xác nhận lại trên cơ sở dữ liệu. Đặc biệt nếu có nhiều cách để truy cập cơ sở dữ liệu.

Answer 8

Nếu bạn có cấp truy cập dữ liệu tốt, gần như không quan trọng bạn đang tiếp cận phương pháp nào.

Điều đó nói rằng, một ràng buộc cơ sở dữ liệu khó khăn hơn rất nhiều để bỏ qua (cố ý hoặc vô tình) so với ràng buộc lớp ứng dụng.

Trong công việc của mình, tôi giữ logic và ràng buộc kinh doanh gần với cơ sở dữ liệu nhất có thể, đảm bảo rằng có ít điểm tiềm năng thất bại hơn. Các ràng buộc khác nhau được thực thi ở các lớp khác nhau, tùy thuộc vào bản chất của ràng buộc, nhưng mọi thứ mà có thể là trong cơ sở dữ liệu, là trong cơ sở dữ liệu.

Answer 9

Lý tưởng đầu tiên: có "gatekeeper" để tính nhất quán của dữ liệu không phụ thuộc vào từng nhà phát triển áp dụng cùng một quy tắc. Việc xác thực đơn giản như xác nhận phạm vi có thể được triển khai hợp lý trong DB. Nếu nó thay đổi ít nhất bạn có một nơi nào đó để đặt.

Sự cố là "quy tắc kinh doanh" có xu hướng phức tạp hơn nhiều. Nó có thể hữu ích để giảm tải xử lý cho tầng ứng dụng, nơi các ngôn ngữ OO có thể tốt hơn để quản lý logic phức tạp.

Bí quyết là cấu trúc tầng ứng dụng để người gác cổng rõ ràng và không bị trùng lặp.

Trong một tổ chức nhỏ (không có DBA ergo, nhỏ?) Tôi có xu hướng đưa các quy tắc kinh doanh nơi bạn có chuyên môn phát triển mạnh mẽ.

Điều này không loại trừ xác thực ban đầu ở cấp cao hơn, ví dụ: bạn có thể xác thực tất cả các cách trong giao diện người dùng để giúp người dùng làm đúng, nhưng bạn không phụ thuộc vào khi xác thực ban đầu đó - bạn vẫn có người gác cổng.

Answer 10

Nếu phần trăm của bạn luôn là 'chia một phần' (và bạn không lưu một phần và toàn bộ giá trị ở nơi khác), thì kiểm tra giá trị của nó với [0-100] là thích hợp ở cấp db. Các hạn chế bổ sung nên được áp dụng ở các cấp độ khác.

Nếu tỷ lệ phần trăm của bạn có nghĩa là một số loại tăng trưởng, thì nó có thể có bất kỳ loại giá trị nào và không được kiểm tra ở mức db.

Đó là trường hợp theo hoàn cảnh. Thông thường, bạn nên kiểm tra ở mức db chỉ ràng buộc, mà không bao giờ có thể thay đổi hoặc có giới hạn tự nhiên (như ví dụ đầu tiên).

Answer 11

Richard đúng: câu hỏi là chủ quan theo cách được hỏi tại đây.

Một điều nữa là: các trường phái tư tưởng về điều này là gì? Chúng có thay đổi theo ngành hay công nghệ không?

Tôi đã làm Ruby on Rails một chút ngay bây giờ, và ở đó, thậm chí mối quan hệ giữa các bản ghi (một đến nhiều vv) KHÔNG được tôn trọng ở cấp độ DB, chưa kể đến việc xóa tầng và tất cả những thứ đó . Không có bất kỳ loại giới hạn nào ngoài các loại dữ liệu cơ bản, cho phép DB thực hiện công việc của mình. Phần trăm của bạn không được xử lý ở cấp DB mà là ở cấp Mô hình Dữ liệu.

Vì vậy, tôi nghĩ rằng một trong những xu hướng mà chúng ta đang thấy gần đây là cung cấp thêm sức mạnh cho cấp ứng dụng. Bạn PHẢI kiểm tra dữ liệu đến máy chủ của bạn (để ở đâu đó trong cấp trình bày) và bạn MIGHT kiểm tra nó trên máy khách và bạn MIGHT kiểm tra lại trong lớp nghiệp vụ của ứng dụng của bạn. Tại sao bạn muốn kiểm tra lại ở cấp cơ sở dữ liệu?

Tuy nhiên: những điều tối ưu nhất xảy ra và đôi khi DB nhận được các giá trị "không thể" đọc mã của lớp doanh nghiệp. Vì vậy, nếu bạn đang quản lý, nói rằng, dữ liệu tài chính, tôi muốn nói để đưa vào mọi ràng buộc duy nhất có thể ở mọi cấp độ. Những người làm từ các lĩnh vực khác nhau làm gì?

Answer 12

Trong một thế giới hoàn hảo, điều duy nhất nói (cập nhật, xóa, chèn) vào cơ sở dữ liệu của bạn sẽ là api kinh doanh của bạn. Trong giới hạn cấp độ databae thế giới hoàn hảo là một sự lãng phí thời gian, dữ liệu của bạn sẽ đã được xác nhận và kiểm tra chéo trong api kinh doanh của bạn. Trong thế giới thực, chúng ta có được những chàng cao bồi lấy các phím tắt và những người khác viết trực tiếp vào cơ sở dữ liệu. Trong trường hợp này, một số ràng buộc trên cơ sở dữ liệu cũng đáng để nỗ lực. Tuy nhiên nếu bạn có người không sử dụng api của bạn để đọc/ghi bạn phải xem xét nơi bạn đã đi sai trong thiết kế api của bạn.