Wiederverwendung gespeicherter SQL-Prozeduren in verschiedenen Anwendungen

Question

Ich bin neugierig auf die Ansätze der Leute, gespeicherte Prozeduren in einer Datenbank zu verwenden, auf die viele Anwendungen zugreifen.Konkret: Behalten Sie in der Regel unterschiedliche Sätze gespeicherter Prozeduren für jede Anwendung bei, versuchen Sie, einen gemeinsam genutzten Satz zu verwenden, oder verwenden Sie eine Mischung?

Einerseits ermöglicht die Wiederverwendung von SPs weniger Änderungen bei einem Modellwechsel oder Ähnlichem und im Idealfall weniger Wartung.Wenn andererseits die Anforderungen der Anwendungen unterschiedlich sind, können Änderungen an einer gespeicherten Prozedur für eine Anwendung andere Anwendungen beschädigen.Ich sollte beachten, dass in unserer Umgebung jede Anwendung ihr eigenes Entwicklungsteam hat und die Kommunikation zwischen ihnen schlecht ist.Das Datenteam verfügt jedoch über eine bessere Kommunikation und ist hauptsächlich mit dem Schreiben gespeicherter Prozeduren betraut.

Danke!

Answer 1

Es hängt alles von Ihrer Abstraktion Strategie. Sind die gespeicherten Prozeduren als diskreter Punkt der Abstraktion behandelt, oder sind sie nur als ein anderer Teil der Anwendung behandelt, die sie nennt.

Die Antwort auf diese Frage wird Ihnen sagen, wie sie verwalten. Wenn sie eine diskrete Abstraktion sind, können sie gemeinsam genutzt werden, als ob Sie neue Funktionen benötigen, werden Sie neue Verfahren hinzufügen. Wenn sie einen Teil der App, die sie nennt, sollten sie nicht mit anderen geteilt werden.

Answer 2

Stored Procedures sollten auf der Grundlage der Daten erstellt werden, die Sie zurückgeben möchten, nicht die Anwendung, der die Anfrage. Wenn Sie eine gespeicherte Prozedur, die getAllItems ist, sollte es alle Elemente in der Datenbank zurück. Wenn eine der Anwendungen möchte alle Elemente nach Kategorie erhalten, erstellen GetAllItemsByCategory. Es gibt keinen Grund für die Geschäftsregeln einer gespeicherten Prozedur ändern basierend auf der Anwendung die Daten anfordert.

Answer 3

Meine Erfahrung ist, dass von mehreren Anwendungen gemeinsam genutzt SPs mit einer Ursache der Schmerzen ist. In der Tat würde ich argumentieren, dass eine Datenbank mit, die direkt von mehr als eine Anwendung zugegriffen wird, ist nicht die beste langfristige Architektur.

Das Muster, das ich empfehlen und umgesetzt habe, ist, dass nur eine Anwendung sollte „eigene“ jede Datenbank und bietet APIs (Dienstleistungen, etc.) für andere Anwendungen zugreifen und Daten zu ändern.

Dies hat mehrere Vorteile:

1. Die besitzende Anwendung kann jede Geschäftslogik anwenden, Protokollierung, usw., um sicherzustellen, es bleibt stabil
2. Wenn das Schema geändert wird, werden alle Schnittstellen bekannt und getestet werden kann, dass externe Anwendungen werden immer noch arbeiten lassen

Answer 4

Stored Procedures sollten Geschäftsregeln aussetzen, die mit ihnen abhängig von der Anwendung nicht ändern. Auf diese Weise können die Regeln einmal gespeichert und aktualisiert werden, anstatt jeden Ort, den sie verwendet werden, die ein Alptraum ist.

Answer 5

Denken auf diese Weise davon: Ihre gespeicherten Prozeduren über die Daten sind, die unter ihnen ist, und soll über die Anwendungen über sie nicht wirklich wissen. Es ist möglich, dass eine Anwendung benötigt, um Daten zu lesen oder zu aktualisieren in eine Weise, dass der andere nicht, und so würde man SPs verwenden, dass der andere würde nicht.

Wenn es meine Anwendung / Datenbank / etc, und Änderungen an einem SP eine Anwendung brach eine andere zu verbessern, würde ich diese Beweise einer tieferen Designproblem betrachten.

Answer 6

Der letzte Teil Ihrer Frage, die ich selbst glauben beantwortet.

Mit bereits schlechter Kommunikation, den Austausch Verfahren zwischen den Entwicklungsteams würde nur auf die möglichen Fehlerpunkte hinzufügen und könnte so oder Team Härte führen.

Wenn ich auf dem gleichen Team bin an mehreren Projekten arbeiten, werden wir einige Zeit und Aktien Verfahren sparen, aber in der Regel habe ich festgestellt, dass ein wenig Überschneidungen (Einige Verfahren hier und da) hilft, die katastrophale Änderungen / Duplizierung später benötigt vermeiden wenn die Anwendungen starten zu divergieren.

LordScarlet weist auch auch ein Schlüsselelement aus, wenn es mit keiner Business-Logik teilt generic ist es sollte kein Problem sein.

Answer 7

Jedes Mal, wenn wir Verfahren hatte gespeichert, die mehrere Anwendungen üblich waren, würden wir eine Datenbank nur für diese Verfahren erstellen (und Ansichten und Tabellen usw.). Diese Datenbank (wir dem Namen „Basis“) hätte dann einen Entwickler (oder Team) verantwortlich dafür (Wartung und Prüfung).

Wenn ein anderes Team neue Funktionen benötigt wird, könnten sie schreiben es und die Basis Entwickler entweder in der Basis DB implementieren würden oder eine einfachere Art und Weise vor.

Answer 8

Wir versuchen, wo immer möglich, einen einzigen, gemeinsam genutzten gespeicherten Prozess zu verwenden, sind aber auch auf die von Ihnen beschriebene Situation gestoßen.Wir haben das Problem gelöst, indem wir den gespeicherten Prozessen ein Anwendungspräfix hinzugefügt haben (ApplicationName_StoredProcName).

Oftmals rufen diese gespeicherten Prozesse den zentralisierten oder „Master“-gespeicherten Prozess auf, aber diese Methode lässt später Raum für anwendungsspezifische Änderungen.

Answer 9

Ich glaube nicht Sprocs unter mehreren Anwendungen sinnvoll zu teilen.

kann ich den Fall sehe eine Datenbank in verwandten Anwendungen für den Austausch, aber vermutlich sind diese Anwendungen getrennt zu einem großen Teil, weil sie die Daten sehr unterschiedlich voneinander zu behandeln.

die gleiche Architektur verwenden könnte über mehrere Anwendungen hinweg arbeiten, aber ich vorstellen, versuchen, das gleiche Geschäftslogikschicht in mehreren Anwendungen zu verwenden. "Aber warte!" Sie sagen: „Das ist dumm ... wenn ich das gleiche BLL bin mit, warum sollte ich eine separate App haben? Sie das gleiche tun!“

QED.

Answer 10

Im Idealfall ein proc nicht mehr Versionen verwenden. Wenn Sie Versionen pro Kunden benötigen, die Idee von 1 db pro Kunden untersuchen, wie für alle Kunden 1 db gegenüber. Auf diese Weise können auch für einige interessante Inszenierung von DBs auf verschiedenen Servern (zuteilen die größeren / schwereren Nutzung diejenigen, um größere Server während kleinere Hardware teilen können)

Answer 11

Wenn Sie Fähigkeit suchen den SQL-Code zu teilen versuchen den Aufbau einer Bibliothek von abstrakten Funktionen. Auf diese Weise könnten Sie einen Code wiederverwenden, die generische Dinge tut und eine separate Business-Logik für jede Anwendung zu halten. Das gleiche mit den Ansichten getan werden könnte -. Sie recht generisch gehalten werden können und für viele Anwendungen

Sie werden wahrscheinlich feststellen, dass es nicht so viele Verwendungen für gemeinsame gespeicherte Prozeduren ist, wie Sie gehen.

Das hieß wir einmal ein Projekt umgesetzt, das mit einer sehr schlecht gestalteten Legacydatenbank arbeitet. Wir haben eine Reihe von gespeicherten Prozeduren implementiert, die Information Retrieval einfach gemacht. Wenn andere Leute von anderen Teams wollten die gleichen Informationen verwenden wir unsere gespeicherte Prozeduren Refactoring, um sie generisch, hinzugefügt eine zusätzliche Schicht von Kommentaren und Dokumentation zu machen und erlaubt andere Menschen unsere Verfahren zu verwenden. Diese Lösung funktioniert recht gut.

Answer 12

Viele gespeicherte Prozeduren sind anwendungsunabhängig, aber es kann einige sein, die Anwendung abhängig sind. Zum Beispiel können die CRUD (Create, Select, Update, Delete) gespeicherten Prozeduren über mehrere Anwendungen hinweg gehen. Insbesondere können Sie bei der Prüfung von Logik werfen (manchmal in Triggern getan, aber es gibt eine Grenze, wie kompliziert Sie in Trigger zu bekommen). Wenn Sie die mittlere Ebene eine Art von Standardarchitektur in der Software-Shop kann eine gespeicherte Prozedur benötigt zum Erstellen / wählen / update / delete aus der Datenbank unabhängig von der Anwendung in diesem Fall das Verfahren geteilt wird.

Zur gleichen Zeit kann es einige nützliche Möglichkeiten, um die Daten sehen, dh GetProductsSoldBySalesPerson, etc .., die auch anwendungsunabhängig sein. Sie können für einige Felder wie Abteilung eine Reihe von Lookup-Tabellen haben, Adresse, etc., so gibt es ein Verfahren sein kann, einen Blick auf die Tabelle mit allen Textfeldern zurückzukehren. Dh statt SalesPersonID, Verkaufsdatum, CustomerID, DepartmentID, CustomerAddressID die Prozedur eine Ansicht SalesPersonName zurückgibt, Verkaufsdatum, Kundenname, Department, Customer. Dies könnte auch für Anwendungen eingesetzt werden. Ein Customer Relationship System würde Customer Name / Adresse / Andere Attribute als würde ein Billing-System wollen. Also, die etwas tat alles verbindet und bekam alle Kundeninformationen in einer Abfrage würde wahrscheinlich über mehrere Anwendungen hinweg verwendet werden. Zugegeben Möglichkeiten Erstellung der Daten ist die Domäne einer Ansicht zu betrachten, aber oft verwendet, um Menschen Stored Procedures, dies zu tun.

Also im Grunde, wenn das Löschen von Ihrem Tisch benötigen Sie aus 3 oder 4 anderen Tabellen zu löschen, um die Datenintegrität sicherzustellen. die Logik für einen Trigger zu kompliziert? Dann wird eine gespeicherte Prozedur, die alle Anwendungen verwenden Deletionen tun kann wichtig sein. Das gleiche gilt für Dinge, die bei der Erstellung getan werden müssen. Wenn es üblich sind Joins, die immer getan werden, kann es sinnvoll, eine gespeicherte Prozedur zu tun haben, alle verbindet. Wenn dann später die Tabellen drehen Sie das Verfahren das gleiche halten konnte und nur dort die Logik ändern.

Answer 13

Das Konzept ein Datenschema über mehrere Anwendungen hinweg zu teilen ist eine schwierige Frage. Unweigerlich wird Ihr Schema aus Performance-Gründen gefährdet: Denormalisierung, die Indizes zu erstellen. Wenn Sie die Größe einer Zeile in zwei Hälften geschnitten, können Sie die Anzahl der Zeilen pro Seite, und wahrscheinlich verdoppeln, halbieren die Zeit, um die Tabelle zu scannen dauert. wenn Sie jedoch ‚gemeinsame‘ Features auf der Haupttabelle enthalten und halten Daten nur von Interesse für bestimmte Anwendungen auf verschiedene (aber verwandten) Tabellen, müssen Sie überall kommen zurück auf die ‚Single-Table‘ Idee zu erhalten.

Weitere Indizes für verschiedene Anwendungen zu unterstützen, wird Zeit immer größer werdenden einfügen, aktualisieren und löschen Daten aus jeder Tabelle.

Der Datenbankserver wird oft zu einem Engpass werden als gut, weil Datenbanken können nicht mit Lastenausgleich sein. Sie können Ihre Daten auf mehrere Server, aber das wird sehr kompliziert zu.

partitionieren

Schließlich benötigt der Grad der Koordination der Regel sehr groß ist, über kein Zweifel, mit Kämpfen zwischen den verschiedenen Abteilungen, deren Anforderungen Priorität erhalten, und neue Entwicklungen werden verzetteln.

Im Allgemeinen ist die ‚isolierte Datensilos pro Anwendung‘ Modell besser funktioniert. Fast alles, was wir tun - ich für einen Vertrag Softwarehaus arbeiten -. Basiert auf Daten aus und Exportieren von Daten an andere Systeme, mit unseren Anwendungen die eigenen Datenbanken zu importieren

Es kann gut sein, leichter in Data Warehouse / Decision Support Systeme; Ich arbeite im Allgemeinen auf OLTP-Systemen, in denen Transaktionsleistung von größter Bedeutung ist.