it-swarm-eu.dev

Best Practices für gängige Personenfelder (Name, E-Mail, Adresse, Geschlecht usw.)

Was sind die gängigsten Best Practices für Länge und Datentyp in gängigen Feldern wie:

  • Vorname
  • Nachname
  • Adresse
  • Email
  • Sex
  • Zustand
  • Stadt
  • Land
  • Telefonnummer

usw....

44
Snow_Mac

Ich würde jeder Reihe von universellen Best Practices gegenüber sehr misstrauisch sein, da in den meisten dieser Bereiche der Teufel im Detail steckt. Nur weil die Informationen relativ häufig sind, bedeutet dies nicht, dass Ihre Anwendung die Daten genauso verwendet wie andere Anwendungen. Das bedeutet, dass Ihr Datenmodell möglicherweise etwas anders sein muss.

  • Vor- und Nachname: Warum erfassen Sie den Namen? Wenn Sie den vollständigen legalen Namen einer Person erfassen müssen (dh Sie bereiten juristische Dokumente oder Geburtsurkunden vor), möchten Sie wahrscheinlich mehr Platz für die Eingabe von Personen einräumen, als wenn Sie nur nach dem Namen einer Person fragen würden Haben Sie etwas, um sie in Ihrer neuen Web-App aufzurufen.
  • Adresse: Was machen Sie mit der Adresse? Welche Art von Adressen speichern Sie? Wenn Sie die Adresse einer Immobilie in den USA speichern, für die Sie eine Hypothek erstellen, ist es Ihnen wahrscheinlich sehr wichtig, eine vollständig standardisierte Adresse zu erhalten. In diesem Fall möchte das Datenmodell wahrscheinlich sehr genau auf Ihre Adresse eingehen Standardisierungstool kehrt zurück. Wenn Sie nur möchten, dass Benutzer eine Adresse eingeben können, um ein Produkt zu liefern, sind wahrscheinlich ein paar Zeilen für Freiformtext ausreichend. Die Länge der Zeilen dort kann von den Anforderungen der nachgeschalteten Prozesse abhängen, die beispielsweise Adressetiketten drucken.
  • Status: Angenommen, Sie können die gültigen Statuswerte identifizieren, ist es wahrscheinlich sinnvoll, eine Tabelle STATE zu erstellen und eine Fremdschlüsselbeziehung zwischen den Tabellen STATE und ADDRESS zu erstellen. Die Fähigkeit, die gültigen Werte zu identifizieren, bedeutet jedoch, dass Sie den Satz gültiger Adressen zumindest auf einen bestimmten Satz von Ländern beschränken. Das ist für viele Websites in Ordnung, aber dann muss man ein bisschen arbeiten, um ein neues Land zu unterstützen.
  • Stadt: Wenn Sie mit Daten arbeiten, für die möglicherweise Vorschriften auf Stadtebene gelten (dh für die je nach Stadt unterschiedliche Steuersätze gelten), möchten Sie diese möglicherweise ähnlich wie den Staat behandeln und haben eine CITY Tabelle mit den gültigen Städten und einer Fremdschlüsselbeziehung zwischen den Tabellen CITY und ADDRESS. Wenn Sie jedoch nur versuchen, ein Produkt zu liefern, und es Ihnen egal ist, ob Sie verschiedene Versionen derselben Stadt in Ihrer Tabelle haben, reicht es aus, den Benutzer in Freiform Text eingeben zu lassen. Wenn Sie Fremdschlüssel speichern, müssen Sie natürlich eine Menge Arbeit leisten, um sicherzustellen, dass Sie alle gültigen Werte haben. Es gibt jedoch Produkte, bei denen der springende Punkt ist, dass das Unternehmen diese Arbeit bereits ausgeführt hat (d. H. Umsatzsteuerdatenbanken).
  • Telefon: Was machst du mit Telefonnummern und warum? Einige Anwendungen möchten Telefonnummern in einem beliebigen Format eingeben, das der Benutzer eingeben möchte, und diese Formatierung für alle nachfolgenden Abfragen beibehalten. Dies ist häufig der Fall, wenn Sie ein persönliches Adressbuch entwerfen, in dem Benutzer ihre eigenen Einstellungen für die Speicherung und Anzeige von Telefonnummern haben. Andere Anwendungen möchten die eingegebene Formatierung ignorieren, nur die numerischen Zeichen extrahieren und die Daten beim Abrufen so formatieren, dass alle Telefonnummern eine ähnliche Formatierung haben. Wenn Sie Unternehmen bedienen, möchten Sie möglicherweise ein separates Feld, in das Benutzer eine Nebenstelle eingeben können. Wenn Sie versuchen, einen ausgehenden Anrufprozess zu unterstützen, möchten Sie möglicherweise die Vorwahl und die Landesvorwahl in separaten Spalten speichern, da Sie sicherstellen möchten, dass Sie zeitzonenspezifische Fenster zum Anrufen von Personen in verschiedenen Vorwahlen haben (a Ein Anruf bei jemandem in der östlichen Zeitzone um 10 Uhr wird viel besser als ein Anruf bei jemandem in der pazifischen Zeitzone, wo es 7 Uhr morgens ist.
  • Geschlecht: Für sehr viele Anwendungen ist es durchaus sinnvoll, einen Geschlechtscode ('M' oder 'F') in einer Tabelle zu speichern. Auf der anderen Seite gibt es Fälle, in denen Sie möglicherweise zusätzliche Optionen wünschen (Andere, Intersex, Transgender) oder in denen Sie beispielsweise das Geschlecht bei der Geburt und das aktuelle Geschlecht speichern müssen.
50
Justin Cave

Sie können auch anhand von Beispieldaten und der erwarteten Zielgruppe erraten. Das hängt von Ihrem Standort ab.

Einige Notizen:

Adressen:

Namen:

Telefonnummer: Internationaler Code, Länge, Handy gegen Haus, Handy als einzige Nummer zulassen

24
gbn

Vergessen Sie nicht, zusätzlich zu den oben genannten tollen Antworten Unicode-Zeichen zu akzeptieren. Nur weil Sie in den USA sind, heißt das nicht, dass Sie keine fremden Zeichen in Ihre Spalten aufnehmen möchten.

Trotzdem empfehle ich normalerweise 50 Zeichen für Namen. 320 sollte mehr als genug für eine E-Mail-Adresse sein (Sie können den ANSI-Standard überprüfen, um sicherzugehen). Für Adressfehler auf der Seite der Vorsicht mit 255 Zeichen. Während Sie wahrscheinlich nie eine so große Adresse benötigen, können Sie dies tun, wenn Sie C/O-Leitungen und ähnliches einfügen. Die Stadt sollte ziemlich groß sein, es gibt einige ziemlich lange Städtenamen da draußen. Für Staat gehen Sie mit einem Kindertisch, das gleiche mit Land. Vergessen Sie bei der Postleitzahl nicht die internationalen Postleitzahlen, die länger als die US-Postleitzahlen sind. Nur weil Sie international nicht unterstützen, könnten Sie es immer noch sein. Es gibt viele US-Bürger, die in verschiedenen Landkreisen leben, einschließlich Militärs.

Vergessen Sie nicht, dass der Staat optional sein sollte, da viele Länder keine Staaten haben.

10
mrdenny

Mein Hintern tut weh, wenn ich auf dem Zaun sitze, also werde ich nur ein paar Antworten rauswerfen und hoffe, nicht in Vergessenheit geraten zu können. Bitte konstruktive Kritik üben.

E-Mail-Addresse:

min: 6 ([email protected]). Oder 3, wenn Sie lokale Domain-E-Mail-Adressen verfolgen möchten
Max: 320 254 (RFC)

Die Menge an Code zum Überprüfen einer E-Mail ist tatsächlich verrückt. Nehmen wir also an, dass sie gültig ist, wenn sie ein "@" hat.

Möglicherweise möchten Sie eine E-Mail-Adresse als "Kommunikationsmethode" abstrahieren, damit Sie auf einfache Weise alle Methoden auflisten können, mit denen Sie mit einem Benutzer kommunizieren können.

Geschlecht

Das Geschlecht kann sich im Laufe der Zeit ändern, sodass Sie dies nachverfolgen können, wenn es Ihnen wichtig ist. Folgen Sie http://en.wikipedia.org/wiki/ISO/IEC_5218

NOT_KNOWN(0),
MALE(1),
FEMALE(2),
NOT_APPLICABLE(9);

Adressen: NORAM

Ich werde den billigen Ausweg nehmen und mich an nordamerikanische Adressen halten.

Es ist praktisch, Länder, Abteilungen, Städte und Landkreise zu abstrahieren, hauptsächlich aufgrund von Steuern. Steuern können auf vielen Ebenen erhoben werden. Wenn Sie also einen Steuersatz auf ein abstraktes geografisches Gebiet verweisen können, sind Sie goldrichtig.

GeographicArea :

id: int  
type: {country, division, county, city, indian reservation}  
name: varchar(45)  [1]
abbreviation: nullable varchar(4)  
parent_id: nullable int  

Adresse :

id: int  
postal_area_id: int, references GeographicArea  
county_or_city_id: int, references GeographicArea  
street_address: varchar(255)  
suite: nullable varchar(255)  

Fügen Sie bei Bedarf Zeile2 und Zeile3 hinzu.

Siehe http://en.wikipedia.org/wiki/Address_ (Geografie)

Nun ist eine Adresse eine Adresse. Mehrere Personen können an einer Adresse wohnen, und eine Person kann mehrere Adressen gleichzeitig und im Laufe der Zeit haben. Daher benötigen Sie dafür eine Tabelle mit vielen, vielen.

PartyAddress

party_id: int references Party  
address_id: int references Address  
purpose: {home, work, ...}  

Füge hinzu ein from_date und nullable to_date wenn im Laufe der Zeit verfolgt.

Telefonnummern

Eine Partei kann mehrere Telefonnummern haben, und eine Telefonnummer kann von mehreren Personen verwendet werden. Eine Telefonnummer kann für Faxe, Telefonanrufe, Modems usw. verwendet werden und Nebenstellen haben. Diese können sich auch im Laufe der Zeit ändern.

Telefonnummer

id: int  
value: varchar(15) - the max allowed by the ITU  

Die Mindestanzahl kann 3 (für "911") oder 7 ("310-4NET" sein, eine spezielle Art von lokaler Nummer, bei der Sie die Vorwahl nicht wählen können).

Sie können dies bei Bedarf in Ländercode usw. aufteilen.

Sie sollten den Standard http://en.wikipedia.org/wiki/E.164 verwenden

PartyPhoneNumber

party_id: int references Party  
phone_number_id references PhoneNumber  
extension: nullable varchar(11) - ITU max  
purpose: {home, work, fax, modem, ...}  

Namen

Namen sind hart. Hier ist der Grund:

  1. Einige Leute haben einen legalen Namen mit nur einem Wort http://en.wikipedia.org/wiki/List_of_legally_mononymous_people

  2. Einige Leute haben Namen mit vielen Wörtern http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior

  3. Einige Leute haben mehrere Namen gleichzeitig (an meiner Universität gibt es zum Beispiel viele asiatische Studenten, aber sie verwenden gerne "bevorzugte" westlichere Namen)

  4. Manchmal müssen Sie die Namen von Personen im Laufe der Zeit nachverfolgen, z. B. Mädchennamen und verheiratete Namen.

  5. Sie möchten Einzelpersonen und Organisationen aus verschiedenen guten Gründen abstrahieren

    tabellenparty erstellen (ID bigserial Primärschlüssel);

    tabelle erstellen party_name (id bigserial Primärschlüssel, party_id bigint nicht null referenziert party (id), Typ smallint nicht null referenziert party_name_type (id) --elided, ex "maiden", "legal");

    create table name_component (id bigserial Primärschlüssel, party_name_id bigint nicht null referenzen party_name (id), Typ smallint nicht null referenziert name_component_type (id), --elided ex "gegebener" Name Text nicht null);

9
Neil McGuigan

Aus einer etwas anderen Perspektive als die vorherigen Antworten und seit es scheint in Ordnung zu sein, über LDAP zu sprechen , RFC 4519 - "Lightweight Directory Access Protocol (LDAP): Schema für Benutzeranwendungen" kann von Interesse sein.

Dies kann hilfreich sein, wenn Ihre Anwendung einem solchen Verzeichnis zugeordnet werden muss. Andernfalls ist es wahrscheinlich nicht an Ihre Anforderungen angepasst.

Bei diesen Definitionen geht es nicht nur um Daten, sondern auch um einige Operatoren, die für die Felder verwendet werden können. postalAddress , zum Beispiel ist ein caseIgnoreListSubstringsMatch . Ich schlage nicht vor, dass Sie sich strikt an dieses Schema halten, aber es könnte interessant sein, die Prinzipien zu betrachten, insbesondere, wie Sie möglicherweise Namen und Adressen in Ihrer Anwendung vergleichen müssen, kann für das Design Ihrer Datenbank relevant sein.

3
Bruno

Bei Namen sollten Sie doppelte Anführungszeichen verwenden, damit Sie Apostrophen in irischen oder italienischen Namen (z. B. O'Hara oder D'Amato) nicht entkommen müssen.

Ich würde auch empfehlen, einen guten Satz regulärer Ausdrücke zu verwenden, damit Sie Teile Ihrer Namensfelder ausgeben können (z. B. erste Initiale, Spitzname, Jr/Sr usw.).

3
KiloVoltaire