it-swarm.com.de

E-Mail-Adresse als Primärschlüssel verwenden?

Ist die E-Mail-Adresse ein schlechter Kandidat für die Primärdatenbank, wenn sie mit automatisch zunehmenden Zahlen verglichen wird?

Für unsere Webanwendung muss die E-Mail-Adresse im System eindeutig sein. Also dachte ich daran, die E-Mail-Adresse als Primärschlüssel zu verwenden. Mein Kollege schlägt jedoch vor, dass der Zeichenkettenvergleich langsamer ist als der Ganzzahlvergleich. 

Ist es ein triftiger Grund, E-Mail nicht als Primärschlüssel zu verwenden?

Wir verwenden PostgreSQL.

216
robert

Der Zeichenkettenvergleich ist langsamer als der Int-Vergleich. Dies spielt jedoch keine Rolle, wenn Sie einen Benutzer einfach über die E-Mail-Adresse aus der Datenbank abrufen. Es ist wichtig, wenn Sie komplexe Abfragen mit mehreren Joins haben.

Wenn Sie Informationen zu Benutzern in mehreren Tabellen speichern, ist die E-Mail-Adresse die Fremdschlüssel für die Benutzertabelle. Das bedeutet, dass Sie die E-Mail-Adresse mehrfach speichern.

272
Sjoerd

Ich möchte auch darauf hinweisen, dass E-Mail eine schlechte Wahl für ein einzigartiges Feld ist. Es gibt Menschen und sogar kleine Unternehmen, die sich eine E-Mail-Adresse teilen. Und wie Telefonnummern können emails wiederverwendet werden. [email protected] kann leicht zu John Smith ein Jahr und zu Julia Smith zwei Jahre später gehören.

Ein weiteres Problem bei E-Mails ist, dass sie sich häufig ändern. Wenn Sie sich mit diesem Schlüssel als Schlüssel zu anderen Tabellen zusammenschließen, müssen Sie auch die anderen Tabellen aktualisieren. Dies kann ein Leistungseinbruch sein, wenn ein ganzes Kundenunternehmen seine E-Mails ändert.

171
HLGEM

der Primärschlüssel sollte unique undconstantsein.

e-Mail-Adressen ändern sich wie die Jahreszeiten. Nützlich als Sekundärschlüssel für die Suche, aber eine schlechte Wahl für den Primärschlüssel.

95
Steven A. Lowe

Nachteile der Verwendung einer E-Mail-Adresse als Primärschlüssel:

  1. Langsamer beim Joins.

  2. Jeder andere Datensatz mit einem veröffentlichten Fremdschlüssel hat jetzt einen höheren Wert, wodurch mehr Speicherplatz benötigt wird. (Angesichts der heutigen Kosten für Festplattenspeicher ist dies wahrscheinlich ein triviales Problem, mit der Ausnahme, dass das Lesen des Datensatzes jetzt länger dauert. Siehe Punkt 1.)

  3. Eine E-Mail-Adresse könnte sich ändern, wodurch alle Datensätze, die diesen als Fremdschlüssel verwenden, aktualisiert werden. Da sich die E-Mail-Adresse nicht allzu oft ändert, ist das Leistungsproblem wahrscheinlich geringfügig. Das größere Problem ist, dass Sie dafür sorgen müssen. Wenn Sie den Code schreiben müssen, ist dies mehr Arbeit und führt die Möglichkeit von Fehlern ein. Wenn Ihr Datenbankmodul "On Update-Kaskade" unterstützt, ist dies ein geringfügiges Problem.

Vorteile der Verwendung der E-Mail-Adresse als Primärschlüssel:

  1. Möglicherweise können Sie einige Verknüpfungen vollständig entfernen. Wenn Sie aus dem "Master Record" lediglich die E-Mail-Adresse benötigen, müssen Sie mit einem abstrakten Integer-Schlüssel einen Join durchführen, um diese abzurufen. Wenn der Schlüssel die E-Mail-Adresse ist, haben Sie sie bereits und der Beitritt ist nicht erforderlich. Ob dies Ihnen hilft, hängt davon ab, wie oft diese Situation auftritt.

  2. Wenn Sie Ad-hoc-Abfragen durchführen, kann ein Mensch leicht erkennen, auf welchen Stammsatz verwiesen wird. Dies kann eine große Hilfe sein, wenn Sie versuchen, Datenprobleme aufzuspüren.

  3. Sie werden fast sicher einen Index für die E-Mail-Adresse benötigen. Wenn Sie also den Primärschlüssel verwenden, wird ein Index gelöscht, wodurch die Leistung der Einfügungen verbessert wird, da sie jetzt nur noch einen zu aktualisierenden Index haben.

Meiner bescheidenen Meinung nach ist es in keiner Weise ein Slam-Dunk. Ich ziehe es vor, natürliche Schlüssel zu verwenden, wenn ein praktischer verfügbar ist, weil sie einfacher zu handhaben sind und die Nachteile in den meisten Fällen keine große Rolle spielen.

61
Jay

Es ist ziemlich schlimm. Angenommen, einige E-Mail-Anbieter gehen aus dem Geschäft. Die Benutzer möchten dann ihre E-Mail-Adresse ändern. Wenn Sie E-Mail als Primärschlüssel verwendet haben, werden diese E-Mails von allen Fremdschlüsseln für Benutzer dupliziert.

... und ich habe noch nicht einmal angefangen, über Leistungsaspekte zu sprechen.

11
meriton

Ich weiß nicht, ob dies ein Problem in Ihrem Setup sein könnte, aber abhängig von Ihrem RDBMS sind die Werte einer Spalte möglicherweise case sensitive . PostgreSQL-Dokumente sagen: „Wenn Sie eine Spalte als UNIQUE oder PRIMARY KEY deklarieren, ist der implizit generierte Index von der Groß- und Kleinschreibung abhängig.“ Mit anderen Worten, wenn Sie die Benutzereingaben für eine Suche in einer Tabelle mit E-Mail als Primärschlüssel akzeptieren und der Benutzer "[email protected]" bereitstellt, werden Sie "[email protected]" nicht finden.

11
xlttj

Niemand scheint ein mögliches Problem erwähnt zu haben, dass E-Mail-Adressen als privat betrachtet werden könnten. Wenn die E-Mail-Adresse der Primärschlüssel ist, sieht die URL einer Profilseite höchstwahrscheinlich in etwa ..../Users/[email protected] aus. Was ist, wenn Sie die E-Mail-Adresse des Benutzers nicht preisgeben möchten? Sie müssten einen anderen Weg finden, den Benutzer zu identifizieren, möglicherweise durch einen eindeutigen Integer-Wert, um URLs wie ..../Users/1 zu erstellen. Am Ende haben Sie schließlich einen eindeutigen ganzzahligen Wert.

10
Simen Echholt

Auf der Ebene logisch ist die E-Mail der natürliche Schlüssel. Wenn Sie auf der Ebene physical eine relationale Datenbank verwenden, passt der natürliche Schlüssel nicht gut als Primärschlüssel. Der Grund sind hauptsächlich die von anderen genannten Leistungsprobleme.

Aus diesem Grund kann das Design angepasst werden. Der natürliche Schlüssel wird zu alternativer Schlüssel (UNIQUE, NOT NULL), und Sie verwenden einen Ersatz-/künstlichen/technischen Schlüssel als Primärschlüssel, der ein automatisches Inkrement in Ihrem sein kann Fall. 

systempuntoout hat gefragt,

Was ist, wenn jemand seine E-Mail-Adresse ändern möchte? Werden Sie auch alle Fremdschlüssel ändern?

Dafür ist kaskadieren .

Ein weiterer Grund, einen numerischen Ersatzschlüssel als Primärschlüssel zu verwenden, hängt mit der Funktionsweise der Indizierung auf Ihrer Plattform zusammen. In MySQL's InnoDB zum Beispiel haben alle Indizes in einer Tabelle den Primärschlüssel vorangestellt, sodass Sie möchten, dass der PK so klein wie möglich ist (aus Gründen der Geschwindigkeit und der Größe). InnoDB ist auch in diesem Zusammenhang schneller, wenn der Primärschlüssel in einer Sequenz gespeichert wird und eine Zeichenfolge dort nicht helfen würde.

Wenn Sie eine Zeichenfolge als alternativen Schlüssel verwenden, sollten Sie berücksichtigen, dass die Verwendung eines Hash der gewünschten Zeichenfolge möglicherweise schneller ist und Dinge wie Groß- und Kleinbuchstaben einiger Buchstaben überspringen. (Ich bin tatsächlich hier gelandet, als ich nach einem Hinweis gesucht habe, um zu bestätigen, was ich gerade gesagt habe.

8
Rafa

Ja, es ist ein fehlerhafter Primärschlüssel, da Ihre Benutzer ihre E-Mail-Adressen aktualisieren möchten.

4
Bryan Legend

ja, es ist besser, wenn Sie stattdessen eine ganze Zahl verwenden. Sie können Ihre E-Mail-Spalte auch als eindeutige Einschränkung festlegen.

so was:

CREATE TABLE myTable(
    id integer primary key,
    email text UNIQUE
);
4
ibram

Ein weiterer Grund, warum der Ganzzahl-Primärschlüssel besser ist, ist der Verweis auf die E-Mail-Adresse in verschiedenen Tabellen. Wenn Adresse selbst ein Primärschlüssel ist, müssen Sie ihn in einer anderen Tabelle als Schlüssel verwenden. So speichern Sie E-Mail-Adressen mehrfach.

3
klew

Postgres kenne ich nicht so gut. Primärschlüssel ist ein großes Thema. Ich habe auf dieser Website (stackoverflow.com) einige hervorragende Fragen und Antworten gesehen.

Ich denke, Sie haben möglicherweise eine bessere Leistung, wenn Sie einen numerischen Primärschlüssel haben und in der E-Mail-Spalte UNIQUE INDEX verwenden. E-Mails sind in der Regel unterschiedlich lang und für den Primärschlüsselindex möglicherweise nicht geeignet.

etwas lesen hier und hier.

3
Saif Khan

Ich weiß, dass dies ein wenig spät ist, aber ich möchte hinzufügen, dass Leute E-Mail-Konten aufgeben und Dienstanbieter die Adresse wiederherstellen, sodass eine andere Person sie verwenden kann.

Wie @HLGEM darauf hinweist, "[email protected] kann leicht zu John Smith ein Jahr und zu Julia Smith zwei Jahre später gehören." Sollte John Smith Ihren Service in diesem Fall wünschen, müssen Sie entweder die Verwendung seiner E-Mail-Adresse ablehnen oder alle Ihre Einträge löschen, die Julia Smith betreffen.

Wenn Sie Datensätze löschen müssen, die sich auf die Finanzgeschichte des Unternehmens beziehen, können Sie sich je nach den örtlichen Gesetzen in heißes Wasser begeben.

Daher würde ich niemals Daten wie E-Mail-Adressen, Nummernschilder usw. als Primärschlüssel verwenden, denn egal, wie einzigartig sie sich anscheinend außerhalb ihrer Kontrolle befinden, und kann einige interessante Herausforderungen mit sich bringen, für die Sie möglicherweise keine Zeit haben.

2
Robert

Verwenden Sie eine GUID als Primärschlüssel. Auf diese Weise können Sie sie aus Ihrem Programm generieren, wenn Sie eine INSERT-Anweisung ausführen und keine Antwort vom Server erhalten, um den Primärschlüssel zu ermitteln. Es wird auch eindeutig über Tabellen und Datenbanken hinweg sein, und Sie müssen sich keine Gedanken darüber machen, was passiert, wenn Sie die Tabelle eines Tages kürzen und das Auto-Inkrement auf 1 zurückgesetzt wird.

2
JoelFan

Persönlich verwende ich keine Informationen für den Primärschlüssel beim Entwerfen einer Datenbank, da es sehr wahrscheinlich ist, dass ich später Informationen ändern muss. Der einzige Grund, aus dem ich den Primärschlüssel bereitstelle, ist, dass es praktisch ist, die meisten SQL-Operationen vom Client aus durchzuführen, und ich habe mich immer für den Integer-Typ mit automatischer Inkrementierung entschieden.

2
tia

Ihr Kollege hat Recht: Verwenden Sie für Ihren Primärschlüssel eine automatisch verkürzende Ganzzahl.

Sie können die E-Mail-Eindeutigkeit entweder auf Anwendungsebene implementieren oder Sie können Ihre E-Mail-Adressenspalte als eindeutig kennzeichnen und einen Index für diese Spalte hinzufügen.

Das Hinzufügen des Felds als eindeutig kostet den Vergleich der Zeichenfolgen nur beim Einfügen in diese Tabelle und nicht bei Joins und Fremdschlüsseleinschränkungsprüfungen. 

Natürlich müssen Sie beachten, dass das Hinzufügen von Einschränkungen zu Ihrer Anwendung auf Datenbankebene dazu führen kann, dass Ihre App unflexibel wird. Berücksichtigen Sie immer die gebührende Überlegung, bevor Sie ein Feld als "eindeutig" oder "nicht null" definieren, nur weil Ihre Anwendung es eindeutig oder nicht leer sein muss.

2
jrharshath

primärschlüssel sollte ein statisches Attribut sein. Da E-Mail-Adressen nicht statisch sind und von mehreren Kandidaten gemeinsam genutzt werden können, ist es nicht ratsam, sie als Primärschlüssel zu verwenden. Darüber hinaus sind E-Mail-Adressen in der Regel Strings mit einer bestimmten Länge, die möglicherweise größer ist als die eindeutige ID, die wir verwenden möchten [len (email_address)> len (unique_id)]. Dies würde mehr Speicherplatz erfordern und am schlechtesten werden sie mehrfach als Fremdschlüssel gespeichert . Infolgedessen wird die Leistung beeinträchtigt.

1
user2719152

sie können die Leistung steigern, indem Sie den Ganzzahl-Primärschlüssel verwenden.

1
xport

Wenn Sie einen nicht int-Wert als Primärschlüssel haben, werden Einfügungen und Abfragen bei großen Daten sehr langsam. 

1
Amareswar

sie sollten einen Ganzzahl-Primärschlüssel verwenden. Wenn die E-Mail-Spalte eindeutig sein soll, setzen Sie einen eindeutigen Index für diese Spalte.

1
oezi

Das hängt von der Tabelle ab. Wenn die Zeilen in Ihrer Tabelle E-Mail-Adressen darstellen, ist E-Mail die beste ID. Wenn nicht, dann ist die E-Mail keine gute ID.

0
Lajos Arpad

E-Mail ist ein guter eindeutiger Indexkandidat, jedoch nicht für Primärschlüssel. Wenn es sich um einen Primärschlüssel handelt, können Sie die E-Mail-Adresse des Kontakts beispielsweise nicht ändern.

0
Chocolim

Wenn es nur darum geht, dass die E-Mail eindeutig ist, können Sie einfach einen eindeutigen Index mit dieser Spalte erstellen.

0
Micah

Möglicherweise müssen Sie alle anwendbaren gesetzlichen Bestimmungen zur Datenregulierung berücksichtigen. E-Mails sind persönliche Informationen. Wenn Ihre Nutzer beispielsweise EU-Bürger sind, können Sie sie unter der DSGVO anweisen, ihre Informationen aus Ihren Unterlagen zu löschen.

Wenn Sie den Datensatz selbst aus referenziellen Gründen oder aus historischen Gründen (z. B. zur Überwachung) in der Datenbank aufbewahren müssen, können Sie bei Verwendung eines Ersatzschlüssels alle Felder für persönliche Daten auf Null setzen. Dies ist offensichtlich nicht so einfach, wenn ihre persönlichen Daten der Primärschlüssel sind 

0
Stuart Parker

verwenden Sie keine E-Mail-Adresse als Primärschlüssel, behalten Sie die E-Mail-Adresse als eindeutig, verwenden Sie sie jedoch nicht als Primärschlüssel

0
Nikki