Cơ sở dữ liệu nên thực hiện bao nhiêu logic?

Tôi đã làm việc trong một số dự án nơi phần lớn logic nghiệp vụ được triển khai trên cơ sở dữ liệu (chủ yếu thông qua các thủ tục được lưu trữ). Mặt khác, tôi đã nghe từ một số lập trình viên đồng nghiệp rằng đây là một thực tiễn tồi ("Cơ sở dữ liệu ở đó để lưu trữ dữ liệu. Các ứng dụng ở đó để làm phần còn lại").

Phương pháp nào trong số này thường tốt hơn?

Ưu điểm của việc triển khai logic nghiệp vụ trong DB tôi có thể nghĩ đến là:

• Tập trung logic kinh doanh;
• Độc lập về loại ứng dụng, ngôn ngữ lập trình, HĐH, v.v;
• Cơ sở dữ liệu ít bị di chuyển công nghệ hoặc tái cấu trúc lớn (AFAIK);
• Không làm lại về di chuyển công nghệ ứng dụng (ví dụ: .NET sang Java, Perl sang Python, v.v.).

Nhược điểm:

• SQL kém năng suất và phức tạp hơn đối với lập trình logic nghiệp vụ, do thiếu các thư viện và cấu trúc ngôn ngữ, các ngôn ngữ hướng ứng dụng nhất cung cấp;
• Việc sử dụng lại mã khó khăn hơn (nếu có thể) thông qua các thư viện;
• IDE kém năng suất.

Lưu ý: Các cơ sở dữ liệu tôi đang nói đến là các cơ sở dữ liệu quan hệ, phổ biến như SQL Server, Oracle, MySql, v.v.

Cảm ơn!

Logic nghiệp vụ không đi vào cơ sở dữ liệu

Nếu chúng ta đang nói về các ứng dụng đa tầng, có vẻ như khá rõ ràng rằng logic kinh doanh, loại trí thông minh điều hành một doanh nghiệp cụ thể, thuộc về Lớp logic nghiệp vụ, không phải trong Lớp truy cập dữ liệu.

Cơ sở dữ liệu làm một số điều thực sự tốt:

1. Họ lưu trữ và lấy dữ liệu
2. Họ thiết lập và thực thi các mối quan hệ giữa các thực thể dữ liệu khác nhau
3. Họ cung cấp phương tiện để truy vấn dữ liệu để trả lời
4. Họ cung cấp tối ưu hóa hiệu suất.
5. Họ cung cấp kiểm soát truy cập

Bây giờ, tất nhiên, bạn có thể mã hóa tất cả các loại trong cơ sở dữ liệu liên quan đến mối quan tâm kinh doanh của bạn, những thứ như thuế suất, giảm giá, mã hoạt động, danh mục, v.v. Nhưng hành động kinh doanh được thực hiện trên dữ liệu đó thường không được mã hóa vào cơ sở dữ liệu, vì tất cả các loại lý do đã được người khác đề cập, mặc dù một hành động có thể được chọn trong cơ sở dữ liệu và được thực hiện ở nơi khác.

Và tất nhiên, có thể có những thứ được thực hiện trong cơ sở dữ liệu để thực hiện và các lý do khác:

1. Kết thúc kỳ kế toán
2. Số giòn
3. Quy trình hàng đêm
4. Thất bại

Đương nhiên, không có gì được khắc trên đá. Thủ tục lưu trữ phù hợp cho một loạt các nhiệm vụ đơn giản vì chúng sống trên máy chủ cơ sở dữ liệu và có những điểm mạnh và lợi thế nhất định.

Thủ tục lưu trữ ở mọi nơi

Có một sức hấp dẫn nhất định để mã hóa tất cả các tác vụ lưu trữ, quản lý và truy xuất dữ liệu của bạn trong các thủ tục được lưu trữ và chỉ đơn giản là tiêu thụ các dịch vụ dữ liệu kết quả. Bạn chắc chắn sẽ được hưởng lợi từ tối ưu hóa hiệu suất và bảo mật tối đa có thể có mà máy chủ cơ sở dữ liệu có thể cung cấp, và đó không phải là chuyện nhỏ.

Nhưng bạn có nguy cơ gì?

1. Nhà cung cấp khóa
2. Sự cần thiết cho các nhà phát triển với bộ kỹ năng đặc biệt
3. Công cụ lập trình Spartan, tổng thể
4. Khớp nối phần mềm cực kỳ chặt chẽ
5. Không tách rời mối quan tâm

Và tất nhiên, nếu bạn cần một dịch vụ web (có lẽ đây là nơi tất cả đều hướng đến), bạn vẫn sẽ phải xây dựng nó.

Vậy thực hành điển hình là gì?

Tôi muốn nói rằng một cách tiếp cận hiện đại, điển hình là sử dụng Trình ánh xạ quan hệ đối tượng (như Entity Framework) để tạo các lớp mô hình hóa các bảng của bạn. Sau đó, bạn có thể nói chuyện với cơ sở dữ liệu của mình thông qua kho lưu trữ trả về các bộ sưu tập các đối tượng, một tình huống rất quen thuộc với bất kỳ nhà phát triển phần mềm có thẩm quyền nào. ORM tự động tạo SQL tương ứng với mô hình dữ liệu của bạn và thông tin được yêu cầu, sau đó máy chủ cơ sở dữ liệu sẽ xử lý để trả về kết quả truy vấn.

Làm thế nào tốt công việc này? Rất tốt, và nhanh hơn nhiều so với việc viết các thủ tục và quan điểm được lưu trữ. Điều này thường bao gồm khoảng 80% yêu cầu truy cập dữ liệu của bạn, chủ yếu là CRUD. Những gì bao gồm 20% khác? Bạn đoán nó: các thủ tục được lưu trữ, mà tất cả các ORM chính hỗ trợ trực tiếp.

Bạn có thể viết một trình tạo mã thực hiện tương tự như ORM, nhưng với các thủ tục được lưu trữ không? Chắc chắn bạn có thể. Nhưng ORM thường độc lập với nhà cung cấp, được mọi người hiểu rõ và được hỗ trợ tốt hơn.

Tôi là một người tin tưởng mạnh mẽ trong việc giữ logic kinh doanh ra khỏi cơ sở dữ liệu càng nhiều càng tốt. Tuy nhiên, là nhà phát triển hiệu suất của công ty tôi, tôi đánh giá cao rằng đôi khi cần phải đạt được hiệu suất tốt. Nhưng tôi nghĩ rằng nó là cần thiết ít thường xuyên hơn nhiều so với mọi người yêu cầu.

Tôi tranh chấp ưu và nhược điểm của bạn.

Bạn tuyên bố rằng nó tập trung logic kinh doanh của bạn. Trái lại, tôi nghĩ nó phân cấp nó. Trong một sản phẩm mà tôi hiện đang làm việc, chúng tôi sử dụng quy trình được lưu trữ cho rất nhiều logic kinh doanh của chúng tôi. Nhiều vấn đề hiệu suất của chúng tôi đến từ các chức năng gọi liên tục. Ví dụ

select <whatever>
from group g
where fn_invoker_has_access_to_group(g.group_id)

Vấn đề với cách tiếp cận này là nó thường (có thể có trường hợp sai) buộc cơ sở dữ liệu chạy chức năng của bạn N lần, mỗi lần một hàng. Đôi khi chức năng đó là đắt tiền. Một số cơ sở dữ liệu hỗ trợ các chỉ mục chức năng. Nhưng bạn không thể lập chỉ mục mọi chức năng có thể theo mọi đầu vào có thể. Hay bạn có thể?

Một giải pháp phổ biến cho vấn đề trên là trích xuất logic từ hàm và hợp nhất nó vào truy vấn. Bây giờ bạn đã phá vỡ đóng gói và logic trùng lặp.

Một vấn đề khác tôi thấy là gọi các thủ tục được lưu trữ trong một vòng lặp bởi vì không có cách nào để tham gia hoặc giao cắt các tập kết quả được lưu trữ.

declare some_cursor
while some_cursor has rows
    exec some_other_proc
end

Nếu bạn kéo mã từ Proc lồng nhau ra, thì bạn lại phân cấp. Do đó, bạn buộc phải lựa chọn giữa đóng gói và hiệu suất.

Nói chung, tôi thấy rằng cơ sở dữ liệu rất tệ ở:

1. Tính toán
2. Lặp lại (chúng được tối ưu hóa cho các hoạt động thiết lập)
3. Cân bằng tải
4. Phân tích cú pháp

Cơ sở dữ liệu tốt về:

1. Khóa và mở khóa
2. Duy trì dữ liệu và mối quan hệ của họ
3. Đảm bảo tính toàn vẹn

Bằng cách thực hiện các hoạt động đắt tiền như vòng lặp và phân tích chuỗi và giữ chúng trong lớp ứng dụng của bạn, bạn có thể mở rộng quy mô ứng dụng của mình để có hiệu suất tốt hơn. Thêm nhiều máy chủ ứng dụng đằng sau bộ cân bằng tải thường rẻ hơn nhiều so với thiết lập sao chép cơ sở dữ liệu.

Tuy nhiên, bạn đã đúng, nó tách riêng logic kinh doanh của bạn khỏi ngôn ngữ lập trình của ứng dụng, nhưng tôi không hiểu tại sao đó là một lợi thế. Nếu bạn có một ứng dụng Java, thì bạn có một ứng dụng Java. Chuyển đổi một loạt mã Java thành các thủ tục được lưu trữ không làm thay đổi thực tế rằng bạn có một ứng dụng Java.

Sở thích của tôi là giữ mã cơ sở dữ liệu tập trung vào sự kiên trì. Làm thế nào để bạn tạo một widget mới? Bạn phải chèn vào 3 bảng và chúng phải nằm trong một giao dịch. Đó là trong một thủ tục lưu trữ.

Xác định những gì có thể được thực hiện đối với một tiện ích và các quy tắc kinh doanh để tìm các tiện ích thuộc về ứng dụng của bạn.

Tôi đã làm việc ở 2 công ty khác nhau có tầm nhìn khác nhau về chủ đề này.

Đề nghị cá nhân của tôi sẽ là sử dụng Thủ tục lưu trữ khi thời gian thực hiện là quan trọng (hiệu suất). Vì Thủ tục lưu trữ được biên dịch, nếu bạn có logic phức tạp để truy vấn dữ liệu, tốt hơn hết là giữ nó trên cơ sở dữ liệu. Ngoài ra, nó sẽ chỉ gửi dữ liệu cuối cùng đến chương trình của bạn vào cuối.

Mặt khác, tôi nghĩ logic của một chương trình phải luôn nằm trong chính phần mềm. Tại sao? Bởi vì một chương trình cần phải được kiểm tra và tôi không nghĩ rằng có một cách dễ dàng để kiểm tra đơn vị thủ tục lưu trữ. Đừng quên, một chương trình không được kiểm tra là một chương trình tồi.

Vì vậy, sử dụng Thủ tục lưu trữ một cách thận trọng, khi cần thiết.

Có một nền tảng mà bạn cần tìm. Tôi đã thấy các dự án đáng sợ trong đó các lập trình viên sử dụng cơ sở dữ liệu không gì khác hơn là một kho lưu trữ khóa / giá trị quá cao. Tôi đã thấy những người khác mà các lập trình viên không sử dụng khóa và chỉ mục nước ngoài. Ở đầu kia của quang phổ, tôi đã thấy các dự án mà hầu hết logic kinh doanh không được triển khai trong mã cơ sở dữ liệu.

Như bạn đã lưu ý, T-SQL (hoặc tương đương với các RDBMS phổ biến khác) không chính xác là nơi tốt nhất để mã hóa logic kinh doanh phức tạp.

Tôi cố gắng xây dựng một mô hình dữ liệu hợp lý, sử dụng các tính năng của cơ sở dữ liệu để bảo vệ các giả định của tôi về mô hình đó (ví dụ, FK và các ràng buộc) và sử dụng mã cơ sở dữ liệu một cách tiết kiệm. Mã cơ sở dữ liệu rất hữu ích khi bạn cần một cái gì đó (ví dụ: một khoản tiền) mà cơ sở dữ liệu rất tốt để làm và có thể giúp bạn không phải di chuyển hàng triệu bản ghi qua dây khi bạn không cần chúng.

Nếu logic kinh doanh của bạn liên quan đến các hoạt động tập hợp, rất có thể là một vị trí tốt cho nó nằm trong cơ sở dữ liệu vì các hệ thống cơ sở dữ liệu thực sự tốt trong việc thực hiện các hoạt động của tập hợp.

http://en.wikipedia.org/wiki/set_operations_(SQL)

Nếu logic nghiệp vụ liên quan đến một số loại tính toán thì có lẽ nó nằm ngoài quy trình cơ sở dữ liệu / cửa hàng vì cơ sở dữ liệu không thực sự được thiết kế để lặp và tính toán.

Mặc dù đây không phải là những quy tắc khó và nhanh, nhưng đây là điểm khởi đầu tốt.

Không có ai trả lời đúng cho điều này. Nó phụ thuộc vào những gì bạn sử dụng cơ sở dữ liệu cho. Trong một ứng dụng doanh nghiệp, bạn cần logic trong cơ sở dữ liệu thông qua các khóa ngoài, các ràng buộc, trình kích hoạt, v.v. bởi vì đó là nơi duy nhất mà tất cả các ứng dụng có thể chia sẻ mã. Hơn nữa, việc đưa logic cần thiết vào mã thường có nghĩa là cơ sở dữ liệu không nhất quán và dữ liệu có chất lượng kém. Điều đó có vẻ tầm thường đối với một nhà phát triển ứng dụng, người chỉ đồng tình với cách thức hoạt động của GUI, nhưng tôi đảm bảo với bạn rằng những người cố gắng sử dụng dữ liệu trong các báo cáo tuân thủ thấy rất phiền phức và tốn kém khi họ bị phạt hàng tỷ đô la vì có dữ liệu không Không tuân theo các quy tắc chính xác.

Trong một môi trường không có quy định khi bạn không quan tâm nhiều đến toàn bộ hồ sơ và chỉ một hoặc hai ứng dụng truy cập vào cơ sở dữ liệu, có thể bạn có thể thoát khỏi việc giữ tất cả trong ứng dụng.

Sau một vài năm, câu hỏi vẫn còn quan trọng ...

Quy tắc đơn giản đối với tôi: nếu đó là một ràng buộc logic hoặc một biểu thức phổ biến (câu lệnh đơn), hãy đặt nó vào cơ sở dữ liệu (vâng, các khóa ngoại và kiểm tra các ràng buộc cũng là logic nghiệp vụ!). Nếu đó là thủ tục, bằng cách chứa các vòng lặp và các nhánh có điều kiện (và thực sự không thể thay đổi thành biểu thức), hãy đặt nó vào mã.

Tránh đổ rác DB

Các nỗ lực đặt thực sự tất cả logic nghiệp vụ vào mã ứng dụng có thể sẽ làm suy giảm cơ sở dữ liệu (quan hệ) thành một bãi rác, trong đó thiết kế quan hệ chủ yếu bị bỏ qua hoàn toàn, trong đó dữ liệu có thể có bất kỳ trạng thái không nhất quán nào và thiếu chuẩn hóa (thường chủ yếu là XML, JSON , CSV vv cột thùng rác).

Loại logic chỉ dành cho ứng dụng này có lẽ là một trong những lý do chính cho sự phát triển của NoQuery - tất nhiên với nhược điểm là ứng dụng phải tự xử lý tất cả logic, thứ đã được tích hợp vào DB trong nhiều thập kỷ. Tuy nhiên, cơ sở dữ liệu NoQuery phù hợp hơn cho loại xử lý dữ liệu này, ví dụ, các tài liệu dữ liệu duy trì một "tính toàn vẹn quan hệ" tiềm ẩn trong chính chúng. Đối với các DB quan hệ, nó chỉ đơn giản là lạm dụng, gây ra nhiều rắc rối hơn bao giờ hết.

Biểu thức (dựa trên tập hợp) thay vì mã thủ tục

Trong trường hợp tốt nhất, mọi truy vấn hoặc thao tác dữ liệu nên được mã hóa dưới dạng biểu thức, thay vì mã thủ tục. Một hỗ trợ tuyệt vời cho điều này là khi các ngôn ngữ lập trình hỗ trợ các biểu thức, chẳng hạn như LINQ trong thế giới .NET (thật không may, hiện tại chỉ có các truy vấn, không có thao tác). Về phía DB quan hệ, nó đã được dạy từ lâu, để thích các biểu thức câu lệnh SQL hơn các vòng lặp con trỏ thủ tục. Vì vậy, DB có thể tối ưu hóa, thực hiện thao tác song song hoặc bất cứ điều gì có thể hữu ích.

Sử dụng các cơ chế toàn vẹn dữ liệu DB

Khi nói đến RDBMS với các ràng buộc Khóa ngoài và Kiểm tra, các cột được tính toán, có thể kích hoạt và các khung nhìn, đây là nơi lưu trữ logic nghiệp vụ cơ bản trong cơ sở dữ liệu. Chuẩn hóa đúng cách giúp duy trì tính toàn vẹn dữ liệu, để đảm bảo một trường hợp duy nhất và khác biệt của dữ liệu. Ngay cả khi bạn phải sao chép nó trong mã và DB, các cơ chế toàn vẹn dữ liệu cơ bản này không nên bị bỏ qua!

Thủ tục lưu trữ?

Ngày nay, các thủ tục lưu trữ hiếm khi cần thiết, vì cơ sở dữ liệu giữ các kế hoạch thực thi được biên dịch cho SQL và sử dụng lại chúng khi cùng một truy vấn xuất hiện trở lại, chỉ với các tham số khác nhau. Vì vậy, đối số tiền biên dịch cho SP không còn hợp lệ. Người ta có thể lưu trữ hoặc tự động tạo các truy vấn SQL trong ứng dụng hoặc ORM, phần lớn sẽ tìm thấy các gói truy vấn được biên dịch trước hầu hết thời gian. SQL là một ngôn ngữ biểu thức, miễn là bạn không sử dụng rõ ràng các yếu tố thủ tục. Vì vậy, trong trường hợp tốt nhất, bạn sử dụng các biểu thức mã có thể được dịch sang SQL.

Mặc dù phía ứng dụng, bao gồm ORM được tạo, SQL, không còn bên trong cơ sở dữ liệu, không giống như Thủ tục lưu trữ, tôi vẫn tính nó là mã cơ sở dữ liệu. Bởi vì nó vẫn đòi hỏi kiến ​​thức về SQL và cơ sở dữ liệu (trừ CRUD đơn giản nhất) và, nếu được áp dụng đúng cách, sẽ hoạt động khác rất nhiều so với mã thủ tục thường được tạo bằng các ngôn ngữ lập trình như C # hoặc Java.

Nó thực sự phụ thuộc vào doanh nghiệp, văn hóa và di sản của nó. Xem xét kỹ thuật sang một bên (những điều này đã được đề cập từ cả hai phía), các câu trả lời được đưa ra cho bạn biết rằng nó đến từ nơi mọi người đến. Trong một số tổ chức, dữ liệu là vua và DBA là một nhân vật quyền lực. Đây là môi trường tập trung điển hình của bạn, một trung tâm dữ liệu với một loạt các thiết bị đầu cuối được gắn vào nó. Sự ưa thích trong loại môi trường này là rõ ràng. Máy tính để bàn có thể thay đổi hoàn toàn nhiều lần trước khi có bất kỳ thay đổi nào trong trung tâm dữ liệu và sẽ có rất ít ở giữa.

Đầu kia của quang phổ là kiến ​​trúc 3 tầng thuần túy. Hoặc có thể đa tầng trong một doanh nghiệp định hướng web. Bạn có thể sẽ nghe một câu chuyện khác nhau ở đây. DBA, nếu có, sẽ chỉ là một nhiệm vụ phụ thực hiện một số nhiệm vụ hành chính.

Một nhà phát triển ứng dụng thời hiện đại sẽ có nhiều mối quan hệ hơn với mô hình thứ hai. Nếu bạn lớn lên với một hệ thống máy khách-máy chủ lớn, bạn có thể sẽ ở trong trại khác.

Thường có rất nhiều yếu tố liên quan đến môi trường phi kỹ thuật liên quan ở đây, không có câu trả lời chung cho câu hỏi này.

Thuật ngữ kinh doanh logic là mở để giải thích. Khi xây dựng hệ thống, chúng tôi muốn đảm bảo tính toàn vẹn của cơ sở dữ liệu và nội dung của nó. Bước đầu tiên cần có các cấp quyền truy cập người dùng khác nhau. Một ví dụ rất đơn giản, chúng ta hãy xem xét một ứng dụng ATM.

Để có được số dư tài khoản, thực hiện chọn trên một chế độ xem phù hợp sẽ ổn. Nhưng để chuyển tiền, bạn sẽ muốn giao dịch được gói gọn bằng một thủ tục được lưu trữ. Logic kinh doanh không được phép cập nhật trực tiếp các bảng cho số tiền tín dụng và ghi nợ.

Trong ví dụ này, logic nghiệp vụ có thể kiểm tra số dư trước khi yêu cầu chuyển hoặc đơn giản là gọi Proc được lưu trữ để chuyển và báo cáo lỗi. IMHO, logic kinh doanh, trong ví dụ này, nên kiểm tra trước xem có đủ tiền không và tài khoản mục tiêu có tồn tại và chỉ sau đó gọi tiền chuyển. Nếu một khoản ghi nợ khác xảy ra giữa các bước ban đầu và lệnh gọi Proc được lưu trữ, chỉ sau đó, một lỗi sẽ được trả lại.