Identitätsspalten oder UDF, die explizit eine eindeutige ID generieren?

dba.stackexchange https://dba.stackexchange.com/questions/1632

Frage

Ich bin mitten in einer Debatte darüber, ob es besser ist, eine zu machen PRIMARY KEY aus einem Identitätsspalten, unser aus einer UDF, die explizit eine eindeutige ID generiert.

  • Ich streite für die Identitätsspalte.
  • Mein Partner argumentiert dafür, die Werte manuell zu generieren, behauptet er
    • Indem wir den UDF auf einen anderen Tisch legen, an dem wir einen UDF haben können
      • Sperren Sie die Ressource
      • Inkrementieren Sie eine ID -Tabelle mit einem aufgerufenen Feld ID_Value durch 1
      • Verwenden Sie dies als globale eindeutige Kennung
    • Oder den Tisch machen lassen eine id+1 Beim Einfügen
    • Dass es einfacher ist, Daten zwischen Servern und/oder Umgebungen zu verschieben, die nicht die Einschränkung identifizieren; Wenn Sie von einem dB wechseln, wo Daten zu einem anderen ähnlichen DB mit Ans Anhand von Staging- oder Dummy -Daten vorhanden sind. Für Tests in der Nichtproduktion möchten wir möglicherweise alle Datensätze von gestern bis zur Inszenierung zum Testen ziehen.

Welche Implementierung macht mehr Sinn?

War es hilfreich?

Lösung

Ihr Kollege ist ein Idiot.

Die Lösung wird nicht skalierbar, die UDF ist nicht gleichzeitig (Der gleiche Grund wie dieser). Und wie gehen Sie mit Multi-Reis-Einsätzen um: Dies würde einen UDF-Anruf pro Zeile erfordern

Und die Migration zu anderen RDBMs findet im wirklichen Leben nicht oft statt ... Sie können jetzt nicht SQL Server verwenden und Sequenzen für Oracle verwenden und hoffen, dass Sie nicht wegmigrieren.

Bearbeiten:

In Ihrem Update heißt es, dass sich bewegende Daten für die Aktualisierung von Nichtproduktionsdatenbanken beziehen.

In diesem Fall ignorieren Sie die Identitätsspalten beim Auffrischen. Sie gefährden Ihre Implementierung nicht, um das Laden von Nicht-Prod-Laden zu erleichtern. Oder verwenden Sie Tempentabellen, um die Identitätswertänderungen zu verfolgen.

Oder verwenden Sie Prozesse: Wir aktualisieren unser Testsystem jeden Abend von der Produktion, was das Problem vollständig vermeidet. (Und stellt sicher, dass unsere Prod -Backup auch wiederhergestellt werden kann)

Andere Tipps

Verwenden Sie einen Identitätswert. Wenn Sie Ihre eigene Sequenztabelle und Sequenzwerte generieren, werden viel Aufwand erfolgt und viel Sperren und Blockieren verursacht, während Sie versuchen, Zahlen zu generieren.

Identität existiert aus einem bestimmten Grund, benutze sie.

Wenn SQL Denali herauskommt, unterstützt es Sequenzen, die effizienter als Identität sind, aber Sie können selbst nicht etwas effizienteres erstellen.

Das Verschieben von Aufzeichnungen von einer Umgebung in eine andere, entweder Identity_insert, wenn Sie das Einfügen durchführen, oder das Kontrollkästchen in SSIS aktivieren.

Die Identitätsspalte klingt für mich gut. Ich bin mir nicht sicher, ob ich der Logik darüber folge, warum es schwierig ist, Daten zwischen Servern zu verschieben.

Wenn Sie möchten, dass jede Reihe eine global eindeutige Identität hat, können Sie eine UUID verwenden, aber ich würde es nicht tun, es sei denn, Sie sind sicher, dass die globale Einzigartigkeit erforderlich ist - normalerweise ist dies nicht der Fall. Die Verwendung von UUIDs als IDS verringert die Leistung, erhöht die Anforderungen an die Festplattenraum und erschwert das Debuggen. Aufgrund der Länge ist es schwierig, sich an eine UUID zu erinnern, es jemandem telefonisch zu sagen oder es ohne Fehler auf Papier aufzuschreiben.

Gehen Sie für einfache numerische IDs einfach mit Identität und vergessen Sie alle Probleme, sie manuell zu erzeugen.

Sie können jederzeit eine "Super -Tabelle" erstellen, die eine Identität als PK verwendet und eine Typspalte und andere Informationen haben. Wenn Sie eine neue ID benötigen (vorausgesetzt, Sie bedeuten eindeutige IDs über verschiedene Tabellen) setzen Sie einfach in diese Tabelle ein und schnappen Sie sich die SCOPE_IDENTITY() und dann in die tatsächliche Tabelle einfügen, die Sie benötigen.

Grundsätzlich erstellen Sie eine Tabelle: Masteride Mit einer Identität PK, wenn Sie eine Zeile in Ihr Tabelle 1 einfügen müssen, INSERT INTO MasterIDs und erhalten Sie die Identität, die durch diese Zeile generiert wird SCOPE_IDENTITY() und dann einfügen in Tabelle 1 Verwenden Sie diesen Wert als PK.

Tabelle 1 wird eine Nicht-Identität int pk haben. Sie würden den gleichen Prozess durchführen, um in Tabelle2 usw. einzufügen, usw. Es sei SQL Server die Identitätswerte in der Masteride Tabelle, die Sie dann in Ihren anderen Tabellen verwenden können. Masteride Könnte andere Tabellen wie Typ enthalten (damit Sie wissen, welche Tabelle, Tabelle1 oder Tabelle2 usw. diesen Identitätswert verwendet.

Solange Sie fremde Schlüsselbeschränkungen ordnungsgemäß verwenden (Kaskadierung, Aktualisierung usw.), werden Sie mit der Verwendung eines Identitätsfeldes in Ordnung sein. Ich sehe in diesem Fall wirklich keinen Vorteil für die andere Lösung.

Identität wurde für Ihr Szenario geeignet. Sie verfügen über Tools wie Replikation für Server-/Umgebungsdatenaustausch, die alles zusammenhalten.

Ich habe gerade eine Arbeit beendet, bei der ich einen SQL -Server ersetzt habe identity Säule mit normaler Säule int Feld und kontrollierte ID -Zuweisung selbst.

Ich habe ziemlich beeindruckende Leistungsgewinne gesehen. Im Gegensatz zum OP habe ich keinen UDF, um die ID zu generieren. Aber das Prinzip ist ziemlich gleich: Es gibt einen Teil der Software, der einen ID -Pool unterhält. Wenn sie ausgehen, wird eine weitere Stapel erhalten, indem die Datenbank für die nächste abfragt Niedrig Wert und erhöht dies zum nächsten Hoch.

Auf diese Weise können wir IDs generieren und alle Entitäten außerhalb einer Transaktion in unserem ORM in Beziehung setzen, bevor wir die Stapel in die Datenbank übermitteln und größere Stapel ohne zusätzliche Roundtrips einreichen, um die gerade eingefügte Identität zu erhalten (erforderlich durch Identitätsspalten).

In der ID -Tabelle, die wir haben, gibt es mehr als eine Zeile, sodass wir bestimmte Bereiche verwenden können, wenn wir dies wünschen. dh für die Wiederverwendung von gelöschten Blöcken und negativen IDs.

Ich benutze Identität seit Jahren und erwähne ernsthaft darüber nach, die Identitätsnummer durch eindeutig Identifikator zu ersetzen. Es ist ein Albtraum, wenn Sie den Datentyp ändern müssen, wenn jemand ihn als kompakte DB und Albtraum entworfen hat, wenn Sie einer Spalte Identität hinzufügen müssen. Außerdem können Sie keine Identitätsspalte aktualisieren. Stellen Sie sich vor, Sie setzen eine INT ein und Ihre Datenbank wächst über 2 Milliarden Datensätze hinaus, wieder Albtraum, um sich zu ändern (betrachten Sie FKS)! Etwas mit Identität zu ändern ist ein Albtraum und nicht skaliert freundlich, es sei denn, Sie setzen Bigint! Uniqueidentifier vs Identität = Bequemlichkeit und Robustheit gegen vielleicht spürbare Leistungsverbesserung (nicht den Benchmark).

Update: Nachdem ich gesehen habe Dies Ich neige definitiv zu Uniqueidentifier. Dies zeigt keinen wirklichen Nutzen von Bigint -Identität und einer Reihe von Vorteilen für Uniqueidentifier! Verschiedene Versionen von SQL Server könnten ein anderes Ergebnis erzielen. Es gibt nur Schönheit, eine eindeutige ID in allen Datenbanken und Systemen (Robustheit) zu haben! Verschieben, kopieren, Daten nach Beliebene transformieren!https://www.mssqltips.com/sqlservertip/5105/sql-server-performance-comparison-int-versus-guid/

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit dba.stackexchange
scroll top