Was sind die gängigsten Best Practices für Länge und Datentyp in gemeinsamen Feldern wie:
usw....
Antworten:
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 sie verwenden. Das bedeutet, dass Ihr Datenmodell möglicherweise etwas anders sein muss.
STATETabelle und eine Fremdschlüsselbeziehung zwischen dem Erstellen STATEund ADDRESSTabellen. Die Möglichkeit, die gültigen Werte zu identifizieren, impliziert 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.CITYTabelle mit den gültigen Städten und einer Fremdschlüsselbeziehung zwischen den Tabellen CITYund ADDRESS. Wenn Sie jedoch nur versuchen, ein Produkt auszuliefern, und es Ihnen egal ist, ob Sie verschiedene Versionen derselben Stadt in Ihrer Tabelle haben, reicht es aus, den Benutzer in freier Form Text eingeben zu lassen. Wenn Sie Fremdschlüssel speichern, müssen Sie natürlich eine Menge Arbeit aufbringen, um sicherzustellen, dass Sie alle gültigen Werte haben. Aber es gibt Produkte, bei denen der springende Punkt ist, dass das Unternehmen diese Arbeit bereits erledigt hat (dh Umsatzsteuerdatenbanken).Sie können auch anhand der Beispieldaten und der erwarteten Zielgruppe raten . Das hängt von Ihrem Standort ab.
Einige Notizen:
Adressen:
Namen:
Telefonnummer: Internationale Vorwahl, Länge, Handy gegen Haus, Handy als einzige Nummer zulassen
Vergessen Sie nicht, zusätzlich zu den großartigen Antworten oben auch Unicode-Zeichen zu akzeptieren. Nur weil Sie in den USA sind, heißt das noch lange 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). Bei Adressfehlern Vorsicht mit 255 Zeichen. Während Sie wahrscheinlich nie eine so große Adresse benötigen werden, können Sie dies tun, wenn Sie C / O-Zeilen und ähnliches einfügen. Die Stadt sollte ziemlich groß sein, da draußen gibt es einige ziemlich lange Städtenamen. Für Staat gehen Sie mit einem Kindertisch, das selbe mit Land. Vergessen Sie für die Postleitzahl nicht die internationalen Postleitzahlen, die länger sind als die US-Postleitzahlen. Nur weil du keine internationale Unterstützung hast, bist du vielleicht immer noch dabei. Es gibt viele US-Bürger, die in verschiedenen Ländern leben, darunter auch Militärangehörige.
Vergessen Sie nicht, dass der Status optional sein sollte, da viele Länder keinen Status haben.
Mein Hintern tut mir weh, weil ich auf dem Zaun sitze, also werfe ich ein paar Antworten raus und hoffe, dass ich nicht in Vergessenheit gerate. Bitte geben Sie konstruktive Kritik.
min: 6 (a@g.cn). 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 der Code gültig ist, wenn er ein "@" enthält.
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.
Das Geschlecht kann sich im Laufe der Zeit ändern, sodass Sie es 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);
Ich werde den billigen Ausweg nehmen und mich an nordamerikanische Adressen halten.
Es ist praktisch, Länder, Divisionen, Städte und Landkreise zu abstrahieren, die hauptsächlich steuerpflichtig sind. Steuern können auf vielen Ebenen anfallen. 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_(geography)
Nun ist eine Adresse eine Adresse. Mehrere Personen können an einer Adresse wohnen, und eine Person kann gleichzeitig und im Laufe der Zeit mehrere Adressen haben. Daher benötigen Sie eine Many-Many-Tabelle.
PartyAdresse
party_id: int references Party
address_id: int references Address
purpose: {home, work, ...}
Fügen Sie a from_dateund nullable hinzu, to_datewenn die Verfolgung über einen längeren Zeitraum erfolgt.
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 kann 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", eine spezielle lokale Nummer, bei der Sie die Vorwahl nicht wählen können) sein.
Sie können dies gegebenenfalls in Ländercodes usw. aufteilen.
Sie sollten den http://en.wikipedia.org/wiki/E.164 Standard verwenden
PartyPhoneNumber
party_id: int references Party
phone_number_id references PhoneNumber
extension: nullable varchar(11) - ITU max
purpose: {home, work, fax, modem, ...}
Namen sind hart. Hier ist der Grund:
Einige Leute haben einen legalen Namen mit nur einem Wort darin http://en.wikipedia.org/wiki/List_of_legally_mononymous_people
Einige Leute haben Namen mit vielen Wörtern http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior
Einige Leute haben mehrere Namen gleichzeitig (zum Beispiel an meiner Universität gibt es viele asiatische Studenten, aber sie mögen "bevorzugte" westlichere Namen)
Manchmal müssen Sie die Namen von Personen im Laufe der Zeit nachverfolgen, z. B. Mädchennamen und Ehenamen.
Sie möchten Einzelpersonen und Organisationen aus einer Vielzahl von guten Gründen abstrahieren
create table party (ID des großen Primärschlüssels);
create table party_name (ID des Hauptschlüssels, party_id bigint nicht null referenziert party (id), type smallint nicht null referenziert party_name_type (id) --elided, ex "maiden", "legal");
create table name_component (id Hauptschlüssel, party_name_id bigint nicht null referenziert party_name (id), type smallint nicht null referenziert name_component_type (id), --elided ex "given" name text nicht null);
Aus einer etwas anderen Perspektive als in den vorherigen Antworten und da es in Ordnung zu sein scheint, über LDAP zu sprechen , kann RFC 4519 - "LDAP (Lightweight Directory Access Protocol): Schema für Benutzeranwendungen" von Interesse sein.
Dies kann hilfreich sein, wenn Ihre Anwendung einem solchen Verzeichnis zugeordnet werden muss. Ansonsten ist es wahrscheinlich nicht an Ihre Anforderungen angepasst.
Bei diesen Definitionen handelt es sich nicht nur um Daten, sondern auch um einige Operatoren, die für die Felder verwendet werden können. postalAddressZum Beispiel ist ein caseIgnoreListSubstringsMatch. Ich schlage nicht vor, dass Sie sich strikt an dieses Schema halten sollten, aber es könnte interessant sein, die Prinzipien zu betrachten, insbesondere, wie Sie Namen und Adressen in Ihrer Anwendung vergleichen müssen, kann für das Design Ihrer Datenbank relevant sein.
Verwenden Sie in Bezug auf Namen doppelte Anführungszeichen, um Apostrophe in irischen oder italienischen Namen (z. B. O'Hara oder D'Amato) zu vermeiden.
Ich würde auch empfehlen, einen guten Satz von regulären Ausdrücken zu verwenden, damit Sie Teile Ihrer Namensfelder ausgeben können (z. B. Vorname, Spitzname, Jr / Sr usw.).