E-Mail-Adresse eindeutig oder Primärschlüssel?

Ich bin ein Neuling in Datenbanken. Ich habe herumgelesen und festgestellt, dass es wahrscheinlich keine gute Idee ist, die E-Mail-Adresse als Primärschlüssel zu verwenden, da Zeichenfolgenvergleiche langsamer sind, was sich auf die Leistung bei komplexen Verknüpfungen auswirkt. Wenn sich eine E-Mail ändert, muss ich alle Fremdschlüssel ändern, was viel erfordert der Anstrengung.

Wenn meine Benutzertabelle erfordert, dass jeder Benutzer eine E-Mail-Adresse hat und jede dieser E-Mail-Adressen eindeutig sein sollte, reicht es dann aus, einen eindeutigen Index für die E-Mail-Spalte hinzuzufügen? Weil afaik eindeutige Felder Nullwerte zulassen, während jeder Benutzer eine E-Mail-Adresse haben muss, ohne Nullwerte zuzulassen. Fehlt mir hier etwas? Oder soll ich die E-Mail-Spalte eindeutig machen und während der Datenüberprüfung auf dem Server sicherstellen, dass der Benutzer eine E-Mail-Adresse eingibt, damit jeder Benutzer eine hat?

postgresql primary-key unique-constraint

— aandis
quelle

Was passiert, wenn ein Benutzer seine E-Mail-Adresse ändert - wie er z. B. den Job wechselt

— user151019

Zeichenfolgenvergleiche sind nicht nur langsamer, Zeichenfolgen sind in der Regel auch größer als beispielsweise eine Ganzzahl. Daher können Sie weniger auf eine Seite im Speicher passen und Ihre logischen Lesevorgänge für Abfragen erhöhen.

— Nameless One

Antworten:

Lassen Sie uns zunächst zwischen Schlüsseln und Indizes unterscheiden. Der Schlüssel ist Teil des logischen Modells und wird häufig mit einem eindeutigen Index implementiert. Sie können jedoch einen eindeutigen Index erstellen, ohne einen Schlüssel zu erstellen, auf den jedoch kein Fremdschlüssel verweisen kann.

Ein Kandidatenschlüssel ist etwas, das eine Zeile in einer Tabelle eindeutig identifiziert. In SQL wird normalerweise einer der Kandidatenschlüssel als Primärschlüssel verwendet (ich habe nie wirklich verstanden, warum einer der ck als "besser" eingestuft wird als der andere, aber das ist ein anderer Geschichte), und das verbleibende ck wird zu einzigartigen Einschränkungen.

Eine eindeutige Einschränkung kann genauso verwendet werden wie ein Primärschlüssel. Erwägen:

create table A ( x ... not null
               , y ... not null
               , z ... not null
               ,     unique (x)
               ,     primary key (y,z) );

create table B ( x ...
               ,   ...
               ,     foreign key (x) references A (x) );

create table C ( y ...
               , z ...
               ,   ...
               ,     foreign key (y, z) references A (y, z) );

B verweist auf die eindeutige Einschränkung und C verweist auf die Primärschlüsseleinschränkung.

NOT NULL ist eine weitere Art von Einschränkung. In Ihrem Fall können Sie dies für E-Mails erzwingen, ohne sie als eindeutig zu deklarieren.

Der nächste Aspekt Ihres Beitrags betrifft die Stabilität eines Schlüssels. Ein Schlüssel sollte stabil sein (aber das bedeutet nicht, dass er sich niemals ändern kann, er muss nicht unveränderlich sein). Einige DBMS implementieren ON UPDATE CASCADE, die für einen solchen Vorgang hilfreich sein können. Wenn der Schlüssel jedoch um Ihr Modell verteilt ist, ist es schwierig, ihn zu aktualisieren.

In Ihrem Fall würde ich wahrscheinlich einen anderen Kandidatenschlüssel als Primärschlüssel auswählen und die E-Mail als NICHT NULL und EINZIGARTIG deklarieren.

— Lennart
quelle

In SQL Server können Sie einen eindeutigen Index als FK referenzieren.

— Martin Smith

Ich habe keinen Zugriff auf SQL, kann also nicht selbst überprüfen. Erstellt dies implizit eine eindeutige Einschränkung, wenn Sie einen eindeutigen Index erstellen?

— Lennart

Nein. Eine eindeutige Einschränkung wird geringfügig anders behandelt und weist im Vergleich zu einem eindeutigen Index einige zusätzliche Metadaten und zusätzliche Einschränkungen auf. SQL Server ermöglicht jedoch die Verwendung von beiden in einem FK.

— Martin Smith

Das ist ein bisschen seltsam, Indizes werden im SQL-Standard nicht einmal erwähnt, während Schlüssel ein zentraler Bestandteil davon sind. Trotzdem danke für die Information.

— Lennart

Es ist erwähnenswert, dass es einige Zeit in Anspruch nehmen kann, alle Datensätze zu aktualisieren, wenn die Aktualisierungskaskaden vorliegen, wenn Ihre E-Mail viele Fremdschlüssel enthält.

— Cimmanon

Ja, ein eindeutiger Index für die Spalte "EmailAddress" sollte in Ordnung sein. Das einzige Problem wäre, wenn jemand die E-Mail-Adresse nach der Anmeldung für Ihren Dienst aufgibt, es Ihnen aber nicht sagt, und wer auch immer der Eigentümer der E-Mail-Adresse versucht, sich anzumelden. Aber das ist ein ziemlich seltener Randfall.

Ob ein eindeutiger Index Nullwerte zulässt, die von Ihrer Datenbankplattform abhängen. Oracle erlaubt, SQL Server erlaubt einen einzelnen NULL-Wert. Sie können dies lösen, indem Sie dafür sorgen, dass die Spalte keine NULL-Werte zulässt, und dann den eindeutigen Index darauf erstellen.

— mrdenny
quelle

Das gilt nicht für SQL Server. Sie können Indizes mit whereKlauseln erstellen, mit denen Sie beispielsweise NULLWerte aus dem Index ausschließen können.

— Kirk Woll

Die Aussage SQL Server allows a single NULL valueist immer noch wahr. Es heißt nicht, dass es keine Möglichkeit gibt, mehrere NULLWerte zu erhalten. Ich denke, der Antwortende hat versucht, die Antwort einfach zu halten und keine zusätzlichen Details zu erklären (wie gefilterte indizierte).

— Brandon

Ja, ich hätte das Kaninchen ganz nach gefilterten Indizes durchsuchen können, aber eine einfache Frage braucht normalerweise eine einfache Antwort. Ohne Datenbankplattform und Version halte ich meine Antworten generisch.

— Mrdenny

Der eindeutige Index für EmailAddress ist in Ordnung.

Da Sie bereits angegeben haben, dass in Ihrem Antrag eine Validierung für die Angabe der E-Mail-Adresse als Pflichtfeld vorhanden ist, würde ich sagen, dass die andere Validierung aus der Datenbank keinen Benutzer ohne E-Mail-Adresse akzeptiert und auch doppelte Eingaben und diese Validierung verhindert wird mit diesem einzigartigen Index auferlegt.

Wie in einer anderen Antwort für SQL Server angegeben, müssen Sie vor dem Erstellen eindeutiger Indizes festlegen, dass in einer Spalte kein Nullwert zulässig ist.

— vijayp
quelle