2010-05-04 55 views
6

Tôi đã đọc nhiều quan điểm mạnh mẽ (cả cho và chống lại) SP hoặc DS.sql động vs thủ tục được lưu trữ - ưu và nhược điểm?

Tôi đang viết một công cụ truy vấn trong C++ (chương trình phụ trợ mySQL cho bây giờ, mặc dù tôi có thể quyết định đi với C++ ORM). Tôi không thể quyết định có viết SP hay tự động tạo SQL và gửi truy vấn đến công cụ db hay không. #

Mọi mẹo về cách quyết định?

Trả lời

1

Bạn có nhiều quyền kiểm soát hơn đối với các cơ chế bên ngoài cơ sở dữ liệu. Các chiến thắng lớn nhất cho việc chăm sóc này bên ngoài cơ sở dữ liệu chỉ đơn giản là bảo trì (trong tâm trí của tôi). Sẽ hơi khó để kiểm soát phiên bản SP so với mã bạn tạo bên ngoài cơ sở dữ liệu. Một điều nữa để theo dõi.

Trong khi chúng tôi đang ở trên chủ đề, nó tương tự như xử lý di chuyển dữ liệu/lược đồ. Thật phiền phức khi phiên bản/xử lý di chuyển giản đồ, nếu bạn chưa có cơ chế cho việc này, bạn sẽ có một thứ khác mà bạn cần quản lý. Nó đi xuống chỉ đơn giản là dễ dàng hơn để quản lý/phiên bản những thứ này bên ngoài cơ sở dữ liệu.

Hãy xem xét trường hợp bạn gặp lỗi trong SP của mình. Bây giờ nó cần phải được thay đổi, nhưng sau đó bạn nhảy qua cơ sở dữ liệu/sandbox của nhà phát triển khác. Phiên bản nào là sandbox và SP? Bây giờ bạn phải theo dõi nhiều phiên bản.

+0

Đây là BS. Không khó để kiểm soát phiên bản mã SQL so với mã C++. Theo nhiều cách, việc sửa đổi mọi thứ trong DB trở nên dễ dàng hơn nhiều; thay đổi một thủ tục lưu sẵn, và bạn đã hoàn thành, so với biên dịch lại và triển khai lại các thư viện và các tệp thực thi. – Joe

1

Một trong những điểm khác biệt chính là liệu bạn có đang viết "một giao diện người dùng thực sự" hay cơ sở dữ liệu là phần trung tâm của đơn đăng ký của bạn.

Nếu bạn sắp có nhiều thủ tục lưu trữ, bạn sẽ cảm thấy rất có ý nghĩa bởi vì bạn giảm chi phí bảo trì. Nếu bạn đang viết chỉ một giao diện, thủ tục lưu trữ là một nỗi đau, bởi vì bạn mất nhiều sự linh hoạt trong việc thay đổi tập dữ liệu khi giao diện người dùng của bạn cần thay đổi, cộng với bây giờ bạn phải thực hiện bảo trì mã, kiểm soát phiên bản, v.v. . Cơ sở dữ liệu là một nỗi đau thực sự để giữ đồng bộ với kho mã.

Cuối cùng, nếu bạn đang mã hóa cho nhiều cơ sở dữ liệu (ví dụ như mã tương thích với Oracle và SQL), tôi sẽ tránh hoàn toàn các thủ tục được lưu trữ.

Bạn có thể trong một số trường hợp hiếm hoi, sau khi lược tả, xác định rằng một số quy trình được lưu trữ giới hạn có ích cho bạn. Tình trạng này đi lên con đường ít hơn những người nghĩ rằng nó.

1

Các kịch bản chính khi bạn PHẢI có sự SP là:

1) Khi bạn đã thiết lập rất phức tạp của các truy vấn với chi phí biên dịch nặng và dữ liệu trôi đủ thấp biên dịch lại rằng là không cần thiết một cách thường xuyên.

2) Khi logic "Chỉ đúng" để truy cập tập dữ liệu cụ thể rất phức tạp, cần được truy cập từ nhiều mã khác nhau trên các nền tảng khác nhau (vì vậy viết nhiều API trong mã là đắt hơn nhiều).

Bất kỳ trường hợp nào khác, gây tranh cãi và có thể được quyết định theo cách này hay cách khác.

Tôi cũng phải nói rằng các đối số của các áp phích khác về việc phiên bản không thực sự lớn trong kinh nghiệm của tôi - có SP của bạn trong điều khiển phiên bản dễ dàng như việc tạo cấu trúc thư mục "sql/db_name" tập lệnh "phát hành cơ sở dữ liệu" phát hành mã SP từ vị trí kiểm soát phiên bản tới cơ sở dữ liệu. Mỗi công ty tôi làm việc cho một số loại thiết lập như thế này, một trong những trung tâm điều hành bởi DBAs hoặc một phòng ban điều hành bởi các nhà phát triển.

1

Điều bạn muốn tránh là phải có logic kinh doanh của bạn trải rộng trên nhiều tầng ứng dụng của bạn. Cơ sở dữ liệu DDL và DML đủ khó để giữ đồng bộ với một cơ sở mã ứng dụng.

Đề xuất của tôi là tạo một giản đồ quan hệ tốt, nhưng tất cả các ràng buộc và trình kích hoạt của bạn để dữ liệu duy trì tính toàn vẹn ngay cả khi ai đó vào cơ sở dữ liệu và cố gắng làm điều gì đó thông qua một số dòng lệnh SQL.

Đặt tất cả logic nghiệp vụ của bạn trong một ứng dụng hoặc dịch vụ gọi SQL (tĩnh/động) rồi kết thúc tốt đẹp chức năng kinh doanh bạn đang cố gắng vạch trần.

Quy trình lưu trữ có hai mục đích mà tôi có thể nghĩ đến.

  1. Trợ giúp để đơn giản hóa việc truy cập dữ liệu. Các Stored Procedure không có bất kỳ logic kinh doanh trong nó, nó chỉ biết về cấu trúc của dữ liệu và cho thấy một giao diện để isolate truy cập vào ba bảng và một cái nhìn chỉ để có được một mảnh duy nhất của thông tin.
  2. Lập bản đồ Mô hình miền với dữ liệu Mô hình, Các thủ tục được lưu trữ có thể hỗ trợ trong việc làm cho Mô hình dữ liệu trông giống như Mô hình miền đã cho.

Sau khi chương trình đã hoàn tất và đã được lược tả, thường có sự cố về hiệu suất với bản phát hành trước 1.0. Các thủ tục được lưu trữ thực hiện việc cung cấp batching của SQL mà không cần lưu lượng truy cập cần phải đi qua lại giữa DBMS và Ứng dụng. Điều đó đang được nói trong trường hợp hiếm hoi và cực đoan do hiệu suất một vài quy tắc kinh doanh có thể cần phải được di chuyển đến bên lưu trữ-thủ tục. Đảm bảo ghi lại bất kỳ ngoại lệ nào cho triết lý kiến ​​trúc ở nhiều vị trí nổi bật.

+1

Thủ tục lưu trữ là những thứ rất mạnh khi được sử dụng đúng cách. Họ có nhiều mục đích hơn những gì bạn đã liệt kê. Họ thường có bối cảnh tốt nhất để đưa ra quyết định kinh doanh và xác nhận. Nó không phải là thực tế và trong nhiều trường hợp lập trình xấu hoàn toàn để mang lại các tập dữ liệu lớn bởi vì bạn không muốn thực hiện logic ở đúng vị trí. – Joe

+1

@Joe - Địa điểm chính xác không phải là cơ sở dữ liệu cho logic. –

2

Đây là câu trả lời đơn giản:

Nếu lập trình viên của bạn làm cả cơ sở dữ liệu và mã hóa, hãy giữ SQL bằng ứng dụng. Nó dễ dàng hơn để duy trì theo cách đó. Nếu không, hãy để các nhân viên DB xử lý nó trong SP.

+0

+1 Lean và nhanh chóng, giống như chúng tôi thích những câu trả lời đó. ;) –

+2

Tôi không đồng ý. SQL trong ứng dụng có nghĩa là bạn bị CÙNG để xây dựng lại ứng dụng khi bạn tìm thấy một truy vấn kém bằng văn bản (hiệu năng kém, dữ liệu xấu, vv) Trong cơ sở dữ liệu, bạn sửa đổi proc và bạn đã hoàn tất. – Joe

+2

Tất nhiên, sự không đồng ý của bạn phụ thuộc vào nhiều yếu tố. Bạn đang giả định một ứng dụng nguyên khối được phân phối. Trong trường hợp đó, có, bạn có lẽ đúng. Nhưng một ứng dụng được xây dựng tốt không phải là một exe lớn mà cần phải được biên dịch lại trên mọi thay đổi. Cũng giống như bạn sẽ không sử dụng một bảng để lưu trữ tất cả dữ liệu của bạn cho một ứng dụng. – Sophtware

0

DS linh hoạt hơn. Cách tiếp cận SP giúp hệ thống của bạn dễ quản lý hơn.

1

Stored Procedure là lý tưởng cho:

  • Tạo trừu tượng tái sử dụng trên các truy vấn phức tạp;
  • Gây các loại chèn/cập nhật cụ thể cho các bảng (nếu bạn cũng từ chối các quyền đối với bảng);
  • Thực hiện các hoạt động đặc quyền mà người dùng đã đăng nhập thường không được phép thực hiện;
  • Đảm bảo kế hoạch thực hiện nhất quán;
  • Mở rộng khả năng của ORM (cập nhật hàng loạt, truy vấn phân cấp, v.v.)

động SQL là lý tưởng cho:

  • đối số tìm kiếm Variable hoặc cột đầu ra:
    • điều kiện tìm kiếm Tùy chọn
    • bảng Pivot
    • IN khoản với giá trị người dùng chỉ định
  • Triển khai ORM (hầu hết có thể sử dụng SP, nhưng không thể được xây dựng hoàn toàn trên chúng);
  • DDL và tập lệnh quản trị.

Họ giải quyết các vấn đề khác nhau, thực sự. Sử dụng cái nào phù hợp hơn với nhiệm vụ trong tay, và không hạn chế bản thân chỉ với cái này hay cái kia. Sau khi bạn làm việc trên mã cơ sở dữ liệu trong một thời gian, bạn sẽ bắt đầu có được một cảm giác trực quan hơn cho những điều này; bạn sẽ tìm thấy chính mình đập vào nhau một số tổ chuột của chuỗi cho một truy vấn và suy nghĩ, "điều này thực sự nên đi trong một thủ tục được lưu trữ."

Lưu ý cuối cùng: Vì câu hỏi này ngụ ý một mức độ thiếu kinh nghiệm nhất định với SQL, tôi cảm thấy có nghĩa là, đừng quên rằng bạn vẫn cần phải tham số hóa truy vấn khi viết SQL động. Tham số không chỉ dành cho các thủ tục được lưu trữ.

Các vấn đề liên quan