Ich arbeite an einem Legacy-Automatisierungssystem für kleine Unternehmen (Inventar, Vertrieb, Beschaffung usw.) mit einer einzigen Datenbank, die von SQL Server 2005 und einer Reihe von Client-Anwendungen gehostet wird. Der Hauptclient (von allen Benutzern verwendet) ist eine MS Access 2003-Anwendung (ADP), und andere Clients enthalten verschiedene VB / VBA-Anwendungen wie Excel-Add-Ins und Befehlszeilendienstprogramme.
Zusätzlich zu ungefähr 60 Tabellen (meistens in 3NF) enthält die Datenbank ungefähr 200 Ansichten, ungefähr 170 UDFs (meistens skalare und Tabellenwerte inline) und ungefähr 50 gespeicherte Prozeduren. Wie Sie vielleicht vermutet haben, ist ein Teil der so genannten "Geschäftslogik" in dieser Masse von T-SQL-Code eingeschlossen (und wird daher von allen Clients gemeinsam genutzt).
Insgesamt ist der Systemcode (einschließlich des T-SQL-Codes) nicht sehr gut organisiert und sozusagen refactoring-resistent. Insbesondere die Schemata der meisten Tabellen verlangen nach allen Arten von Refactorings, kleinen (wie Spaltenumbenennungen) und großen (wie Normalisierung).
FWIW, ich habe ziemlich lange und anständige Erfahrungen in der Anwendungsentwicklung (C / C ++, Java, VB und so weiter), aber ich bin kein DBA. Also, wenn die Frage für Sie albern aussieht, wissen Sie jetzt, warum es so ist. : -)
Während ich darüber nachdenke, all dieses Durcheinander zu rekonstruieren (natürlich auf friedliche Art), habe ich folgende Idee:
Erstellen Sie für jede Tabelle eine "Wrapper" -Ansicht, die (a) alle Spalten der Tabelle enthält; und (b) in einigen Fällen einige zusätzliche berechnete Spalten basierend auf den "echten" Spalten der Tabelle.
Ein typisches (wenn auch vereinfachtes) Beispiel für eine solche zusätzliche berechnete Spalte wäre der Verkaufspreis eines Produkts, das aus dem regulären Preis und Rabatt des Produkts abgeleitet wird.
Reorganisieren Sie den gesamten Code (sowohl T-SQL- als auch VB / VBA-Clientcode), sodass nur die "Wrapper" -Sichten direkt auf Tabellen verweisen.
Selbst wenn beispielsweise eine Anwendung oder eine gespeicherte Prozedur Datensätze aus einer Tabelle einfügen / aktualisieren / löschen müsste, würden sie dies mit der entsprechenden "Tabellen-Wrapper" -Ansicht tun, nicht direkt mit der Tabelle.
Es geht im Wesentlichen darum, alle Tabellen nach Sichten vom Rest des Systems zu isolieren .
Dieser Ansatz scheint eine Menge Vorteile zu bieten, insbesondere aus Sicht der Wartbarkeit. Zum Beispiel:
Wenn eine Tabellenspalte umbenannt werden soll, kann sie durchgeführt werden, ohne den gesamten betroffenen Client-Code gleichzeitig neu zu schreiben.
Es ist einfacher, abgeleitete Attribute zu implementieren (einfacher als mit berechneten Spalten).
Sie können effektiv Aliase für Spaltennamen haben.
Natürlich muss es einen gewissen Preis für all diese Vorteile geben, aber ich bin mir nicht sicher, ob ich all die Fänge sehe, die dort draußen lauern.
Hat jemand diesen Ansatz in der Praxis versucht? Was sind die größten Fallstricke?
Ein offensichtlicher Nachteil sind die Kosten für die Pflege von "Wrapper" -Sichten synchron mit ihren entsprechenden Tabellen (eine neue Spalte in einer Tabelle muss ebenfalls zu einer Ansicht hinzugefügt werden; eine aus einer Tabelle gelöschte Spalte muss aus der Ansicht gelöscht werden) zu, usw.). Aber dieser Preis scheint klein und fair zu sein, um die gesamte Codebasis belastbarer zu machen.
Kennt jemand andere, stärkere Nachteile?
Zum Beispiel hat die Verwendung all dieser "Wrapper" -Ansichten anstelle von Tabellen sehr wahrscheinlich negative Auswirkungen auf die Performance, aber wird diese Auswirkung erheblich genug sein, um sich darum zu kümmern? Bei der Verwendung von ADODB ist es außerdem sehr einfach, ein Recordset zu erhalten, das nicht aktualisierbar ist, selbst wenn es nur auf einigen verbundenen Tabellen basiert. Werden also die "Wrapper" -Ansichten die Dinge wesentlich schlechter machen? Und so weiter und so fort ...
Alle Kommentare (besonders geteilte echte Erfahrung) würden sehr geschätzt werden.
Danke!
P.S. Ich trat auf den folgenden alten Artikel, der die Idee von "Wrapper" Ansichten diskutiert:
Der Artikel empfiehlt, den oben beschriebenen Ansatz zu vermeiden. Aber ... Ich sehe keine guten Gründe gegen diese Idee in dem Artikel. Im Gegenteil, in seiner Liste der guten Gründe, eine Ansicht zu erstellen, ist fast jeder Punkt genau deshalb so verlockend, eine "Wrapper" -Ansicht für jede einzelne Tabelle zu erstellen (besonders in einem Altsystem als Teil des Refactoring-Prozesses) ).
Der Artikel ist wirklich alt (1999), was auch immer gute Gründe waren, mag jetzt nicht mehr gut sein (und umgekehrt). Es wäre wirklich interessant, von jemandem zu hören, der diese Idee kürzlich in Betracht gezogen oder sogar versucht hat, mit den neuesten Versionen von SQL Server und MS Access ...
Beim Entwerfen einer Datenbank bevorzuge ich Folgendes:
Dies ermöglicht dem DBA, direkt mit der Tabelle zu arbeiten (um Spalten hinzuzufügen, Dinge zu bereinigen, Daten einzuschleusen usw.), ohne die Codebasis zu stören, und isoliert die Codebasis von allen an der Tabelle vorgenommenen Änderungen (temporär oder ansonsten)
es kann zu Leistungseinbußen kommen, wenn man die Dinge auf diese Weise macht, aber bisher waren sie nicht signifikant - und die Vorteile der Isolationsschicht waren schon mehrmals lebensrettend.
Sie werden keine Leistungseinbußen für One-Table-Ansichten feststellen. SQL Server verwendet die zugrunde liegende Tabelle beim Erstellen der Ausführungspläne für Code, der diese Ansichten verwendet. Ich empfehle Ihnen, diese Ansichten schema-bind zu machen, um zu vermeiden, dass die zugrunde liegende Tabelle versehentlich geändert wird, ohne die Ansicht zu ändern (denken Sie an den armen nächsten Typ.)
Wenn eine Tabellenspalte umbenannt werden soll
Meiner Erfahrung nach passiert das selten. Das Hinzufügen von Spalten, das Entfernen von Spalten, das Ändern von Indizes und das Ändern von Datentypen sind die üblichen alter table-Skripte, die Sie ausführen.
Es ist einfacher, abgeleitete Attribute zu implementieren (einfacher als mit berechneten Spalten).
Ich würde das bestreiten. Was ist der Unterschied zwischen dem Einfügen der Berechnung in eine Spaltendefinition und dem Einfügen in eine Sichtdefinition? Außerdem sehen Sie einen Leistungseinbruch, wenn Sie ihn in eine Ansicht statt in eine berechnete Spalte verschieben. Der einzige wirkliche Vorteil ist, dass changing die Berechnung in einer View einfacher ist als durch Ändern einer Tabelle (aufgrund von Indizes und Datenseiten.)
Sie können Aliase für Spaltennamen haben.
Das ist der wahre Grund, um Ansichten zu haben; Aliasen von Tabellen und Spalten und Kombinieren mehrerer Tabellen. Die beste Vorgehensweise in meinen letzten Jobs bestand darin, Ansichten zu verwenden, bei denen ich die Daten denormalisieren musste (Lookups usw., wie Sie bereits erwähnt haben.)
Wie üblich lautet die ehrlichste Antwort auf eine DBA-Frage "Es kommt darauf an" - auf Ihre Situation, Ihre Fähigkeiten usw. In Ihrem Fall wird das Refactoring von "alles" sowieso alle Apps durchbrechen. Wenn Sie die Basistabellen korrekt korrigieren, ist die Indirektion, die Sie aus Ihren Ansichten abrufen möchten, nicht erforderlich und verdoppelt nur die Schemawartung für zukünftige Änderungen. Ich würde sagen, überspringen Sie die Wrapper-Ansichten, fixieren Sie die Tabellen und gespeicherten Procs (die genug Informationen bereitstellen, die bereits verstecken), und alles wird gut.
Ich stimme Steven's Kommentar - hauptsächlich, weil Sie Access verwenden. Es ist äußerst wichtig, die Vorteile / Nachteile von Access beim Neuentwurf dieser Datenbank im Fokus zu behalten. Ich war dort, habe das mit dem Access Frontend / SQL Server Backend gemacht (obwohl es kein ADP Projekt war).
Ich würde hinzufügen, dass Ansichten nützlich sind, um sicherzustellen, dass Daten nicht außerhalb der Access-Formulare im Projekt geändert werden. Der Nachteil ist, dass für alle Updates gespeicherte Prozeduren erforderlich sind - wenn Sie diese nicht bereits haben, müssten sie auch erstellt werden.
Tags und Links sql sql-server database refactoring