Ich habe eine Anwendung, die sehr stark auf gespeicherten Prozeduren beruht (SQL 2005/2008). Wir machen ein kleines Update, das 25 bis 35 dieser gespeicherten Prozeduren ändern wird. Die Anwendung ist so, dass beide Versionen der gespeicherten Prozedur verfügbar sein müssen.
Dies ist Hauptversion 4 der Anwendung und in der Regel konnten wir die Datenstruktur für jede neue Version vollständig ändern. Aber in diesem Fall können wir das nicht tun.
Hier sind meine 2 Möglichkeiten, die ich mir ausgedacht habe
Erstellen Sie eine "2" -Version für jede gespeicherte Prozedur. Wenn ich eine Prozedur namens getUser hatte, erstellen Sie einen getUser2. Der Nachteil davon ist, dass die Anzahl gespeicherter Prozeduren mit jeder Versionsänderung exponentiell anwachsen wird
Fügen Sie jeder gespeicherten Prozedur, die standardmäßig auf v1 festgelegt ist, einen @version-Parameter hinzu. Dies würde die Anzahl gespeicherter Prozeduren niedrig halten, würde jedoch jede gespeicherte Prozedur aufblähen.
Hat jemand irgendwelche Gedanken dazu? Irgendwelche anderen schlauen Ideen?
Cody
Ich würde diese Gelegenheit nutzen, um von gespeicherten Prozeduren zu einem ORM oder einem anderen Ansatz überzugehen. Beide von Ihnen vorgeschlagenen Lösungen erfordern eine Art Codeänderung, um zu entscheiden, welche gespeicherte Prozedur verwendet werden soll. Stattdessen würde ich entscheiden, ob die gespeicherten Prozeduren oder das ORM verwendet werden sollen. Ich würde auch Pläne ausarbeiten, die meisten gespeicherten Prozeduren auslaufen zu lassen.
Ich habe in meiner Karriere eine Menge schlechten Code und verpatzte Systeme gesehen, aber nichts bringt meine Hoffnungen zum Ausdruck, dass ein Projekt gerettet werden kann, wie zum Beispiel GetItemFromLots_2_Temp_2 in der Liste gespeicherter Prozeduren zu sehen. Mehrere Methoden sind viel schöner und einfacher zu pflegen als mehrere gespeicherte Prozeduren.
(An andere, die Stored Procedures lieben. Ich sage nicht, dass sie schlecht sind. Ich bin mir sicher, dass es clevere Ansätze gibt, um solche Dinge mit gespeicherten Prozeduren zu handhaben, aber wenn solch ein Ansatz verwendet würde, diese Frage wäre nicht gefragt worden.)
Ändern Sie die vorhandenen gespeicherten Prozeduren so, dass die neue Logik nur dann bedingt ausgeführt wird, wenn der Prozess unter den Umständen aufgerufen wird, unter denen die neue Logik ausgeführt werden soll ... Wenn der neue Prozess eine etwas andere Schnittstelle hätte (Gruppe von sProc Parameter) dann könnten Sie sie optional machen und die Anwesenheit oder Abwesenheit des Parameters einen Schalter verwenden, um zu steuern, welcher Chunkl des Codes innerhalb des proc ausgeführt wird ...
Wenn die alte Logik nicht mehr benötigt wird, können Sie sie einfach aus den sProcs entfernen
Ich würde nicht zwei verschiedene Dateien erstellen, die sicher sind.
Vielleicht sollten Sie in Ihrer Quellcodeverwaltung eine Verzweigung aller Ihrer Versionssteuerungen erstellen und dann eine neue Verzweigung mit Ihrer nächsten Version, dann können Sie beide Verzweigungen als separate Ordner in Ihr System aufnehmen und Ihre Geschäftslogik auf die richtiger Ort.
Diese Lösung mag ein wenig schlampig sein, aber ich denke, es ist das kleinere Übel.
Unabhängig davon ist die Versionskontrolle Ihres Codes für gespeicherte Prozeduren meiner Meinung nach ein absolutes Muss.
Ich würde die zweite Option vorschlagen, die Sie angegeben haben. Verwenden Sie einen Versionsparameter. Dies ist, was Webdienste tun, damit sie nicht den Code von Apps brechen, die vor langer Zeit mit der API begonnen haben, aber die API wird irgendwann aktualisiert.
Ich wette, es gibt eine Logik, die zwischen den beiden Versionen die gleiche ist, die Sie in die Unterseite des Procs oder etwas abstrahieren könnten. Oder Sie können möglicherweise Funktionen für allgemeine Elemente erstellen und diese Funktionen in Ihren großen IF / SWTICH-Blöcken aufrufen.
Früher haben wir in meiner Firma häufig gespeicherte Prozeduren benutzt, sind aber (meistens) in letzter Zeit von ORM weggezogen.
Wir verwenden sie immer noch, und unsere Versionierung ist die gleiche wie zuvor: Jedes Mal, wenn wir die gespeicherten Prozeduren modifizieren (die nur ein paar Leute haben), speichern wir die SQL ab und speichern die .SQL-Datei in unserer Versionskontrolle.
Es ist unvollkommen und wir verlieren viel von der Integration, die wir zwischen der Quellcodeverwaltung und unseren Code-Dateien haben (da es keine SQL-Server-Integration in TFS gibt), aber es ist besser als gar keine Versionskontrolle.
BEARBEITEN - und das funktioniert natürlich nur, wenn Sie nicht mehr die alte Version des gespeicherten Procs verwenden müssen, da es nicht mehr in einer ausführbaren Form existiert.
Ein weiterer interessanter Ansatz wäre, den gesamten Code für Ihre gespeicherten Prozeduren zusammen mit der Version für den Code in einer Datenbanktabelle zu speichern. Dann haben Sie eine "Frontend" -Prozedur, die Anfragen bearbeitet und dann je nach Version dynamisch einen Proc erstellt und ausführt. Es kann dann das Proc fallen lassen, wenn es fertig ist.
Nur ein Vorschlag von der Wand, aber kann für Sie arbeiten.
Ich würde für die zwei Dateien Option aus den folgenden zwei Gründen gehen:
Tags und Links architecture sql-server-2005 stored-procedures database-design