Hunderte von Aliasen/Synonymen vs. vollqualifizierten Namen von Datenbanktabellen

Question

Bei Hunderten von Datenbanktabellen in mehreren Schemas würden Sie beim Erstellen gespeicherter Prozeduren und Ansichten die Verwendung von Aliasen/Synonymen oder vollständig qualifizierten Namen empfehlen? Gegeben ein paar schema.tabelle wie so,

Orders.OrderHeader, Production.LineThroughput, Sales.Opportunities 

Ich erwarte einen leichten Performance-Gewinn mit qualifizierten Namen verwenden, aber wenn eine Tabelle wie Orders.Customers würde Sales.Customers haben zu bewegen, würde ich entweder bestehende Ansichten/Prozeduren, die sich auf Orders.Customers beziehen, zu ändern oder ein Synonym vorzeitig zu verwenden, wenn eine solche Bewegung erwartet wird. Ich sehe den Wert beim Verschieben von Code in das Testen mit Synonymen, aber gleichzeitig könnte ich auch eine Replik meiner Produktionsumgebung erstellen, um/dev zu testen und keine Synonyme zu benötigen.

SQL Server Books Online empfiehlt, immer einen vollständig qualifizierten Namen zu verwenden. Einige Freunde schlagen vor, für jedes der Hunderte von Tabellen ein Synonym zu erstellen und nur Synonyme zu verwenden. Während ich es vorziehe, einen voll qualifizierten Namen zu verwenden (besser lesbaren und selbsterklärenden Code, zu wissen, welches referenzierte Objekt zu welchem ​​Schema gehört und wie oft die schema.table eingegeben wird), haben Sie festgestellt, welche signifikante Leistung, Betrieb oder Lesbarkeit (dis) advice Sie beobachtet haben Verwenden von Synonymen vs. vollständig qualifizierten Tabellennamen?

Answer 1

Wenn Sie erwarten, dass die Tabellen sich wirklich bewegen, seien Sie sicher, verwenden Sie voll qualifizierte Namen.

Answer 2

Ich verwende immer Aliase in Abfragen, ein Hauptgrund ist die Abfrage wird einfacher zu lesen. Wenn Sie den vollständigen Tabellennamen immer wieder wiederholen, wird der Code nur überfüllt.

Die meiste Zeit ist der Tabellenname überflüssig, es ist offensichtlich, nur aus dem Feldnamen, woher sie kommen. Sie sollten jedoch immer angeben, von welcher Tabelle Sie ein Feld erhalten, wodurch die Abfrage einfacher zu verwalten ist und weniger für Änderungen in der Datenbank relevant ist.

Eine Abfrage verwendet normalerweise nur ein paar Tabellen, und da sie verwandt sind, ist es einfach genug, die verwendeten Tabellen zu verfolgen. Wenn nicht, ist es nur ein weiterer Schritt, um zu bestimmen, was der Alias ​​bedeutet, und die Information ist direkt in der Abfrage verfügbar.

Wenn Sie eine Tabelle in eine andere Datenbank verschieben müssen, sind Aliase ebenfalls hilfreich. Da der vollständige Tabellenname nur einmal in der Abfrage angegeben wird, ist es einfacher zu ändern.

Wenn es Unterschiede in der Leistung zwischen verschiedenen Möglichkeiten gibt, das gleiche Feld anzugeben, würde nur die Abfrage analysiert werden, so dass dies minimal wäre. Wenn die Abfrage ausgeführt wird, gibt es überhaupt keine Leistungsdifferenz.

Answer 3

Dies ist eine "es kommt auf" Art der Situation.

Persönlich würde ich in einer Anwendung mit Tabellen, die über mehrere Schemas verteilt sind, lieber nicht die Code-Namen irgendwo in meinem Code fest codieren; zu diesem Zweck würde ich private Synonyme für jedes Schema erstellen, das Code hat.

Auf diese Weise, wenn eine Tabelle von einem Schema zu einem anderen verschoben wird oder (noch schlimmer) ein Schema umbenannt wird, muss ich nur die Synonyme aktualisieren, die auf es zeigen, anstatt den gesamten Code und die Ansichten durchzugehen .

Auf der anderen Seite, in einigen Fällen habe ich es vorgezogen, Code zu schreiben, die das Schema explizit bezieht - es Code für ein Datenmigrationsprojekt war, das in mehreren Schemata auf die gleiche Tabelle beziehen hatte, und wir „gesperrt nach unten "die Schemanamen, so dass es in DEV/TEST/etc funktionieren würde, ohne eine ganze Menge von Synonymen zu benötigen.

Answer 4

Der Code (SQL oder Stored Proc) sollte in einem Quellcodeverwaltungssystem außerhalb der Datenbank verbleiben. Wenn Sie nicht genau suchen und ersetzen können, haben Sie ernsthafte Probleme, also sollte das wirklich zuerst angegangen werden.

Wenn die Anzahl der Tabellen groß ist, müssen Sie unbedingt Präfixe verwenden. Nicht Sales.Customer, sondern REF_Customer.

Der Punkt gibt an, dass er sich in einer separaten Datenbank (MS und Sybase) oder einem Schema (DB2 und Oracle) befindet. Dies ist eine separate Wiederherstellungseinheit, daher werden sie separat verwaltet, und der Server muss jedes Mal, wenn Sie die Grenze überschreiten, den Kontext wechseln. Daher müssen Sie Ihre Tabellen richtig sammeln und einige Datenbanken/Schemas verwenden, nicht viele. Z.B. Trennen Sie die Referenztabellen, die nicht häufig aktualisiert werden, und werden üblicherweise von anderen dbs/Schemas referenziert.

Verwenden Sie immer vollständig qualifizierte Namen im SQL-Code. Nicht als Präfix für Spaltennamen, sondern in jeder WHERE- und FROM-Klausel. Das wird beim Verschieben von Datenbanken/Schemas oder Umgebungen, DEV in UAT oder PROD, sehr hilfreich sein.

Answer 5

Meine zwei Cent ...

persönlich die Unternehmen, die ich an haben voll qualifizierte Objektnamen verwendet gearbeitet haben, auch wenn sie auf Objekte in dem gleichen Schema verweist. In den seltenen Fällen, in denen wir eine Tabelle in ein anderes Schema verschoben haben, haben wir normalerweise aus Gründen der Abwärtskompatibilität eine Ansicht (kein Synonym) an dem alten Speicherort eingerichtet, hauptsächlich weil wir in der Vergangenheit durch Revalidierungsprobleme gebrannt wurden.

Performanceweise, zumindest in Oracle, gibt es Berichte über einen leichten Leistungseinbruch mit Synonymen, da die Datenbank zunächst den Namen des Synonyms auflösen und dann den Namen des Zielobjekts auflösen muss (table/view/package/etc.). Öffentliche Synonyme haben einen etwas größeren Leistungseinbruch (2 x den von nicht-öffentlichen Synonymen). Dies ist jedoch etwas umstritten; Weitere Informationen finden Sie unter this Ask Tom article. Wenn Sie jedoch Ihre Datenbank nicht bis an die Grenzen treiben, würde ich mir keine Sorgen machen.

Answer 6

Es gibt immer mehr als eine Antwort auf jede Frage. Deshalb "kommt es darauf an" ist immer die richtige Antwort. Ich finde, wenn du den Absichten treu bleibst und dich am Ende entwirfst, kommst du voraus.

Schemas sind für die Namensraumisolierung konzipiert. Zum Beispiel können Schemas beim Entwerfen eines SaaS-Systems sehr effektiv verwendet werden, um Probleme für mehrere Mandanten zu trennen. Schemas können auch verwendet werden, um den Test von der Produktion oder eine Anwendungsdaten von einer anderen zu trennen. Und das nicht nur für Tabellen, sondern auch für gespeicherte Prozeduren und alle anderen Datenbankobjekte.

DB2 stellt ein spezielles Register CURRENT SCHEMA genannt, die Sie nicht qualifizierten Objektnamen codieren, ermöglicht aber wie so durch einfaches Einstellen Sonderregister CURRENT SCHEMA nach rechts Schema wechseln:

SET CURRENT SCHEMA = 'Production' 

Dies ist meiner Meinung nach, ein viel besserer Ansatz als die Verwendung von Synonymen.