it-swarm.com.de

In welchem ​​Datentyp soll ich eine E-Mail-Adresse in der Datenbank speichern?

Ich verstehe, dass eine E-Mail-Adresse mit 254 Zeichen gültig ist, aber von mir untersuchte Implementierungen verwenden in der Regel einen varchar (60) bis varchar (80) oder einen gleichwertigen Wert. Zum Beispiel: diese SQL Server-Empfehlung verwendet varchar (80) oder dieses Oracle-Beispiel

Gibt es einen Grund, nicht das volle Maximum von 254 Zeichen zu verwenden? Verwendet ein Varchar per Definition nicht nur so viel Speicherplatz wie nötig, um die Daten zu speichern?

Gibt es signifikante Auswirkungen auf die Leistung/Kompromisse, die dazu führen, dass so viele Implementierungen weniger als die vollen 254 möglichen Zeichen verwenden?

47
Thronk

Ich habe immer VARCHAR(320) verwendet. Hier ist der Grund. Der Standard schreibt die folgenden Einschränkungen vor:

  • 64 Zeichen für den "lokalen Teil" (Benutzername).
  • 1 Zeichen für das Symbol @.
  • 255 Zeichen für den Domainnamen.

Nun, einige Leute werden sagen, dass Sie mehr als das unterstützen müssen. Einige Leute werden auch sagen, dass Sie Unicode für Domain-Namen unterstützen müssen (was bedeutet, dass Sie zu NVARCHAR wechseln müssen). Obwohl sich der Standard in der Zwischenzeit ändern kann (es ist schon eine Weile her, seit ich Skin im Spiel hatte), bin ich ziemlich zuversichtlich, dass die meisten Server der Welt derzeit keine Unicode-E-Mail-Adressen akzeptieren, und ich bin mir sicher Viele Server haben Probleme beim Erstellen und/oder Akzeptieren von Adressen mit> 320 Zeichen.

Sie können sich jetzt auf das Schlimmste vorbereiten, wenn Sie möchten (und wenn Sie die Datenkomprimierung in SQL Server 2008 R2 oder besser verwenden, profitieren Sie von der Unicode-Komprimierung, dh Sie zahlen nur die 2-Byte-Strafe für Zeichen, die tatsächlich benötigt werden es). Auf diese Weise können Sie Ihre Spalte so breit machen, wie Sie möchten, und Sie können zulassen, dass die Leute zu langen Müll hineinstecken, den sie wollen - sie erhalten keine E-Mail, wenn sie Ihnen Müll geben, so wie sie es nicht tun Sie erhalten eine E-Mail, wenn die Einfügung fehlschlägt. Das Problem ist, wenn Sie ungültigen Müll hereinlassen, Sie damit umgehen müssen. Und egal wie groß Sie es machen - wenn jemand versucht, 400 Zeichen in eine Spalte mit 320 Zeichen zu stecken, versucht jemand, 1025 Zeichen in eine Spalte mit 1024 Zeichen zu stecken. Es gibt keinen Grund, warum eine vernünftige Person eine E-Mail-Adresse> 320 Zeichen haben sollte, es sei denn, sie verwendet sie zum expliziten Testen von Systemgrenzen.

Aber hören Sie auf, nach Meinungen zu fragen - und hören Sie auf, andere Implementierungen als Anleitung zu betrachten (in diesem Fall ist es nur so, dass diejenigen, auf die Sie verwiesen haben, sich nicht die Mühe gemacht haben, ihre eigenen Hausaufgaben zu machen und nur Zahlen ausgewählt haben aus ihren, na ja, weißt du). Sie haben direkten Zugriff auf den Standard - Stellen Sie sicher, dass Sie die aktuellste Version konsultieren, diese mindestens unterstützen und auf dem neuesten Stand bleiben, damit Sie sich an Änderungen der Spezifikationen anpassen können.


[~ # ~] edit [~ # ~] danke an @ypercube für den Ping im Chat.

Abgesehen davon möchten Sie vielleicht gar nicht erst die gesamte Adresse in einer einzigen Spalte speichern. Die Normalisierung könnte darauf hindeuten, dass Sie @hotmail.com Nicht 15 Millionen Mal speichern möchten, wenn ein viel dünneres FK int einwandfrei funktioniert und nicht den zusätzlichen Overhead von Spalten variabler Länge hat. Sie können den Benutzernamen auch normalisieren, da [email protected] Und [email protected] Einen gemeinsamen Benutzernamen haben - sie kennen sich nicht, aber Ihre Datenbank kümmert sich nicht darum.

Ich habe hier darüber gesprochen:

http://www.mssqltips.com/sqlservertip/2657/storing-email-addresses-more-efficiently-in-sql-server/

http://www.mssqltips.com/sqlservertip/2671/storing-email-addresses-more-efficiently-in-sql-server--part-2/

Dies stellt jedoch die oben genannte Beschränkung auf 254 Zeichen vor Herausforderungen, da es keinen Konsens darüber zu geben scheint, was passiert, wenn eine gültige Domäne mit 255 Zeichen mit einem gültigen lokalen Teil aus 1 Zeichen kombiniert wird. Dies sollte von den meisten Servern auf der ganzen Welt akzeptiert werden, scheint jedoch diese Beschränkung auf 254 Zeichen zu verletzen. Erstellen Sie also eine Domains -Tabelle mit einer künstlich geringeren Längenbeschränkung für E-Mail-Adressen, wenn die Domain könnte Als gültige URL mit 255 Zeichen wiederverwendet werden kann ?

49
Aaron Bertrand

Bei dieser Entscheidung gibt es einige Überlegungen. In erster Linie müssen aktuelle und zukünftige Vorhersagen der notwendigen Einschränkungen verwendet werden, denen die Daten entsprechen müssen. Es gibt einen Grund, warum Sie nicht jeden Datenträgertyp für Zeichenfolgenspalten auf varchar(1024) setzen möchten, wenn Sie nur eine Zeichenfolge speichern, die sollte nicht 32 Zeichen überschreitet (Hervorhebung von das Schlüsselwort sollte.

Wenn Sie eine Sicherheitsanfälligkeit haben, bei der alle E-Mails auf 255 Zeichen geändert werden, kann dies möglicherweise zu einer langen Auswirkung der Seitenteilung auf die Leistung führen. Dies mag ungewöhnlich erscheinen und ist es höchstwahrscheinlich, aber Sie müssen Größe Ihrer Daten an die Geschäftsanforderungen anpassen. Ähnlich wie bei der uralten Einschränkung in der Datenbank- und Anwendungsdebatte bin ich fest davon überzeugt, dass Datentypbeschränkungen und zulässige Werte auch auf der Datenebene durchgesetzt werden sollten.

Was mich zu meinem nächsten Punkt führt. Die Datenbank ist höchstwahrscheinlich nur die Datenschicht. Was nutzt die Anwendungsebene? Wenn Sie beispielsweise eine Anwendung haben, in der Sie nur 80 Zeichen für eine E-Mail-Adresse eingeben können, warum sollte der Datentyp dann größer sein? Unternehmen müssen zwei Fragen beantworten:

  1. Was kann es sein?
  2. Was sollte es sein?

Nur dann haben Sie Ihre Antwort.

Verwendet ein Varchar per Definition nicht nur so viel Speicherplatz wie nötig, um die Daten zu speichern?

Ja und nein. Es wird eine Art Versatz für die Daten variabler Länge geben, um deren Länge aufzuzeichnen.

5
Thomas Stringer

In RFC 5321 (die aktuelle SMTP-Spezifikation veraltet RFC2821) heißt es:

Die maximale Gesamtlänge eines Benutzernamens oder eines anderen lokalen Teils beträgt 64 Oktette. Die maximale Gesamtlänge eines Domainnamens oder einer Domainnummer beträgt 255 Oktette

Das Zeichen 64 + 255 + @ impliziert also VARCHAR (320). Sie werden wahrscheinlich nie so viel brauchen, aber es ist sicher, es zu haben, nur für den Fall.

3
avakharia

Jede Variation von VARCHAR belegt nur so viel Speicherplatz im Datenblock wie nötig. Die zusätzlichen Bytes zum Speichern der Länge sind im Vergleich zu dem Speicherplatz, der stattdessen mit einem CHAR fester Länge verschwendet würde, trivial.

Da eine VARCHAR-Spaltenlänge tatsächlich eine "maximale Länge" ist, sollte sie unter allen Umständen größer als die maximal mögliche Länge eingestellt werden. Es wird nur so viel Platz verwendet, wie jede Zeile benötigt. Die Anwendungsprogramme sollten dann mit Bildlauffeldern oder was auch immer sinnvoll ist, basierend auf typischen Werten gestaltet werden.

Ein Datenbankdesign ist insofern wie ein physisches Stück Papier, als es die harten Grenzen der Größe festlegt. Eine Papierseite kann nicht vergrößert werden. In dieser Analogie ähnelt das Anwendungsprogramm einem auf der Seite gedruckten Formular. Es kann viel getan werden, um anzupassen, wie viele Daten wir im Formular halten können.

Obwohl der Befehl zum Erhöhen einer VARCHAR-Größe einfach aussieht und sofort in einer kleinen Tabelle ausgeführt wird, erfordert die Ausführung in einer Tabelle mit Tausenden von Zeilen oder mehr wahrscheinlich eine Art Datenbankruhe, während alle Daten- und Indexblöcke neu generiert werden. Eine Möglichkeit besteht darin, alles in eine neue Tabelle mit den größeren Spalten zu kopieren. Welche Technik auch immer verwendet wird, es ist eine große Sache. Daher sollten Sie die VARCHAR-Spaltengröße nach dem Laden einer Produktionstabelle als weitgehend unveränderlich betrachten.

1
DocSalvager

Als Kommentar zu den hervorragenden Antworten bereits hier:

Wenn Sie das Feld als varchar(240) erstellt haben und es später in ein längeres Feld ändern möchten, z. B. varchar(320), sollte diese Änderung - abhängig vom Datenbankserver - eine triviale Operation sein Natürlich auf Ihrem Datenbankprodukt.

alter table Schema.Object alter column EmailAddress varchar(320) ;

Zweitens ändert die Verwendung von varchar(320) anstelle von varchar(240) abhängig von der durchschnittlichen Zeilengröße und der Seitengröße möglicherweise nicht die Anzahl der zugewiesenen Seiten (den tatsächlich von der Tabelle belegten Speicherplatz).

Drittens sprach jemand oben über die Validierung einer E-Mail-Adresse. Ich behaupte, dass es nur einen sicheren Weg gibt, eine E-Mail-Adresse zu validieren, nämlich eine E-Mail an sie zu senden. :-)

1

Verwenden von SQL DOMAIN

Wenn Sie einen Enterprise-Datenbankserver verwenden, sollte es eine Möglichkeit geben, eine E-Mail-Adresse als DOMAIN mit einer gewissen Gültigkeitsstufe zu speichern. Domänen werden in der SQL-Spezifikation angegeben

Eine Domäne ist ein benanntes benutzerdefiniertes Objekt, das an bestimmten Stellen, an denen ein Datentyp angegeben werden kann, als Alternative zu einem Datentyp angegeben werden kann. Eine Domäne besteht aus einem Datentyp, möglicherweise einer Standardoption, und null oder mehr (Domänen-) Einschränkungen.

Das kostenlose und Open-Source-PostgreSQL unterstützt dies beispielsweise. Abgesehen von Einschränkungen bei der Implementierung der Spezifikation enthält die Spalte selbst eine gültige E-Mail. Sie können zum Beispiel ..

  • Erstellen Sie ein benutzerdefiniertes DOMAIN über der HTML5-E-Mail-Spezifikation.
  • Oder über die E-Mail-Spezifikation RFC822, RFC2822, RFC5322.
  • Erstellen Sie ein benutzerdefiniertes DOMAIN, das den Server zum Zeitpunkt der Überprüfung auf einen MX-Datensatz überprüft.

Ich bewerte diese Optionen in diese Antwort, die spezifisch für PostgreSQL ist

0
Evan Carroll

VARCHAR ist der beste Datentyp für E-Mail-Adressen, da E-Mails je nach Länge sehr unterschiedlich sind. NVARCHAR ist auch eine Alternative, aber ich würde empfehlen, es nur zu verwenden, wenn die E-Mail-Adresse erweiterte Zeichen enthält, und zu beachten, dass im Vergleich zu VARCHAR doppelt so viel Speicherplatz erforderlich ist.

In meiner Umgebung verwenden wir varchar (70), da die längsten, auf die ich gestoßen bin, knapp 60-70 char lang sind, aber dies hängt auch vom Kundenstamm Ihres Unternehmens ab. Stellen Sie außerdem als Randnotiz sicher, dass eine E-Mail-Validierungsprüfung für die Gültigkeit von E-Mail-Adressen vorhanden ist. Verwenden Sie beispielsweise Prüfbeschränkungen oder CHARINDEX

0
Kin Shah