Quali sono le migliori pratiche più comuni su lunghezza e tipo di dati su campi comuni come:
eccetera....
Risposte:
Tenderei ad essere molto sospettoso di qualsiasi insieme di migliori pratiche universali perché, per la maggior parte di questi campi, il diavolo è nei dettagli. Solo perché le informazioni sono relativamente comuni non significa che l'applicazione utilizzi i dati esattamente nello stesso modo in cui le usano altre applicazioni. Ciò significa che il tuo modello di dati potrebbe dover essere leggermente diverso.
STATEtabella e creare una relazione di chiave esterna tra le tabelle STATEe ADDRESS. Ma la capacità di identificare i valori validi implica che stai limitando il set di indirizzi validi almeno a un determinato set di paesi. Va bene per molti siti, ma poi devi fare un po 'di lavoro per supportare un nuovo paese.CITYtabella con le città valide e una relazione di chiave esterna tra le tabelle CITYe ADDRESS. D'altra parte, se stai solo cercando di ottenere un prodotto consegnato e non ti interessa molto se hai diverse versioni della stessa città nella tua tabella, lasciare che l'utente in formato libero inserisca il testo è sufficiente. Naturalmente, se stai memorizzando chiavi esterne, avrai una buona dose di lavoro per assicurarti di avere tutti i valori validi. Ma ci sono prodotti in cui il punto è che la società ha già fatto quel lavoro (ad es. Database delle imposte sulle vendite).Puoi anche indovinare in base ai dati di esempio e al pubblico previsto. Dipende dalla tua posizione.
Alcune note:
indirizzi:
nomi:
Numero di telefono: prefisso internazionale, lunghezza, cellulare vs casa, consente il cellulare come unico numero
Oltre alle ottime risposte sopra, non dimenticare di accettare caratteri unicode. Solo perché sei negli Stati Uniti non significa che non vuoi accettare caratteri stranieri nelle tue colonne.
Detto questo, di solito raccomando 50 caratteri per i nomi. 320 dovrebbe essere più che sufficiente per un indirizzo e-mail (puoi essere sicuro dello standard ANSI). Per errore di indirizzo sul lato della cautela con 255 caratteri. Anche se probabilmente non avrai mai bisogno di un indirizzo così grande, potresti includere linee C / O e cose del genere. La città dovrebbe essere piuttosto grande, ci sono alcuni nomi di città piuttosto lunghi là fuori. Per lo stato vai con una tabella figlio, lo stesso con il paese. Per il codice postale non dimenticare i codici postali internazionali che sono più lunghi dei codici postali statunitensi. Solo perché non supporti internazionale potresti essere. Ci sono molti cittadini statunitensi che vivono in diverse contee, compresi i militari.
Non dimenticare che lo stato dovrebbe essere facoltativo poiché molti paesi non hanno stati.
Il mio sedere sta diventando dolorante da seduto sul recinto, quindi ho intenzione di buttare via alcune risposte e spero di non essere votato all'oblio. Si prega di offrire critiche costruttive.
min: 6 (a@g.cn). Oppure 3 se si desidera tenere traccia degli indirizzi e-mail del dominio locale
max: 320 254 (RFC)
La quantità di codice per convalidare un'e-mail è in realtà folle, quindi supponiamo che sia valida se ha un "@"
Potresti voler astrarre un indirizzo email come "metodo di comunicazione", in modo da poter elencare facilmente tutti i metodi con cui comunicare con un utente.
Il genere può cambiare nel tempo, quindi puoi rintracciarlo se è importante per te. Segui http://en.wikipedia.org/wiki/ISO/IEC_5218
NOT_KNOWN(0),
MALE(1),
FEMALE(2),
NOT_APPLICABLE(9);
Prenderò la via più economica e mi atterrò agli indirizzi nordamericani.
È conveniente astrarre paesi, divisioni, città e contee principalmente a causa della tassazione. Le tasse possono essere applicate a molti livelli, quindi se puoi indicare un'aliquota fiscale in un'area geografica astratta, sei d'oro.
GeographicArea :
id: int
type: {country, division, county, city, indian reservation}
name: varchar(45) [1]
abbreviation: nullable varchar(4)
parent_id: nullable int
Indirizzo :
id: int
postal_area_id: int, references GeographicArea
county_or_city_id: int, references GeographicArea
street_address: varchar(255)
suite: nullable varchar(255)
Aggiungi line2 e line3 se necessario.
Vedi http://en.wikipedia.org/wiki/Address_(geography)
Ora, un indirizzo è un indirizzo. Più persone possono vivere a un indirizzo e una persona può avere più indirizzi contemporaneamente e nel tempo, quindi è necessario disporre di una tabella molte per questo.
PartyAddress
party_id: int references Party
address_id: int references Address
purpose: {home, work, ...}
Aggiungi a from_datee nullable to_datese traccia nel tempo.
Una parte può avere più numeri di telefono e un numero di telefono può essere utilizzato da più persone. Un numero di telefono può essere utilizzato per fax, chiamate telefoniche, modem, ecc. E può avere interni. Anche questi possono cambiare nel tempo.
Numero di telefono
id: int
value: varchar(15) - the max allowed by the ITU
Il min potrebbe essere 3 (per "911") o forse 7 ("310-4NET", che è un tipo speciale di numero locale che non consente di comporre il prefisso)
Puoi dividerlo in prefisso internazionale, ecc. Se necessario.
Dovresti usare lo standard http://en.wikipedia.org/wiki/E.164
PartyPhoneNumber
party_id: int references Party
phone_number_id references PhoneNumber
extension: nullable varchar(11) - ITU max
purpose: {home, work, fax, modem, ...}
I nomi sono difficili. Ecco perché:
Alcune persone hanno un nome legale con una sola parola al suo interno http://it.wikipedia.org/wiki/List_of_legally_mononymous_people
Alcune persone hanno nomi con molte parole http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior
Alcune persone hanno più nomi contemporaneamente (ad esempio, nella mia università ci sono molti studenti asiatici, ma a loro piace usare nomi "preferiti" più occidentalizzati)
A volte, è necessario tenere traccia dei nomi delle persone nel tempo, come nomi da nubile e nomi sposati.
Vuoi astrarre individui e organizzazioni per una serie di buoni motivi
creare table party (id chiave primaria bigserial);
crea una tabella party_name (id chiave primaria bigserial, party_id bigint non riferimenti null party (id), digita smallint non riferimenti null party_name_type (id) --elided, ex "maiden", "legal");
crea la tabella name_component (id chiave primaria bigserial, nome_ party_id bigint non riferimenti null nome_ party (id), digita smallint non riferimenti null nome_component_type (id), --elided ex "nome" testo non nullo);
Da una prospettiva leggermente diversa rispetto alle risposte precedenti e poiché sembra corretto parlare di LDAP , RFC 4519 - "Lightweight Directory Access Protocol (LDAP): Schema for User Applications" potrebbe essere interessante.
Può essere utile se l'applicazione deve essere mappata su tale directory. Altrimenti, probabilmente non è adattato alle tue esigenze.
Queste definizioni non riguardano solo i dati, ma anche alcuni operatori che possono essere utilizzati nei campi. postalAddress, ad esempio è a caseIgnoreListSubstringsMatch. Non sto suggerendo che dovresti aderire rigorosamente a questo schema, ma osservare i principi potrebbe essere interessante, in particolare il modo in cui potresti dover confrontare il nome e gli indirizzi nella tua applicazione potrebbe essere rilevante per la progettazione del tuo database.
Per quanto riguarda i nomi, prendi in considerazione l'uso delle virgolette in modo da non dover sfuggire agli apostrofi con nomi irlandesi o italiani (ad esempio O'Hara o D'Amato).
Ti consiglierei anche di usare un buon set di espressioni regolari, in modo da poter produrre parti dei campi del tuo nome (es. Prima iniziale, soprannome, Jr / Sr, ecc.).