Các đối số chống lại hoặc để đưa logic ứng dụng vào lớp cơ sở dữ liệu là gì? [đóng cửa]

Hầu hết các nhà phát triển phần mềm muốn giữ logic ứng dụng trong lớp ứng dụng và có lẽ chúng tôi cảm thấy tự nhiên khi giữ nó ở đây. Các nhà phát triển cơ sở dữ liệu dường như muốn đưa logic ứng dụng vào lớp cơ sở dữ liệu, như các trình kích hoạt và các thủ tục được lưu trữ.

Cá nhân tôi muốn giữ càng nhiều càng tốt trong lớp ứng dụng để dễ gỡ lỗi hơn và giữ cho các trách nhiệm của các lớp riêng biệt.

Suy nghĩ của bạn về điều này là gì và những gì nên hoặc không nên thực hiện trong lớp cơ sở dữ liệu?

Chỉnh sửa Câu hỏi này cũng được đề cập trên dba.se , từ quan điểm của DBA. Vì lập trình viên.se & dba.se có đối tượng và thành kiến ​​khác nhau, độc giả tương lai có thể muốn xem lại cả hai bộ câu trả lời trước khi quyết định cách nào phù hợp nhất với họ.

Ra khỏi đầu tôi, lợi thế của việc đưa logic vào lớp ứng dụng.

1. Khả năng kiểm tra . Đây thực sự là một lý do đủ tốt cho chính nó.
2. Cấu trúc mã tốt hơn . Rất khó để theo kiến ​​trúc OO thích hợp với SQL. Điều này thường cũng làm cho mã dễ bảo trì hơn.
3. Mã dễ dàng hơn . Do tất cả các tính năng ngôn ngữ khác nhau có sẵn trong bất kỳ ngôn ngữ nào bạn đang sử dụng, việc mã hóa trong lớp ứng dụng thường dễ dàng hơn.
4. Mã sử ​​dụng lại . Chia sẻ mã với các thư viện dễ dàng hơn nhiều so với chia sẻ mã trong cơ sở dữ liệu.

Mặc dù có thể sử dụng kiểm soát phiên bản với các thủ tục được lưu trữ (ví dụ: các công cụ cơ sở dữ liệu Redgate tích hợp với TFS), nhưng không phải lúc nào cũng dễ dàng như với mã ứng dụng.

Vị trí mặc định của tôi là logic nên được giữ ngoài lớp cơ sở dữ liệu, tuy nhiên, đôi khi việc triển khai logic trong cơ sở dữ liệu sẽ hiệu quả hơn. Nếu đó là trường hợp thì bạn phải chắc chắn rằng bạn có thể theo dõi các thay đổi đối với mã này.

Trong một công ty nơi tôi làm việc, có rất nhiều băng đỏ liên quan đến việc phát hành mã cho sản xuất và liên quan đến một DBA để phát hành mã luôn là một cơn ác mộng. Chúng tôi luôn đặt logic trong lớp ứng dụng để loại bỏ việc phải đối phó với các DBA khó làm việc. Đó là một lý do hoàn toàn khập khiễng nhưng một lý do xuất phát từ sự cần thiết.

Đưa logic ứng dụng vào DB nghe có vẻ là một ý tưởng tồi đối với tôi. OTOH đưa logic vào DB, một phần cụ thể của việc duy trì trạng thái DB (ví dụ: kích hoạt / sprocs để cập nhật các bảng không chuẩn hóa) là một đề xuất khác nhau.

Cách khác, điều này có thể được nêu là: có những lý lẽ tốt để đưa logic cần thiết để trừu tượng hóa cách thức cơ sở dữ liệu thực sự hoạt động từ cách bạn muốn nó nhìn vào cơ sở dữ liệu.

Đọc cả hai câu hỏi, tôi nghĩ rằng tất cả chúng ta có thể đã bỏ lỡ một điểm quan trọng. Câu trả lời đúng có thể phụ thuộc vào loại phần mềm bạn đang phát triển. Nhóm DBA có xu hướng phần lớn làm việc trên các hệ thống phần mềm Doanh nghiệp quan trọng và câu trả lời của họ có xu hướng phản ánh những gì cần thiết trong thế giới đó. Có một sự khác biệt rất lớn về những gì cần thiết cho những loại ứng dụng đó so với những gì cần thiết cho ứng dụng "Facebook" tiếp theo. Sẽ không có vấn đề gì lớn nếu bạn mất một vài bài đăng trên tường, đó là nếu bạn mất một vài đơn đặt hàng hoặc các giao dịch tài chính khác.

Những người làm việc trong thế giới COTS (thương mại ngoài thị trường) có xu hướng cần phải không biết cơ sở dữ liệu vì lý do bán hàng và họ muốn mọi thứ trong mã tuân thủ sẽ gây khó khăn hơn cho kỹ sư đảo ngược và thay thế sản phẩm của họ bằng một sản phẩm gia đình. Các ứng dụng Enterprise được phát triển và bảo trì nội bộ sẽ hầu như không cần thay đổi các phụ trợ cơ sở dữ liệu ngoại trừ việc nâng cấp.

Các ứng dụng doanh nghiệp cũng là những ứng dụng có xu hướng có đầu vào từ nhiều nơi với cơ sở dữ liệu là điểm chung duy nhất. Hệ thống tôi làm việc có hàng trăm ứng dụng khác nhau truy cập vào nó cũng như hàng trăm nhập dữ liệu khách hàng, xuất dữ liệu cho khách hàng và đến kho dữ liệu và sử dụng các hệ thống báo cáo mulitple. Mã hoạt động tốt khi thêm một bản ghi bị lỗi khi tôi phải nhập 20.000.000. Chúng tôi đã buộc phải sử dụng lớp ứng dụng một lần vì đó là nơi logic và phải dừng quá trình 18 giờ sau đó chưa hoàn thành. Logic nên áp dụng cho tất cả các bản ghi dữ liệu trong một bảng cần có trong cơ sở dữ liệu khi bạn không thể có một lớp dữ liệu mà mọi người sử dụng.

Ngược lại, khi chỉ có một ứng dụng sẽ tiêu thụ dữ liệu và dữ liệu không phải là huyết mạch của công ty bạn hoặc là thông thường, các quy tắc sẽ khác nhau và đưa tất cả logic vào ứng dụng có ý nghĩa hơn.

Lâu dài. xem Tóm tắt ở phía dưới.

RDBMS

Một RDBMS là viết tắt của hệ thống quản lý cơ sở dữ liệu quan hệ. Đó là một hệ thống để quản lý một cơ sở dữ liệu quan hệ. Dữ liệu được lưu trữ ở đó. Dữ liệu. Nó không nói logic kinh doanh.

Quy trình kinh doanh

Logic kinh doanh có nghĩa là gì, thực sự? Đối với tôi, đó là mô tả về các quy trình kinh doanh theo thuật ngữ hợp lý.

Các quy trình là những hoạt động kinh doanh diễn ra thường xuyên, đủ để chúng không còn đặc biệt nữa. Đây là khác nhau cho mỗi doanh nghiệp.

Hãy để tôi đặt giới hạn kinh doanh của tôi và giải thích ý nghĩa kinh doanh ở đây. Đối với một số người, điều này có thể đến như một bất ngờ.

Kinh doanh

Kinh doanh là tổng hợp các hoạt động được thực hiện để đạt được việc tạo ra giá trị và cụ thể hơn là giá trị có thể được giao dịch. Điều này có thể có nghĩa là làm cho máy gặt đập liên hợp, bánh mì kẹp cá ngừ hoặc cung cấp dịch vụ ngân hàng. Ở hầu hết các quốc gia trên thế giới, ngay cả những người trong các hệ thống phi tư bản, mọi người muốn nhận được giá trị cao nhất cho tiền của họ, và do đó có sự cạnh tranh giữa các nhà cung cấp khác nhau của các hàng hóa và dịch vụ có giá trị này. Sự cạnh tranh thường xoay quanh giá cả, chất lượng và tính sẵn có.

Đường vòng nhanh: Bạn cần 40 triệu đinh tán trong 2 ngày, bạn sẽ không đặt hàng từ một người nào đó trên internet bằng tài khoản paypal, bất kể giá của anh ta rẻ hơn nhà cung cấp bình thường của bạn bao nhiêu.

Quy trình kiến ​​thức

Như bạn có thể tưởng tượng, các quy trình liên quan đến việc tạo ra "giá trị" này chủ yếu sống trong những người đứng đầu điều hành. Một số trong đó được đặt trên giấy và được sử dụng như các chính sách và thủ tục của công ty. Một số trong đó sống trong những người đứng đầu của tư vấn doanh nghiệp. Rất nhiều trong số đó sống trong đầu của những người điều hành các bộ phận, phòng ban, đội, và những người chạy máy móc, máy tính tiền, lò nướng, xe tải. Một tập hợp con nhỏ đã làm giảm các yêu cầu nghiệp vụ đối với phần mềm và một tập hợp con nhỏ hơn nữa chính xác theo thời gian nó được triển khai trong các hệ thống máy tính.

Cuối cùng, logic kinh doanh mà bạn thấy trong mã không phải là điều hành một doanh nghiệp, mà là chạy ứng dụng cho doanh nghiệp. Bộ não thực tế bên trong con người thực tế nắm giữ các quy trình kinh doanh thực tế và họ không có vấn đề gì khi hiểu rằng quy trình trong não của họ chính xác hơn quy trình trong máy tính. Bên cạnh đó, bạn có thể không thể điều hành doanh nghiệp nếu tất cả những gì bạn có là chính sách và thủ tục của hầu hết các tập đoàn. Rất thường những điều này là không chính xác, mặc dù những nỗ lực phi thường.

Vì vậy, cuối cùng, đó là logic ứng dụng được mã hóa vào phần mềm. Và mọi người muốn đưa nó vào cơ sở dữ liệu, bởi vì các nhà cung cấp hệ thống quản lý cơ sở dữ liệu đã đưa ra những tuyên bố hoành tráng.

Logic ứng dụng

Tôi nói là không. Tôi nói logic ứng dụng ở lại trong ứng dụng. Dữ liệu đi vào cơ sở dữ liệu, theo cách rất được chuẩn hóa, và sau đó được ETL'd đến cơ sở dữ liệu để báo cáo, khoan và cuộn và cuộn và xoay vòng.

Dữ liệu

Tôi cũng nói rằng dữ liệu tồn tại lâu hơn ứng dụng, vì vậy nỗ lực chuẩn hóa dữ liệu không nên là ứng dụng cụ thể và thậm chí không dành riêng cho doanh nghiệp, mà nên nói chung là kinh doanh. Bạn có lưu trữ mã nhà nước? Bạn nên sử dụng THU NHẬP 38: 2009 (http://www.cencies.gov/geo/www/ansi/statetables.html) vì đó là di động giữa các doanh nghiệp. Điều này cũng giúp nhiều ứng dụng thao tác dữ liệu dễ dàng hơn.

Không có vấn đề gì?

Nếu bạn coi cơ sở dữ liệu là một phần của mã của ứng dụng, từ cách bố trí bảng đến trình kích hoạt, quy trình được lưu trữ và định dạng dữ liệu, thì về cơ bản bạn đang sử dụng cơ sở dữ liệu doanh nghiệp như một BerkleyDB được tôn vinh, là cấu trúc tệp phẳng được tôn vinh, đó thực sự chỉ là danh sách tồn tại. Đây thực chất là những gì NoQuery đang làm: quay trở lại cội nguồn, nhưng thực hiện nó theo cách đa quy trình, bền bỉ, không chịu thất bại.

Mã thực tế

Không, bạn cần coi cơ sở dữ liệu là kho lưu trữ dữ liệu chung cho nhiều ứng dụng, cả hiện tại và tương lai. Bây giờ chúng ta đi đến mấu chốt của lập luận của tôi. Các quy trình kinh doanh thay đổi với sự mơ hồ của thị trường, chính trị và thời trang. Rất thường họ thay đổi nhanh hơn những gì các lập trình viên có thể quản lý bằng các ngôn ngữ cấp khoa học máy tính (Java, C #, C ++, v.v.) và cuối cùng được viết bằng VBA trong bảng tính excel trong bộ phận kế toán hoặc tiếp thị. (Và chỉ khi nó không thể được thể hiện trong những cái nhìn lạ mắt ...)

Suy thoái cơ sở dữ liệu

Dữ liệu không thay đổi nhiều nếu được tổ chức tốt. Logic kinh doanh thay đổi rất nhanh. Bằng cách đưa logic nghiệp vụ vào cơ sở dữ liệu, bạn làm cho cơ sở dữ liệu trở nên ít giá trị hơn, bởi vì nó sẽ trở nên lỗi thời và không chính xác sớm hơn.

Tóm lược

Dữ liệu phải tồn tại lâu hơn ứng dụng vì các quy trình kinh doanh sống trong ứng dụng và quy trình kinh doanh thay đổi thường xuyên hơn nhiều. Bao gồm logic kinh doanh trong cơ sở dữ liệu là xấu cho tuổi thọ và giá trị tổng thể của nó.

Hãy cẩn thận

Tôi đã thực hiện phần chia sẻ của mình về dba-ing và tôi đã đọc câu trả lời tại dba.se nhưng thật lòng mà nói họ đang nói đến là vấn đề toàn vẹn dữ liệu và vấn đề hiệu suất. Tôi hoàn toàn đồng ý rằng những người chạm vào dữ liệu của công ty nên biết họ đang làm gì, cho dù là dba hay lập trình viên hay nhà phân tích cao cấp của SAS có quyền truy cập đọc / ghi.

Tôi cũng lưu ý rằng họ khuyên các lập trình viên biết SQL. Tôi đồng ý. Đó là ngôn ngữ lập trình máy tính, vì vậy tôi không hiểu tại sao các lập trình viên máy tính không muốn biết nó.

Sau này, sau khi nghĩ về nó

Tôi nghĩ rằng nền tảng trung gian là tạo ra một API và để API đó quản lý luồng dữ liệu qua lại. Nếu bạn không thể cho phép các ứng dụng kết nối trực tiếp với các bảng, ít nhất bạn có thể làm cho cơ chế truy cập bằng các ngôn ngữ hiện đại.

Có nguy cơ nghe có vẻ kịch tính, tôi thực sự kinh hoàng với ý tưởng logic ứng dụng trong cơ sở dữ liệu. Rất nhiều câu trả lời ở đây đã tập trung vào các lợi thế phát triển phần mềm, vì vậy vì lợi ích của sự ngắn gọn, tôi sẽ tập trung vào các lợi thế do sự phân chia trách nhiệm mang lại.

Cơ sở dữ liệu cung cấp một phương tiện lưu trữ và truy cập thông tin hiệu quả, đồng thời giảm thiểu dữ liệu dư thừa và tạo ra các mối quan hệ logic trong dữ liệu. Mặc dù logic cơ sở dữ liệu có thể có khả năng triển khai logic nghiệp vụ ở mức sản xuất, ý kiến ​​cá nhân của tôi là cơ sở dữ liệu phải có tính ứng dụng cao nhất có thể để đảm bảo rằng dữ liệu có thể được tận dụng hiệu quả bởi nhiều ứng dụng trong khi chơi với các thế mạnh tương ứng của cơ sở dữ liệu động cơ so với thế mạnh của ngôn ngữ thực hiện của ứng dụng.

Một người dùng trên sàn giao dịch ngăn xếp DBA đã tuyên bố điều này ...

Tôi muốn tất cả logic phải áp dụng cho tất cả người dùng và tất cả các ứng dụng trong cơ sở dữ liệu. Đó là nơi duy nhất lành mạnh để đặt nó.

Fortune 500 cuối cùng tôi làm việc có các ứng dụng được viết bằng ít nhất 25 ngôn ngữ đánh vào cơ sở dữ liệu OLTP của họ. Một số chương trình đã chuyển sang sản xuất vào những năm 1970.

... Tiếp theo là niềm tin của anh ta rằng đây là dấu hiệu của việc vi phạm nguyên tắc DRY.

Thay vì là sự lặp lại của logic kinh doanh, tôi nghĩ rằng đây rất có thể là một ví dụ hoàn hảo về tính linh hoạt được cung cấp bởi sự phân chia trách nhiệm khác biệt giữa lớp doanh nghiệp và lớp dữ liệu.

Cơ sở dữ liệu OLTB của họ đã cung cấp dữ liệu đáng tin cậy và hiệu quả cho hơn 25 ứng dụng trong nhiều thập kỷ! Thật đáng kinh ngạc! (Con đường để đi!)

Tôi chỉ có thể giả định rằng dữ liệu đủ bất khả tri để cung cấp nội dung cho một số ứng dụng riêng biệt. Một cái gì đó phần lớn là không thể nếu những nhà phát triển đó cố gắng hack một cái gì đó cùng nhau bằng logic cơ sở dữ liệu.

Như các câu trả lời khác đã chỉ ra, có nhiều lý do khác để không thực hiện một chương trình trong cơ sở dữ liệu. Tôi chắc chắn rằng nó sẽ hoạt động, nhưng kết quả có thể xảy ra nhất sẽ là hàng thập kỷ hối tiếc, thay vì hàng thập kỷ ổn định.

Các ứng dụng bất khả tri của cơ sở dữ liệu yêu cầu tất cả logic ra khỏi cơ sở dữ liệu. Rất khó để xây dựng và duy trì mã cho nhiều nhà cung cấp cơ sở dữ liệu khác nhau.

Một sự phát triển tốt sẽ tạo ra sự cân bằng tốt giữa nhu cầu về tính toàn vẹn và tốc độ của cơ sở dữ liệu bằng cách đưa một số logic vào cơ sở dữ liệu và hầu hết trong số đó vào ứng dụng.

Liệu cùng một truy vấn sẽ được sử dụng nhiều lần trên nhiều ứng dụng, sau đó có thể nó thuộc về một thủ tục được lưu trữ.

Đảm bảo rằng các trường giữ nhà được đặt khi một hàng được chèn và cập nhật là trách nhiệm của DBA. Một kích hoạt sẽ được sử dụng.

Mặt khác, nếu tôi có logic kinh doanh, nó cần phải có trong ứng dụng. Khi có thể thực hiện các cuộc gọi đến các thủ tục được lưu trữ sẽ trả về bộ bản ghi được lọc, mong muốn với số lượng chính xác các trường cần thiết. Không hơn, không ít.

Đó là vấn đề giao tiếp giữa các đội và vấn đề nhận ra ưu và nhược điểm cho từng khả năng.

Ý kiến ​​của tôi là: Đừng làm cho logic ứng dụng quá sâu trong DB.

Một số hệ thống giao dịch cung cấp một cách để mở rộng chức năng hiện có với các tập lệnh, về cơ bản được đưa vào cơ sở dữ liệu. Trải nghiệm của tôi với điều này khá tiêu cực, ít nhất là trong cài đặt nhiều người dùng.

Bạn sẽ đặt logic vào cơ sở dữ liệu, vì bạn muốn có thể sửa đổi logic đó một cách dễ dàng.

• Làm thế nào bạn sẽ kiểm soát phiên bản?
  • Lịch sử mã là gì? Những thay đổi là gì? Bởi ai?
  • Làm thế nào bạn xử lý các thay đổi trên cùng một đoạn mã?
• Làm thế nào bạn sẽ xác định và đảm bảo một trạng thái mã nhất quán?

Bạn có thể theo dõi điều này trong một VCS dựa trên tệp bổ sung, nhưng lợi ích của cơ sở dữ liệu là gì?

Hầu hết các ứng dụng cần phải có một số cách để cung cấp tích hợp. Lý tưởng nhất là bạn sẽ có API đầy đủ, dịch vụ web hoặc ít nhất là cung cấp một số đối tượng cơ sở dữ liệu có chứa logic nghiệp vụ. Mọi người không ở vị trí thời gian / tài nguyên để xây dựng API, vì vậy bạn phải thỏa hiệp.