Tạo chức năng trong cơ sở dữ liệu trung tâm hoặc lặp lại trong mỗi cơ sở dữ liệu?

Một trong những nhà phát triển của tôi đã viết một hàm SQL hoạt động giống như hàm VB.Net (LastIndexOf) và muốn xuất bản nó. Câu hỏi của tôi là lý do gì để đưa điều này vào cơ sở dữ liệu trung tâm so với việc đưa nó vào từng cơ sở dữ liệu người dùng?

Nhà phát triển đã cố gắng đưa nó vào lược đồ sys trên db chính của anh ta để anh ta không phải đủ điều kiện gọi nó từ cơ sở dữ liệu người dùng ... thở dài

Nhưng tôi không chắc cái cớ hợp lệ sẽ là gì để tập trung nó (rõ ràng không phải là cơ sở dữ liệu chủ) so với mỗi cơ sở dữ liệu người dùng?

— David George
nguồn

Tôi nghĩ ý tưởng đằng sau nó có thể là một cái gì đó như 'Bạn sẽ làm gì trong trường hợp có một lỗi giả định? Đi đến mọi cơ sở dữ liệu và sửa từng bản sao riêng biệt? '

— dezso

Chi phí quản trị không liên quan ở đây vì tôi có thể cập nhật tất cả các cơ sở dữ liệu dễ dàng như một cơ sở dữ liệu duy nhất

— David George

Và nhà phát triển của bạn có biết về nó không? :) Và có lẽ anh ấy / cô ấy cảm thấy nó thực hiện một chức năng cơ bản như vậy mà nó phải ở trong chính cốt lõi.

— dezso

Đúng. Đó là câu hỏi của tôi, nên một cái gì đó có thể được coi là cốt lõi là một phần của cơ sở dữ liệu người dùng hoặc được chia sẻ giữa tất cả các cơ sở dữ liệu từ một cơ sở dữ liệu chung?

— David George

Có, tôi đã cố gắng trình bày hai hoặc ít hơn các đối số hợp lệ có lợi cho việc tập trung hóa. Tôi nghĩ nó có thể là một câu hỏi về chính sách hoặc sở thích cá nhân của bạn - rõ ràng từ ngữ mà bạn không thích ý tưởng này.

— dezso

Câu trả lời:

Cách tôi thích làm điều này: đặt hàm vào cơ sở dữ liệu tiện ích và tạo từ đồng nghĩa với nó trong mỗi cơ sở dữ liệu thông thường. Bằng cách này bạn sẽ có được điều tốt nhất của cả hai thế giới:

chỉ có một bản sao của đối tượng để duy trì
nhà phát triển không phải cung cấp tên ba hoặc bốn phần

ví dụ

USE UtilityDB;
GO
CREATE FUNCTION dbo.LastIndexOf(...) ...
GO
USE otherDB;
GO
CREATE SYNONYM dbo.LastIndexOf FOR UtilityDB.dbo.LastIndexOf;
GO

Điều này đặc biệt mạnh mẽ đối với các chức năng CLR, vì có thêm chi phí quản trị để thay đổi / triển khai các chức năng đó.

Và đây là cách tốt hơn để sử dụng chủ (và đánh dấu là một đối tượng hệ thống, không được đảm bảo để có thể chuyển tiếp). Dù vậy, tôi rất muốn biết nhà phát triển của bạn mong muốn tạo chức năng của mình như thế nào trong syslược đồ.

Tôi hiểu rằng việc duy trì nhiều bản sao của một chức năng trong 500 cơ sở dữ liệu thực sự không khó hơn việc duy trì một bản sao duy nhất, nhưng có nhiều bản sao thực sự chỉ là một lợi ích khi bạn có ngoại lệ (ví dụ: khách hàng A muốn chức năng của họ xử lý các NULL khác nhau, hoặc một cái gì đó). Trong trường hợp đó, tôi sẽ để lại từ đồng nghĩa trong tất cả các cơ sở dữ liệu khác và giới thiệu một phiên bản đặc biệt của chức năng chỉ trong cơ sở dữ liệu đó.

(Tất nhiên, điều này giả định rằng hàm không phụ thuộc vào bất kỳ quyền truy cập dữ liệu nào trong cơ sở dữ liệu của khách hàng - điều này chắc chắn có thể làm phức tạp vấn đề.)

— Aaron Bertrand
nguồn

Tôi sẽ không đồng ý với Aaron (và câu trả lời được chấp nhận).

Cách tiếp cận của Aaron là cách tôi muốn đối phó với "công cụ DBA", ví dụ như các kịch bản bảo trì. Tôi sẽ không bao giờ muốn làm điều này với một chức năng thư viện sẽ được gọi bởi cơ sở dữ liệu người dùng.

Tại sao? Bạn sẽ hướng đến cơ sở dữ liệu tương đương với DLL Hell .

Phiên bản không tương thích

... Trước Windows 2000, Windows dễ bị tổn thương vì bảng lớp COM được chia sẻ trên tất cả người dùng và quy trình. Chỉ có một đối tượng COM, trong một DLL / EXE có thể được khai báo là có ID lớp COM toàn cầu cụ thể trên một hệ thống. Nếu bất kỳ chương trình nào cần thiết để tạo một thể hiện của lớp đó, thì nó có bất cứ thứ gì là triển khai được đăng ký tập trung hiện tại. Do đó, việc cài đặt chương trình cài đặt phiên bản mới của một đối tượng chung có thể vô tình phá vỡ các chương trình khác đã được cài đặt trước đó.

Cài đặt .net 4.5 trên máy chủ chạy ứng dụng .net 2.0 và điều gì xảy ra? Không có gì, ứng dụng của bạn tiếp tục sử dụng khung 2.0. Cập nhật chức năng LastIndexOf của bạn trên máy chủ lưu trữ 3 cơ sở dữ liệu ứng dụng (là một phần của bản nâng cấp lên một trong số chúng) và điều gì xảy ra? Cả ba hiện đang sử dụng phiên bản mới nhất.

Thay thế là cách tiếp cận được áp dụng bởi SQL # . Điều này được cài đặt vào một lược đồ trong mỗi cơ sở dữ liệu người dùng, vì vậy bạn có thể nâng cấp cơ sở dữ liệu cho Application-X một cách an toàn mà không gặp rủi ro về tính ổn định của Application-Y.

Nếu bạn đang làm việc trong môi trường quản lý thay đổi được kiểm soát chặt chẽ, bạn sẽ không có lựa chọn nào khác, bạn không thể nâng cấp một thành phần dùng chung mà không kiểm tra tất cả người tiêu dùng của thành phần đó. Nếu bạn đang làm việc ở đâu đó "nhanh và lỏng" hơn một chút, bạn có thể tự do nắm bắt cơ hội của mình bằng cách phá vỡ thứ gì đó vô tình bằng một bản vá / nâng cấp.

— Mark Storey-Smith
nguồn

Hãy để tôi cung cấp phản bác, vì bạn dường như muốn một và bây giờ tôi có một vài khoảnh khắc rảnh rỗi mà tôi không có trước đó. :-) (1) Tôi giả định rằng bộ cơ sở dữ liệu được đề cập đều có liên quan và không phải là một phần của các ứng dụng hoàn toàn khác nhau. (2) Trong trường hợp này, tôi không nghi ngờ có nhiều nguy hiểm đối với một chức năng được gọi là LastIndexOfthay đổi, ít hơn theo cách chỉ phá vỡ một số ứng dụng / cơ sở dữ liệu. Tôi muốn nói rằng đó là một vấn đề lớn hơn đối với CLR hoặc các chức năng thực sự trung tâm / phức tạp phục vụ nhiều ứng dụng. (3) Sở thích thực tế của tôi là không sử dụng chức năng nào cho các tác vụ đơn giản.

— Aaron Bertrand

Luôn luôn chào đón những suy nghĩ của bạn tất nhiên :)

— Mark Storey-Smith

Này đó. Là người tạo ra SQL #, tôi đánh giá cao đề cập tích cực :-). Tuy nhiên, tôi nên làm rõ rằng điểm quyết định chính cho việc sử dụng Lược đồ riêng cho tất cả các đối tượng SQL # là tạo không gian tên để không xảy ra xung đột đặt tên cho dù SQL # được cài đặt ở đâu. Tuy nhiên, bạn vẫn đưa ra một điểm cần được xem xét về phiên bản, tùy thuộc vào cách ứng dụng được cấu trúc. Cá nhân, tôi thích có một UtilityDB cho các công cụ thư viện thường được gọi, nhưng nó làm tăng rủi ro một chút và yêu cầu kiểm tra kỹ lưỡng.

— Solomon Rutzky

Câu trả lời cho câu hỏi này phụ thuộc vào việc chúng ta đang nói về các đối tượng T-SQL hay các đối tượng SQLCLR. Có nhiều yếu tố khác nhau (và hơn thế nữa) để xem xét khi xử lý các đối tượng SQLCLR.

Về các đối tượng T-SQL, cả hai câu trả lời ở đây đều đưa ra các điểm hợp lệ. Như được mô tả trong câu trả lời của @ Aaron , DB trung tâm có thể khá tiện dụng và Từ đồng nghĩa có thể được sử dụng để giúp dễ dàng có một số DB trỏ đến tài nguyên được chia sẻ và một số sử dụng tài nguyên cục bộ. Nhưng quan điểm đưa ra trong câu trả lời của Mark liên quan đến rủi ro gia tăng do sự phụ thuộc mạnh mẽ hơn không thể bị bỏ qua.

Tuy nhiên, nếu bạn đang xử lý các đối tượng SQLCLR, thì trước tiên bạn cần xem xét tất cả các điểm tôi đã đưa ra trong câu trả lời sau:

Làm cách nào để sử dụng tốt hơn Chức năng CLR từ quan điểm hiệu suất (lặp lại bên trong mỗi DB hoặc có chức năng chung)?

— Solomon Rutzky
nguồn