it-swarm.it

Best practice nei campi delle persone comuni (nome, email, indirizzo, genere ecc ...)

Quali sono le migliori pratiche più comuni su lunghezza e tipo di dati su campi comuni come:

  • Nome di battesimo
  • Cognome
  • Indirizzo
  • E-mail
  • Sesso
  • Stato
  • Città
  • Nazione
  • Numero di telefono

eccetera....

44
Snow_Mac

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.

  • Nome e cognome: perché acquisisci il nome? Se hai l'obbligo di acquisire il nome legale completo di una persona (ovvero stai preparando documenti legali o certificati di nascita), probabilmente vorrai consentire più spazio alle persone da digitare rispetto a quanto faresti se stai solo chiedendo il nome di una persona in modo da avere qualcosa da chiamare nella tua nuova app web.
  • Indirizzo: che cosa hai intenzione di fare con l'indirizzo? Che tipo di indirizzi stai memorizzando? Se stai memorizzando l'indirizzo di una proprietà negli Stati Uniti su cui stai creando un mutuo, probabilmente ti preoccupi molto di ottenere un indirizzo completamente standardizzato nel qual caso il modello di dati probabilmente vorrà andare molto vicino a qualunque sia il tuo indirizzo ritorni strumento di standardizzazione. Se vuoi solo che le persone siano in grado di digitare un indirizzo per consegnare un prodotto, probabilmente sono sufficienti un paio di righe per il testo a mano libera. La lunghezza delle linee può dipendere dai requisiti dei processi a valle che fanno cose come stampare le etichette degli indirizzi.
  • Stato: supponendo che sia possibile identificare i valori di stato validi, probabilmente ha senso creare una tabella STATE e creare una relazione di chiave esterna tra le tabelle STATE e 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.
  • Città: se hai a che fare con dati in cui sono potenzialmente in vigore normative a livello di città (ovvero dove ci sono diversi tipi di aliquote fiscali applicate in base alla città), potresti volerli trattare in modo simile allo stato e avere un CITY tabella con le città valide e una relazione di chiave esterna tra le tabelle CITY e 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 forma libera 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à svolto quel lavoro (ad es. Database delle imposte sulle vendite).
  • Telefono: cosa stai facendo con i numeri di telefono e perché? Alcune applicazioni vorranno inserire i numeri di telefono in qualunque formato l'utente decida di inserirli e conservare tale formattazione per tutte le successive query. Ciò sarebbe comune se si sta progettando una rubrica personale in cui gli utenti hanno le proprie preferenze su come i numeri di telefono vengono memorizzati e visualizzati. Altre applicazioni vorrebbero ignorare la formattazione inserita, estrarre solo i caratteri numerici e quindi formattare i dati al momento del recupero in modo che tutti i numeri di telefono abbiano una formattazione simile. Se fai catering per le aziende, potresti voler inserire un campo separato per gli utenti per inserire un'estensione. Se stai provando a supportare un processo di chiamata in uscita, potresti voler memorizzare il prefisso e il prefisso nazionale in colonne separate perché vorrai assicurarti di avere finestre specifiche del fuso orario per chiamare le persone in diversi prefissi (facendo un la chiamata a qualcuno nel fuso orario orientale alle 10 andrà molto meglio che fare la stessa chiamata a qualcuno nel fuso orario del Pacifico dove sono le 7).
  • Genere: per molte applicazioni, è perfettamente ragionevole memorizzare un codice di genere ('M' o 'F') in una tabella. D'altra parte, ci sono casi in cui potresti desiderare opzioni aggiuntive (Altro, Intersex, Transgender) o in cui è necessario memorizzare qualcosa come il genere alla nascita e il genere attuale.
50
Justin Cave

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

24
gbn

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 tra cui militari.

Non dimenticare che lo stato dovrebbe essere facoltativo poiché molti paesi non hanno stati.

10
mrdenny

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.

Indirizzo email:

min: 6 ([email protected]). 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.

Genere

Il genere può cambiare nel tempo, quindi puoi seguirlo se è importante per te. Segui http://en.wikipedia.org/wiki/ISO/IEC_5218

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

Indirizzi: NORAM

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_ (geografia)

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, ...}  

Aggiungere un from_date e nullable to_date se traccia nel tempo.

Numeri di telefono

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.

PhoneNumber

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, ...}  

Nomi

I nomi sono difficili. Ecco perché:

  1. Alcune persone hanno un nome legale con solo una parola in esso http://en.wikipedia.org/wiki/List_of_legally_mononymous_people

  2. Alcune persone hanno nomi con molte parole http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior

  3. 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)

  4. A volte, è necessario tenere traccia dei nomi delle persone nel tempo, come nomi da nubile e nomi sposati.

  5. 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);

9
Neil McGuigan

Da una prospettiva leggermente diversa rispetto alle risposte precedenti, e poiché sembra OK parlare di LDAP , RFC 4519 - "LDAP (Lightweight Directory Access Protocol): schema per applicazioni utente" potrebbe essere di interesse.

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 è un 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.

3
Bruno

Per quanto riguarda i nomi, prendi in considerazione l'uso delle virgolette doppie in modo da non dover sfuggire agli apostrofi con nomi irlandesi o italiani (ad esempio O'Hara o D'Amato).

Consiglierei anche di utilizzare un buon set di espressioni regolari, in modo da poter produrre parti dei campi del tuo nome (ad es. Prima iniziale, nickname, Jr/Sr, ecc.).

3
KiloVoltaire