In Tabellen, in denen Sie nur eine Spalte als Schlüssel benötigen und Werte in dieser Spalte können ganze Zahlen sein, wenn Sie kein Identitätsfeld verwenden sollten?
Im Gegensatz dazu würden Sie in derselben Tabelle und Spalte wann ihre Werte manuell generieren und Sie würden keinen automatisch generierten Wert für jeden Datensatz verwenden?
Ich nehme an, dass dies der Fall wäre, wenn es viele Einfügungen und Löschungen in der Tabelle gibt. Habe ich recht? Welche anderen Situationen könnten sein?
Wenn Sie sich bereits auf der Ersatzseite des Großen Primärschlüssel-Debakels entschieden haben, kann ich keinen einzigen Grund finden Verwenden Sie keine Identitätsschlüssel. Die üblichen Alternativen sind Guids (sie haben viele Nachteile, vor allem von Größe und Zufälligkeit) und von der Anwendungsebene generierte Schlüssel. Aber das Erstellen eines Ersatzschlüssels in der Anwendungsschicht ist ein bisschen schwieriger als es scheint und deckt auch nicht anwendungsbezogenen Datenzugriff (dh Batch-Ladevorgänge, Importe, andere Anwendungen usw.) nicht ab. Der einzige Spezialfall sind verteilte Anwendungen, wenn GUIDs und sogar sequenzielle GUIDs eine bessere Alternative zu Site ID + Identitätsschlüsseln bieten können.
Ich nehme an, wenn Sie eine Viele-zu-Viele-Verknüpfungstabelle erstellen, in der beide Felder Fremdschlüssel sind brauche kein Identitätsfeld.
Heutzutage stelle ich mir vor, dass die meisten ORMs erwarten, dass es in jeder Tabelle ein Identitätsfeld gibt. Im Allgemeinen ist es eine gute Praxis, eine zu liefern.
Ich bin mir nicht sicher, ob ich genug über Ihren Kontext verstehe, aber ich interpretiere Ihre Frage so:
"Wenn die Datenbank eine eindeutige Spalte (aus welchen Gründen auch immer) erstellen soll, wann sollte es nicht eine monoton steigende Ganzzahl (Identität) sein?"
In diesen Fällen besteht kein Grund, etwas anderes als die vom DBMS zur Verfügung gestellte Einrichtung zu diesem Zweck zu verwenden. In Ihrem Fall (SQL Server?) ist das eine Identität.
Außer:
Wenn Sie die Tabelle jemals mit Daten aus einer anderen Quelle zusammenführen müssen, verwenden Sie eine GUID, die verhindert, dass doppelte Schlüssel kollidieren.
Ein Fall, in dem man kein Identitätsfeld haben möchte, wäre in einer Eins-zu-eins-Beziehung. Die Sekundärtabelle würde als Primärschlüssel denselben Wert wie die Primärtabelle haben. Der einzige Grund, ein Identitätsfeld in dieser Situation zu haben, scheint ein ORM zu sein.
Sie können (normalerweise) keine Werte angeben, wenn Sie in Identitätsspalten einfügen. Wenn beispielsweise die Spalte "id" als Kennung angegeben wurde, würde das folgende SQL fehlschlagen:
%Vor%Um diese Art von Einfügung durchführen zu können, muss IDENTITY_INSERT für diese Tabelle aktiviert sein - dies ist normalerweise nicht vorgesehen und kann nur zu einem beliebigen Zeitpunkt für maximal 1 Tabellen in der Datenbank aktiviert sein.
Wenn ich ein Ersatzzeichen brauche, würde ich entweder eine IDENTITY-Spalte oder eine GUID-Spalte verwenden, abhängig von der Notwendigkeit der globalen Eindeutigkeit.
Wenn es einen natürlichen Primärschlüssel gibt oder der Primärschlüssel als eindeutige Kombination anderer Fremdschlüssel definiert ist, dann habe ich normalerweise keine IDENTITÄT, noch verwende ich ihn als Primärschlüssel.
Es gibt eine Ausnahme, bei der es sich um Snapshot-Konfigurationstabellen handelt, die ich mit einem Audit-Trigger verfolgen kann. In diesem Fall gibt es normalerweise einen logischen "Primärschlüssel" (normalerweise das Datum des Snapshots und den natürlichen Schlüssel der Zeile - wie eine Kostenstellen- oder gl-Kontonummer, für die die Zeile ein Konfigurationsdatensatz ist), aber statt des natürlichen "Primärschlüssel" als Primärschlüssel, ich füge einen IDENTITY hinzu und mache diesen zum Primärschlüssel und mache einen eindeutigen Index oder eine Einschränkung für das Datum und den natürlichen Schlüssel. Obwohl theoretisch das Datum und der natürliche Schlüssel sich nicht ändern sollten, möchte ich in diesen Tabellen, wenn ein Benutzer das tut, anstatt eine neue Zeile hinzuzufügen und die alte Zeile zu löschen, die Überprüfung (die eine Änderung einer durch den Primärschlüssel identifizierten Zeile widerspiegelt) ) um wirklich eine Veränderung in der Reihe zu reflektieren - nicht das Verschwinden eines Schlüssels und das Erscheinen eines neuen.
Ich habe kürzlich eine Suffix-Anweisung in C # implementiert, die Romane indexieren und dann Suchvorgänge extrem schnell und linear zur Größe der Suchzeichenfolge ermöglichen kann. Ein Teil der Anforderungen (dies war eine Hausaufgabe) bestand darin, Offline-Speicher zu verwenden. Daher verwendete ich MS SQL und benötigte eine Struktur, um einen Knoten in einer Tabelle darzustellen.
Ich hatte die folgende Struktur: NodeID Character ParentID, etc, wobei die NodeID ein Primärschlüssel war.
Ich wollte das aus zwei Gründen nicht als autoinkrementierende Identität machen.
Tags und Links sql-server performance