Ist dies eine Standardmethode zum Entwerfen einer Datenbank?

Ich habe kürzlich erfahren, wie Beziehungen in der Datenbank bei der Arbeit definiert werden, und mich gefragt, ob dies eine Standardpraxis ist.

Angenommen, wir haben zwei Prozesse: Prozess A und Prozess B. Prozess B hängt von den Ergebnissen von Prozess A ab. Daher muss eine Beziehung zwischen einem Lauf von Prozess B und einem Lauf von Prozess A definiert werden. So wird die Beziehung definiert:

TableProcessA:
Id

und

TableProcessB:
Id
ProcessAId

Bis zu diesem Punkt machen die Dinge für mich Sinn, aber dann werden die Dinge für mich und mein Verständnis von Tischgestaltung etwas seltsam. Immer wenn eine Zeile in TableProcessA oder TableProcessB erstellt wird, wird eine Funktion aufgerufen, die für jede eine global eindeutige ID erstellt. Grundsätzlich enthalten alle ID-Felder in TableProcessA und TableProcessB keine Übereinstimmungen, da die IDs nicht nur für die Tabelle, sondern für die gesamte Datenbank eindeutig sind.

Meine Frage ist, wie Standard ist das? Ich kam auf die Idee, dass jede Tabelle einfach eine automatisch inkrementierende ID haben sollte, die nur für die Tabelle und nicht für die gesamte Datenbank eindeutig ist.

Das ist keine so seltsame Übung. Diese werden als GUIDs oder global eindeutige IDs bezeichnet. Die Idee ist, dass Sie anhand einer GUID genau sagen können, zu welchem ​​Datenelement die ID gehört, da sie überall eindeutig ist . GUIDs werden am besten verwendet, wenn Sie verschiedene Quellen ähnlicher Daten zusammenführen. Zum Beispiel Inventar für verschiedene Geschäfte.

Ich würde einige Nachforschungen anstellen und herausfinden, warum dies in Ihrer Umgebung üblich ist. Vielleicht wird es gebraucht, vielleicht nicht.

Im Prinzip ist es nicht schlecht, eindeutige IDs in einer Datenbank zu haben, aber meiner Erfahrung nach eher ungewöhnlich. Sofern keine besonderen Anforderungen für die Verwaltung eines global eindeutigen ID-Schlüssels bestehen, sollte die Verwendung der normalen Identität in Ordnung sein, da die Entitätstypen oder Objekte in der Regel typspezifisch sind und normalerweise nicht zu unangemessenen Verknüpfungen führen.

Abgesehen von Ihrer Frage würde ich dringend empfehlen, GUIDs nicht als Primär- oder Ersatzschlüssel zu verwenden, da sie viermal so viel Platz wie ein Int beanspruchen. In Zeiten von Multi-Gigabyte-Festplatten könnte man sagen, dass dies nicht wichtig ist, aber wenn Sie über einige Millionen Datenzeilen verfügen, sind immer noch Ressourcen erforderlich, um von der Festplatte zu lesen oder über ein Netzwerk zu übertragen. Dies gilt umso mehr, wenn sie in Indizes enthalten sind. Während ich mich mit den Themenindizes befasse, sind GUIDs in Primärschlüsseln aufgrund ihrer zufälligen Natur schlecht und verursachen normalerweise eine signifikante Fragmentierung.

Jetzt ist es wahrscheinlich zu spät für diese Datenbank, aber denken Sie für die Zukunft daran

Ihre Prozesse können Datensätze erstellen, die die GUID als Referenz auf die Prozessinstanz enthalten. Die Verwendung der GUIDs als Schlüssel ist jedoch nicht unbedingt optimal.

Ich sehe drei Hauptnachteile bei der Verwendung von GUIDs als Datenbankschlüssel und würde sie vermeiden, es sei denn, Sie haben einen zwingenden Grund, sie zu verwenden. Beachten Sie, dass die global eindeutige Eigenschaft keine Vorteile gegenüber der Verwendung eines lokal eindeutigen Schlüssels in einer Tabelle bietet, da Sie bereits wissen, aus welcher Tabelle die Daten stammen.

Unbequemlichkeit: Es ist nicht besonders einfach, eine GUID einzugeben, wenn Sie eine Ad-hoc-Abfrage der Datenbank durchführen möchten, zum Beispiel:

select *
  from Foo
 where FooID = 12345

vs.

select *
  from Foo
 where FooID = convert (uniqueidentifier, '5E64E653-35F0-4803-B459-F5F59C701F22')

Letzteres bedeutet praktisch, dass Sie eine Quelle der GUID zum Ausschneiden und Einfügen benötigen.

2. Natürliche Ordinalität: Ein automatisch inkrementierender Primärschlüssel hat den Nebeneffekt, dass Ihre Transaktionen auf natürliche Weise in der Reihenfolge angeordnet werden, in der sie in das System eingegeben wurden. Dies ist oft sehr nützlich. GUIDs werden normalerweise nicht in der richtigen Reihenfolge generiert, daher sind sie in dieser Hinsicht nicht von Nutzen.

3. Größe: Heutzutage weniger problematisch, aber eine GUID ist 16 Byte lang. Es nimmt mehr Platz in der Tabelle und allen darin enthaltenen Indizes ein.

Ich werde nicht sagen, dass es normal ist, aber es ist auch nicht ungewöhnlich, die Dinge so einzurichten.