Wiederverwendung von SQL gespeicherten Prozeduren in verschiedenen Anwendungen

Question

Ich bin neugierig, wie die Leute mit gespeicherten Prozeduren in einer Datenbank umgehen, auf die viele Anwendungen zugreifen. Neigen Sie dazu, für jede Anwendung einen anderen Satz gespeicherter Prozeduren vorzuhalten, versuchen Sie, einen gemeinsamen Satz zu verwenden, oder verwenden Sie eine Mischung?

Einerseits ermöglicht die Wiederverwendung von SPs weniger Änderungen bei einer Modelländerung oder Ähnlichem und im Idealfall weniger Wartungsaufwand. Andererseits können Änderungen an einer gespeicherten Prozedur für eine Anwendung andere Anwendungen beeinträchtigen, wenn die Anforderungen der Anwendungen voneinander abweichen. Ich sollte anmerken, dass in unserer Umgebung jede Anwendung ihr eigenes Entwicklungsteam hat, mit schlechter Kommunikation zwischen ihnen. Das Datenteam hat jedoch eine bessere Kommunikation und ist hauptsächlich mit dem Schreiben von gespeicherten Prozeduren betraut.

Danke!

Answer 1

Gespeicherte Prozeduren sollten auf der Grundlage der Daten erstellt werden, die Sie zurückgeben wollen, nicht auf der Grundlage der Anwendung, die die Anfrage stellt. Wenn Sie eine gespeicherte Prozedur haben, die GetAllItems heißt, sollte sie alle Elemente in der Datenbank zurückgeben. Wenn eine der Anwendungen alle Artikel nach Kategorie abrufen möchte, erstellen Sie GetAllItemsByCategory. Es gibt keinen Grund dafür, dass sich die Geschäftsregeln einer gespeicherten Prozedur je nach der Anwendung, die die Daten anfordert, ändern müssen.

Answer 2

Ich habe die Erfahrung gemacht, dass SPs, die von mehreren Anwendungen gemeinsam genutzt werden, eine Ursache für Schmerzen sind. Ich würde sogar behaupten, dass eine Datenbank, auf die mehr als eine Anwendung direkt zugreift, langfristig nicht die beste Architektur ist.

Das Muster, das ich empfehle und implementiert habe, besteht darin, dass nur eine Anwendung jede Datenbank "besitzen" und APIs (Dienste usw.) für andere Anwendungen bereitstellen sollte, damit diese auf die Daten zugreifen und sie ändern können.

Dies hat mehrere Vorteile:

1. Die besitzende Anwendung kann jede beliebige Geschäftslogik, Protokollierung usw. anwenden, um sicherzustellen, dass sie stabil bleibt.
2. Wenn das Schema geändert wird, sind alle Schnittstellen bekannt und können getestet werden, um sicherzustellen, dass externe Anwendungen weiterhin funktionieren.

Answer 3

Gespeicherte Prozeduren sollten Geschäftsregeln offenlegen, die sich je nach Anwendung, die sie verwendet, nicht ändern. Auf diese Weise können die Regeln nur einmal gespeichert und aktualisiert werden, anstatt an jedem Ort, an dem sie verwendet werden, was ein Alptraum ist.

Answer 4

Stellen Sie sich das so vor: Ihre gespeicherten Prozeduren beziehen sich auf die Daten, die sich unter ihnen befinden, und sollten eigentlich nichts über die Anwendungen wissen, die sich über ihnen befinden. Es ist möglich, dass eine Anwendung Daten auf eine Art und Weise lesen oder aktualisieren muss, die eine andere nicht braucht, und daher würde die eine SPs verwenden, die die andere nicht braucht.

Wenn es sich um meine Anwendung/Datenbank/etc. handeln würde und Änderungen an einem SP zur Verbesserung einer Anwendung eine andere kaputt machen würden, würde ich das als Beweis für ein tieferes Designproblem ansehen.

Answer 5

Wir versuchen, wo immer möglich, eine einzige, gemeinsam genutzte gespeicherte Prozedur zu verwenden, aber wir sind auch schon in die von Ihnen beschriebene Situation geraten. Wir haben es durch Hinzufügen eines Anwendungspräfixes zu den gespeicherten Procs (ApplicationName_StoredProcName) gelöst.

Oft rufen diese gespeicherten Procs den zentralisierten oder "Master"-Proc auf, aber diese Methode lässt Raum für anwendungsspezifische Änderungen in der Zukunft.