web-dev-qa-db-fra.com

Meilleures pratiques sur les champs de personnes communs (nom, email, adresse, sexe etc ...)

Quelles sont les meilleures pratiques les plus courantes sur la longueur et le type de données dans des domaines communs tels que:

  • Prénom
  • Nom de famille
  • Adresse
  • Email
  • Sexe
  • Etat
  • Ville
  • Pays
  • Numéro de téléphone

etc....

database-designbest-practices
44
Snow_Mac

J'aurais tendance à me méfier de tout ensemble de meilleures pratiques universelles car, pour la plupart de ces domaines, le diable est dans les détails. Ce n'est pas parce que les informations sont relativement courantes que votre application utilise les données exactement de la même manière que les autres applications. Cela signifie que votre modèle de données peut devoir être légèrement différent.

  • Prénom et nom: Pourquoi capturez-vous le nom? Si vous avez besoin de saisir le nom légal complet d'une personne (c.-à-d. Que vous préparez des documents juridiques ou des certificats de naissance), vous voudrez probablement laisser plus d'espace pour les personnes à taper que si vous demandiez simplement le nom d'une personne afin que vous avoir quelque chose à les appeler dans votre nouvelle application Web.
  • Adresse: qu'allez-vous faire de l'adresse? Quelle sorte d'adresses stockez-vous? Si vous stockez l'adresse d'une propriété aux États-Unis sur laquelle vous créez une hypothèque, vous vous souciez probablement beaucoup d'obtenir une adresse entièrement standardisée, auquel cas le modèle de données voudra probablement être très proche de votre adresse. retourne l'outil de normalisation. Si vous voulez simplement que les gens puissent taper une adresse pour livrer un produit, quelques lignes de texte libre sont probablement suffisantes. La longueur des lignes peut dépendre des exigences des processus en aval qui font des choses comme imprimer des étiquettes d'adresse.
  • État: en supposant que vous puissiez identifier les valeurs d'état valides, il est probablement judicieux de créer une table STATE et de créer une relation de clé étrangère entre les tables STATE et ADDRESS. Mais la capacité d'identifier les valeurs valides implique que vous limitez l'ensemble d'adresses valides au moins à un ensemble particulier de pays. C'est bien pour de nombreux sites, mais vous devez faire un peu de travail pour soutenir un nouveau pays.
  • Ville: si vous traitez des données où il existe potentiellement des réglementations au niveau de la ville (c'est-à-dire où il existe différents types de taux d'imposition qui sont appliqués en fonction de la ville), vous voudrez peut-être les traiter un peu comme l'État et avoir un CITY table avec les villes valides et une relation de clé étrangère entre les tables CITY et ADDRESS. D'un autre côté, si vous essayez simplement de faire livrer un produit et que vous ne vous souciez pas si vous disposez de différentes versions de la même ville dans votre tableau, laisser l'utilisateur sous forme libre entrer du texte est suffisant. Bien sûr, si vous stockez des clés étrangères, vous aurez beaucoup de travail pour vous assurer que vous avez toutes les valeurs valides. Mais il y a des produits où le fait est que l'entreprise a déjà fait ce travail (c'est-à-dire les bases de données de taxe de vente).
  • Téléphone: Que faites-vous avec les numéros de téléphone et pourquoi? Certaines applications voudront prendre les numéros de téléphone dans le format que l'utilisateur décide de saisir et conserver cette mise en forme pour toutes les requêtes ultérieures. Cela serait courant si vous concevez un carnet d'adresses personnel dans lequel les utilisateurs ont leurs propres préférences pour la façon dont les numéros de téléphone sont stockés et affichés. D'autres applications souhaiteraient ignorer la mise en forme entrée, extraire uniquement les caractères numériques, puis formater les données lors de la récupération afin que tous les numéros de téléphone aient une mise en forme similaire. Si vous approvisionnez des entreprises, vous souhaiterez peut-être un champ séparé pour les utilisateurs d'entrer une extension. Si vous essayez de prendre en charge un processus d'appels sortants, vous souhaiterez peut-être stocker l'indicatif régional et l'indicatif de pays dans des colonnes distinctes, car vous souhaiterez vous assurer que vous disposez de fenêtres spécifiques au fuseau horaire pour appeler des personnes dans différents indicatifs régionaux (en créant un appeler à quelqu'un dans le fuseau horaire de l'Est à 10h va aller bien mieux que faire ce même appel à quelqu'un dans le fuseau horaire du Pacifique où il est 7h).
  • Sexe: pour de nombreuses applications, il est parfaitement raisonnable de stocker un code de genre ("M" ou "F") dans une table. D'autre part, il existe des cas où vous pouvez souhaiter des options supplémentaires (Autre, Intersex, Transgenre) ou où vous devez stocker quelque chose comme le sexe à la naissance et le sexe actuel.
50
Justin Cave

Vous pouvez également deviner sur la base d'exemples de données et de l'audience attendue. Cela dépend de votre emplacement.

Quelques notes:

Adresses:

Noms:

Numéro de téléphone: code international, longueur, mobile vs maison, autoriser le mobile comme seul numéro

24
gbn

En plus des bonnes réponses ci-dessus, n'oubliez pas d'accepter les caractères unicode. Ce n'est pas parce que vous êtes aux États-Unis que vous ne voulez pas accepter de caractères étrangers dans vos colonnes.

Cela dit, je recommande généralement 50 caractères pour les noms. 320 devrait être plus que suffisant pour une adresse e-mail (vous pouvez vérifier la norme ANSI pour être sûr). Pour une erreur d'adresse du côté de la prudence avec 255 caractères. Bien que vous n'ayez probablement jamais besoin d'une adresse aussi grande, vous pourriez le faire si vous incluez des lignes C/O et des trucs comme ça. La ville devrait être assez grande, il y a des noms de villes assez longs. Pour l'état aller avec une table enfant, même avec le pays. Pour le code postal, n'oubliez pas les codes postaux internationaux qui sont plus longs que les codes postaux américains. Juste parce que vous ne soutenez pas l'international, vous pourriez toujours l'être. Il y a beaucoup de citoyens américains qui vivent dans différents comtés, y compris des militaires.

N'oubliez pas que cet état devrait être facultatif car de nombreux pays n'en ont pas.

10
mrdenny

Mon cul devient douloureux de s'asseoir sur la clôture, alors je vais simplement jeter quelques réponses et j'espère ne pas être rejeté dans l'oubli. Veuillez formuler des critiques constructives.

Adresse électronique:

min: 6 ([email protected]). Ou 3 si vous souhaitez suivre les adresses e-mail du domaine local
max: 320 254 (RFC)

La quantité de code pour valider un e-mail est en fait insensée, supposons donc qu'il est valide s'il a un "@"

Vous souhaiterez peut-être résumer une adresse e-mail comme une "méthode de communication", afin de pouvoir facilement répertorier toutes les méthodes avec lesquelles communiquer avec un utilisateur.

Le genre

Le sexe peut changer au fil du temps, vous pouvez donc le suivre si cela est important pour vous. Suivez http://en.wikipedia.org/wiki/ISO/IEC_5218

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

Adresses: NORAM

Je vais prendre la voie bon marché et m'en tenir aux adresses nord-américaines.

Il est pratique de résumer les pays, divisions, villes et comtés principalement en raison de la fiscalité. Les taxes peuvent s'appliquer à plusieurs niveaux, donc si vous pouvez pointer un taux de taxe sur une zone géographique abstraite, vous êtes en or.

Zone géographique :

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)

Ajoutez line2 et line3 si vous en avez besoin.

Voir http://en.wikipedia.org/wiki/Address_ (géographie)

Maintenant, une adresse est une adresse. Plusieurs personnes peuvent vivre à une adresse, et une personne peut avoir plusieurs adresses en même temps et au fil du temps, vous avez donc besoin d'une table plusieurs-pour cela.

PartyAddress 

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

Ajouter un from_date et nullable to_date si le suivi au fil du temps.

Les numéros de téléphone

Une partie peut avoir plusieurs numéros de téléphone et un numéro de téléphone peut être utilisé par plusieurs personnes. Un numéro de téléphone peut être utilisé pour les télécopies, les appels téléphoniques, les modems, etc. et peut avoir des extensions. Celles-ci peuvent également changer au fil du temps.

Numéro de téléphone 

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

Le min peut être 3 (pour "911"), ou peut-être 7 ("310-4NET", qui est un type spécial de numéro local qui ne vous permet pas de composer l'indicatif régional)

Vous pouvez diviser cela en code pays, etc. si nécessaire.

Vous devez utiliser la norme 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, ...}

Noms

Les noms sont durs. Voici pourquoi:

  1. Certaines personnes ont un nom légal avec un seul mot dedans http://en.wikipedia.org/wiki/List_of_legally_mononymous_people

  2. Certaines personnes ont des noms avec beaucoup de mots http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior

  3. Certaines personnes ont plusieurs noms en même temps (par exemple, dans mon université, il y a beaucoup d'étudiants asiatiques, mais ils aiment utiliser des noms "préférés" plus occidentalisés)

  4. Parfois, vous devez suivre les noms des personnes au fil du temps, tels que les noms de jeune fille et les noms de mariés.

  5. Vous voulez faire abstraction d'individus et d'organisations pour diverses bonnes raisons

    créer la table party (id bigserial primary key);

    créer la table party_name (id bigserial clé primaire, party_id bigint not null références party (id), type smallint not null references party_name_type (id) --elided, ex "maiden", "legal");

    créer la table name_component (id bigserial clé primaire, party_name_id bigint not null références party_name (id), type smallint not null références name_component_type (id), --elided ex "given" name text not null);

9
Neil McGuigan

D'un point de vue légèrement différent des réponses précédentes, et depuis il semble OK de parler de LDAP , RFC 4519 - "Lightweight Directory Access Protocol (LDAP): Schema for User Applications" peut être intéressant.

Cela peut être utile si votre application doit être mappée vers un tel répertoire. Sinon, il n'est probablement pas adapté à vos besoins.

Ces définitions sont plus que des données, elles concernent également certains opérateurs qui peuvent être utilisés sur les champs. postalAddress , par exemple est un caseIgnoreListSubstringsMatch . Je ne suggère pas que vous devriez adhérer strictement à ce schéma, mais regarder les principes pourrait être intéressant, en particulier comment vous devrez peut-être comparer le nom et les adresses dans votre application peut être pertinent pour la conception de votre base de données.

3
Bruno

En ce qui concerne les noms, pensez à utiliser des guillemets doubles afin de ne pas avoir à échapper aux apostrophes dans les noms irlandais ou italiens (par exemple, O'Hara ou D'Amato).

Je recommanderais également d'utiliser un bon ensemble d'expressions régulières pour que vous puissiez sortir des parties de vos champs de nom (par exemple, première initiale, surnom, Jr/Sr, etc.).

3
KiloVoltaire