Standarddatenbank-IDs;System- und Benutzerwerte
https://stackoverflow.com/questions/9702
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Im Rahmen unserer aktuellen Datenbankarbeit beschäftigen wir uns mit dem Prozess der Aktualisierung von Datenbanken.
Ein immer wieder angesprochener Punkt ist der Umgang mit System vs.Benutzerwerte;In unserem Projekt werden Benutzer- und Systemwerte zusammen gespeichert.Zum Beispiel...
Wir haben eine Liste mit Vorlagen.
1, <system template>
2, <system template>
3, <system template>
Diese werden in der App einer Aufzählung (1, 2, 3) zugeordnet.
Dann kommt ein Benutzer herein und fügt hinzu ...
4, <user template>
...Und...
5, <user template>
Dann..Wir geben ein Upgrade heraus.und als Teil unserer Upgrade-Skripte einfügen ...
<new id> [6], <new system template>
DANN!!...Wir finden einen Fehler in der neuen Systemvorlage und müssen sie aktualisieren ...Das Problem ist, wie?Wir können den Datensatz nicht mit ID6 aktualisieren (da wir ihn möglicherweise als 9 oder 999 eingefügt haben, sodass wir den Datensatz mithilfe eines anderen Mechanismus identifizieren müssen).
Wir sind also zu zwei möglichen Lösungen für dieses Problem gekommen.
In der roten Ecke (Geschwindigkeit)....
Wir beginnen einfach mit Benutzer-IDs bei 5000 (oder einem anderen Wert) und testen Daten bei 10000 (oder einem anderen Wert).Dies würde es uns ermöglichen, Änderungen an Systemwerten vorzunehmen und diese bis zur unteren Grenze des nächsten ID-Bereichs zu testen.
Vorteil...Schnell und einfach umzusetzen,
Nachteil...Wenn wir keinen ausreichend großen Bereich wählen, könnten uns die Werte ausgehen!
In der blauen Ecke (Skalierbarkeit)...
Wir speichern System- und Benutzerdaten getrennt, verwenden GUIDs als Ids und führen die beiden Listen mithilfe einer Ansicht zusammen.
Vorteil...Skalierbar.Keine Einschränkungen hinsichtlich der DB-Größe.
Nachteil..Komplizierter in der Umsetzung.(viele zu eins aktualisierbare Ansichten usw.)
Ich entscheide mich voll und ganz für die erste Option, bin aber auf der Suche nach etwas Munition, die mich unterstützt!
Hat jemand eine Meinung zu diesen Ansätzen oder sogar zu einem oder mehreren, die wir übersehen haben?
Lösung
Ich hatte noch nie Probleme (Leistung oder Entwicklung – TDD und Unit-Tests eingeschlossen) bei der Verwendung von GUIDs als ID für meine Datenbanken, und ich habe an einigen ziemlich großen Datenbanken gearbeitet.Guck mal Hier, Hier Und Hier Wenn Sie mehr über die Verwendung von GUIDs (und den potenziell beteiligten GOTCHAS) als Primärschlüssel erfahren möchten – ich kann es jedoch nicht genug empfehlen, da das sichere Verschieben von Daten und die DB-Synchronisierung so einfach sind wie das Zähneputzen am Morgen: -)
Für Ihre obige Frage würde ich entweder (falls möglich) eine dritte Spalte empfehlen, die angibt, ob die Vorlage benutzer- oder systembasiert ist oder nicht, oder Sie können beim Einfügen zumindest GUIDs für Systemvorlagen generieren und eine Liste davon führen Wenn Sie also die Vorlage aktualisieren müssen, können Sie einfach auf dieselbe GUID in Ihren DEV-, UAT- und/oder PRODUCTION-Datenbanken abzielen, ohne befürchten zu müssen, andere Vorlagen zu überschreiben.Die dritte Spalte wäre jedoch praktisch, um alle System- oder Benutzervorlagen nach Belieben auszuwählen, ohne sie in zwei Tabellen aufteilen zu müssen (das ist meiner Meinung nach übertrieben).
Ich hoffe das hilft,
Rob G
Andere Tipps
Ich empfehle die Verwendung des zweiten mit der Änderung, dass Sie die System- und Benutzerwerte in einer Tabelle speichern.GUID ist auf diese Weise recht zuverlässig.
Eine andere Idee:Verwenden Sie eine beliebige textbasierte ID (keine erforderliche GUID), die Sie für die Systemwerte angeben und die durch eine zufällige Zeichenfolge oder eine Zeichenfolge basierend auf einer benutzerdefinierten Logik für die Benutzerwerte generiert wird.
Eine andere Idee:Verwenden Sie den ersten Ansatz, erweitern Sie die Tabelle jedoch um ein Flag, das anzeigt, ob es sich bei einem Wert um einen System- oder Benutzerwert handelt.Vielleicht ist das das einfachste.Ok, Sie müssen einen Mechanismus schreiben, um den korrekten Systemwert zu aktualisieren, aber das ist einfach.
+1 für Biris textbasierte ID – Definieren Sie eine textbasierte Spalte „template_mnemonic“ und machen Sie sie zum Primärschlüssel.Dies ist ein bekannter Wert, wenn Sie ihn nach Belieben einfügen, die Entwickler haben sich darüber entschieden (oder ihn automatisch generiert) und Sie können immer über seine Mnemonik auf eine Vorlage verweisen, unabhängig davon, wie viele benutzerdefinierte Vorlagen vorhanden sind.Außerdem können Benutzer eine sinnvolle Namenskonvention für ihre Vorlagen festlegen.
Vielleicht habe ich es nicht verstanden, aber könnte man nicht GUIDs als IDs verwenden und trotzdem Benutzer- und Systemdaten zusammen haben?Anschließend können Sie über die (nicht veränderbaren) GUIDs auf die Systemdaten zugreifen.
Ich denke nicht, dass GUID ein Problem darstellen sollte.
Wenn Sie dies vermeiden möchten, verwenden Sie ein Flag:
ID int
Vorlage was auch immer
Flag enum/int/bool
Flag zeigt an, ob der tatsächliche Wert ein System- oder ein Benutzerwert ist.
Wenn Sie einen Systemwert aktualisieren möchten, fragen Sie nur nach Systemwerten, die nach ID geordnet sind, und es wird Ihnen die tatsächliche Reihenfolge der Einfügung angezeigt (Sie sollten einen Bigint oder etwas Ähnliches für die ID haben, um sicherzustellen, dass sie nicht voll wird und die gelöschten IDs werden dadurch nicht wieder funktionsfähig).Mit dieser Liste ist das x.Datensatz ist das x.eingefügter Systemwert.
Ich denke, es gibt eine bessere dritte Lösung.Mir fällt auf, dass Sie zwei verschiedene Dinge in derselben Tabelle speichern und dass es möglicherweise besser wäre, zwei separate Tabellen zu erstellen, eine für Benutzervorlagen und eine für Systemvorlagen.Möglicherweise können Sie dann eine Ansicht über die beiden Tabellen erstellen, damit sie für Ihre Anwendung als ein einzelnes Objekt angezeigt werden.Offensichtlich kenne ich Ihre Anwendung nicht vollständig und dies kann für Sie aus verschiedenen Gründen unmöglich sein, aber ich denke, es ist eine sauberere Lösung als GUIDs und viel sicherer als ID-Bereiche (machen Sie im Ernst keine ID-Bereiche). beiße dich eines Tages)
