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

Wenn Sie die Möglichkeit suchen, den SQL-Code gemeinsam zu nutzen, versuchen Sie, eine Bibliothek mit abstrakten Funktionen zu erstellen. Auf diese Weise können Sie einen Teil des Codes wiederverwenden, der generische Aufgaben erfüllt, und die Geschäftslogik für jede Anwendung getrennt halten. Das Gleiche könnte man mit den Ansichten machen - sie könnten recht generisch gehalten werden und für viele Anwendungen nützlich sein.

Sie werden wahrscheinlich feststellen, dass es nicht so viele Verwendungsmöglichkeiten für gängige gespeicherte Prozeduren gibt, wenn Sie weitergehen.

Allerdings haben wir einmal ein Projekt durchgeführt, das mit einer sehr schlecht konzipierten Legacy-Datenbank arbeitete. Wir haben eine Reihe von gespeicherten Prozeduren implementiert, die das Abrufen von Informationen erleichterten. Als andere Mitarbeiter aus anderen Teams dieselben Informationen nutzen wollten, haben wir unsere gespeicherten Prozeduren umstrukturiert, um sie allgemeiner zu machen, eine zusätzliche Ebene von Kommentaren und Dokumentation hinzugefügt und anderen Mitarbeitern die Nutzung unserer Prozeduren ermöglicht. Diese Lösung hat ziemlich gut funktioniert.

Answer 2

Viele gespeicherte Prozeduren sind anwendungsunabhängig, aber es kann auch einige geben, die anwendungsabhängig sind. Zum Beispiel können die CRUD (Create, Select, Update, Delete) Stored Procedures anwendungsübergreifend sein. Insbesondere können Sie eine Prüflogik einbauen (manchmal in Triggern, aber es gibt eine Grenze, wie kompliziert man in Triggern werden kann). Wenn Sie eine Art Standardarchitektur in Ihrem Softwarehaus haben, kann die mittlere Ebene eine gespeicherte Prozedur zum Erstellen/Auswählen/Aktualisieren/Löschen aus der Datenbank benötigen, unabhängig von der Anwendung, in der die Prozedur gemeinsam genutzt wird.

Gleichzeitig kann es einige nützliche Möglichkeiten geben, die Daten einzusehen, z. B. GetProductsSoldBySalesPerson usw., die ebenfalls anwendungsunabhängig sein werden. Möglicherweise haben Sie eine Reihe von Nachschlagetabellen für einige Felder wie Abteilung, Adresse usw., so dass es eine Prozedur geben kann, die eine Ansicht der Tabelle mit allen Textfeldern zurückgibt. D.h. anstelle von SalesPersonID, SaleDate, CustomerID, DepartmentID, CustomerAddressID gibt die Prozedur eine Ansicht SalesPersonName, SaleDate, CustomerName, DepartmentName, CustomerAddress zurück. Dies könnte auch anwendungsübergreifend verwendet werden. Ein Kundenbeziehungssystem würde Kundenname/Adresse/Sonstige Attribute ebenso benötigen wie ein Fakturierungssystem. Etwas, das alle Verknüpfungen durchführt und alle Kundeninformationen in einer Abfrage abruft, würde also wahrscheinlich anwendungsübergreifend verwendet werden. Zugegebenermaßen ist das Erstellen von Möglichkeiten zum Anzeigen der Daten die Domäne eines Views, aber oft wurden dafür gespeicherte Prozeduren verwendet.

Also im Grunde, beim Löschen aus Ihrer Tabelle müssen Sie aus 3 oder 4 anderen Tabellen löschen, um die Datenintegrität zu gewährleisten. ist die Logik zu kompliziert für einen Trigger? Dann könnte eine gespeicherte Prozedur wichtig sein, die von allen Anwendungen für Löschungen verwendet wird. Das Gleiche gilt für Dinge, die bei der Erstellung durchgeführt werden müssen. Wenn es gemeinsame Joins gibt, die immer durchgeführt werden, kann es sinnvoll sein, eine Stored Procedure zu haben, die alle Joins durchführt. Wenn Sie dann später die Tabellen ändern, können Sie die Prozedur beibehalten und nur die Logik dort ändern.

Answer 3

Das Konzept der gemeinsamen Nutzung eines Datenschemas durch mehrere Anwendungen ist schwierig. Ihr Schema wird aus Leistungsgründen immer beeinträchtigt: Denormalisierung, zu erstellende Indizes. Wenn Sie die Größe einer Zeile halbieren können, können Sie die Anzahl der Zeilen pro Seite verdoppeln und wahrscheinlich auch die Zeit halbieren, die zum Scannen der Tabelle benötigt wird. Wenn Sie jedoch nur "allgemeine" Merkmale in die Haupttabelle aufnehmen und Daten, die nur für bestimmte Anwendungen von Interesse sind, in anderen (aber verwandten) Tabellen aufbewahren, müssen Sie alle Daten zusammenführen, um zur Idee der "einzigen Tabelle" zurückzukehren.

Mehr Indizes zur Unterstützung verschiedener Anwendungen führen zu immer längeren Zeiten für das Einfügen, Aktualisieren und Löschen von Daten aus jeder Tabelle.

Auch der Datenbankserver wird oft zu einem Engpass, da Datenbanken nicht lastverteilt werden können. Sie können Ihre Daten auf mehrere Server verteilen, aber auch das wird sehr kompliziert.

Schließlich ist der Koordinierungsaufwand in der Regel enorm, und es kommt zweifellos zu Streitigkeiten zwischen verschiedenen Abteilungen darüber, wessen Anforderungen Vorrang haben, so dass neue Entwicklungen ins Stocken geraten.

Im Allgemeinen funktioniert das Modell des "isolierten Datensilos pro Anwendung" besser. Fast alles, was wir tun - ich arbeite für ein Softwarehaus - basiert auf dem Import von Daten aus anderen Systemen und dem Export von Daten in andere Systeme, und zwar mit den eigenen Datenbanken unserer Anwendungen.

In Data-Warehouse-/Entscheidungsunterstützungssystemen mag das einfacher sein; ich arbeite im Allgemeinen an OLTP-Systemen, bei denen die Transaktionsleistung im Vordergrund steht.