RECAP TRÊN TRẢ LỜI KHÁC
Dưới đây là một bản tóm tắt nhanh chóng về những gì người khác đã nói ở đây trước đây.
Chính sách công ty chuyên nghiệp:
- Cho phép theo dõi các phụ thuộc giữa các đối tượng cơ sở dữ liệu và tổng quan về các thay đổi được lên kế hoạch ảnh hưởng đến lược đồ;
- Nhóm DBA có thể xem xét và kiểm soát quyền truy cập ứng dụng;
- Nhóm DBA có thể dự đoán tác động hiệu suất của các thay đổi;
- Decouples cơ sở dữ liệu từ mã ứng dụng;
- Lý thuyết cửa sổ bị hỏng ... có nghĩa là cách họ tổ chức mã của họ và phá vỡ tính nhất quán sẽ khiến cơ sở hạ tầng khó nắm bắt hơn đối với người mới, điều này sẽ khiến họ tôn trọng và cố gắng giảm chất lượng;
- Bạn nhận được tiền lương của bạn để làm những gì bạn được yêu cầu làm. Đây là một chính sách của công ty và ngay bây giờ bạn không có quyền thay đổi nó, vì vậy tốt hơn là sống với nó.
Chính sách của công ty Contra:
- Tư duy của công ty này rất cứng nhắc và giáo điều, và chính sách này khiến công việc của nhà phát triển trở nên cồng kềnh không cần thiết. Thật không may, xem điểm cuối cùng trong phần Ưu điểm;
- Vì back2dos đề cập đến nó bằng cách nói "Đối với mọi truy vấn được thực hiện cho cơ sở dữ liệu, bạn phải tra cứu thủ tục được lưu trữ" , chính sách chỉ dành cho sprocs thường dẫn đến sao chép mã, bởi vì các nhà phát triển khác nhau không biết sprocs nào có thể được sử dụng lại cho vấn đề trong tầm tay;
- Ngoài ra, trớ trêu thay, ngược lại với trường hợp trước cũng tạo ra vấn đề, khi một ứng dụng nào đó sở hữu một sproc, sau đó một ứng dụng khác lại cập nhật nó mà không biết ai khác bắt đầu dựa vào nó. Các DBA theo dõi các phụ thuộc không xa hơn các bức tường của phòng máy chủ DB, vì vậy đừng hy vọng họ sẽ đưa ra một ứng dụng chết tiệt nào dựa trên những gì bên ngoài đó. Nếu các nhóm ứng dụng không theo dõi vấn đề giữa họ thì đó là vấn đề của họ, các DBA sẽ được bảo vệ.
THỨ 2 TRUNG TÂM
Thứ nhất, nhiều câu trả lời ở đây sử dụng từ chuẩn . Việc thực hành cấm truy vấn trực tiếp và chỉ cho phép sprocs không được gọi là tiêu chuẩn. Đó là một chính sách (xem câu trả lời của jzd ).
Thứ hai, cụ thể cho vấn đề của bạn: đối số chính của tôi chống lại chính sách hạn chế sử dụng các thủ tục được lưu trữ này sẽ chỉ là ngôn ngữ SQL và không nhất thiết phải là cơ sở hạ tầng kho lưu trữ logic nghiệp vụ tập trung mà nó thúc đẩy (mặc dù cũng có đối số đối lập) .
SQL là một ngôn ngữ khá cứng nhắc và không thể kết hợp, với sức mạnh biểu cảm khá hạn chế . Điều này có nghĩa là bạn sẽ đi vào ngõ cụt rất sớm liên quan đến khả năng sử dụng lại mã . Một trong những lý do của sự cứng nhắc này là không có cách nào để vượt qua các chức năng hạng nhất theo bất kỳ cách nào (như với các ngôn ngữ OOP sử dụng đa hình), điều này hạn chế đáng kể khả năng kết hợp . Cách gần nhất mà bạn có thể có được đó là sức mạnh biểu cảm là bằng cách viết các truy vấn SQL động được xây dựng bằng cách sử dụng nối chuỗi. Không phải là một điều gọn gàng. Các truy vấn động đánh bại một số điểm trong phần "ưu", như phụ thuộc theo dõi giữa các đối tượng DB và thường có hiệu suất kém hơn, dễ bị lỗi, khó gỡ lỗi và tăngnguy cơ tấn công SQL SQL . Thật không may, với SQL, bạn sẽ thấy rằng bạn không thể tiến xa được với việc trích xuất logic có thể tái sử dụng phổ biến giữa các spro mà không va vào tường và bị buộc phải dùng đến các truy vấn được thực hiện linh hoạt.
CẬP NHẬT: Một hạn chế lớn khác của các thủ tục được lưu trữ, bên cạnh chức năng của lớp thứ nhất, là việc truyền và trả về các kiểu dữ liệu tổng hợp dưới dạng đối số, cho dù đó là danh sách, bộ, bản ghi hoặc cặp giá trị khóa. Điều này làm tổn thương khả năng tổng hợp quá tệ.
Cuối cùng, tôi không nhất thiết phải đồng ý với một trong những điểm chuyên nghiệp ở trên, "tách DB khỏi ứng dụng" của Jorge : Nguyên tắc chính mà tôi cảm thấy áp dụng ở đây là thích cấu trúc dữ liệu nguyên thủy với tập hợp lớn các hoạt động có thể tái sử dụng và có thể kết hợp chung, thay vì làm việc với các API tùy chỉnh . Sprocs là các API tùy chỉnh như vậy ở đây, nằm giữa người dùng và dữ liệu quan hệ nguyên thủy để truy vấn nó bằng cách sử dụng các nguyên hàm thao tác dữ liệu có thể kết hợp phổ biến ( chọn, tham gia, ở đâu, nhóm theo, Vân vân). Bây giờ, bản thân SQL không phải là lựa chọn lý tưởng để trở thành DSL cho các nguyên hàm thao tác dữ liệu có thể tổng hợp, do độ cứng được đề cập ở trên, nhưng với lựa chọn ngôn ngữ hợp lý hơn (như .NET Linq ... hoặc Lisp / Clojure!) Bạn có thể chạy logic đối với một Danh sách đơn giản giống như đối với Kết quả DB. Rõ ràng, điều đó làm cho nó dễ dàng kiểm tra, đó là một điều tốt. Tôi nói thích lưu trữ dữ liệu của bạn là đơn giản và nguyên thủy, sao cho nó có thể được sử dụng với các CSV đơn giản. Như bạn thấy, mô hình này cũng tách DB khỏi ứng dụng, chỉ có điều nó vẽ đường ở mức độ trừu tượng thấp hơn.
PHẢI LÀM GÌ TIẾP THEO?
Có một chút không liên quan đến câu hỏi, nhưng tôi khuyến khích bạn hãy xem Datomic , có một cách tiếp cận mới lạ thú vị để lưu trữ và truy vấn dữ liệu, phù hợp với một số quan sát trên. (Rõ ràng, ý tôi là trước tiên hãy nhìn vào nó bên ngoài môi trường làm việc ... chắc chắn KHÔNG đến văn phòng của CTO vào ngày hôm sau và nói "Này các bạn, tôi đã viết lại một số sprocs của bạn trong Datomic và triển khai nó trên máy chủ prod sáng bóng này ở đó, nó thực sự tuyệt vời hãy xem! " Họ có thể không đánh giá cao sự phấn khích hoàn toàn dễ hiểu khác;)