Meilleures pratiques sur les champs de personnes communes (Nom, email, adresse, genre, etc.) [fermé]

44

Quelles sont les meilleures pratiques les plus courantes en termes de longueur et de type de données dans des champs communs tels que:

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

etc....

Snow_Mac
la source
Cette question est WAYY à large. Il devrait être purgé et supprimé.
Evan Carroll

Réponses:

50

J'aurais tendance à être très méfiant vis-à-vis de tout ensemble de bonnes pratiques universelles car, pour la plupart de ces domaines, le diable est dans les détails. Le fait que les informations soient relativement communes ne signifie pas 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 devra peut-être être légèrement différent.

  • Prénom et nom: Pourquoi enregistrez-vous le nom? Si vous devez capturer le nom légal complet d'une personne (par exemple, vous préparez des documents légaux ou des actes de naissance), vous souhaitez probablement laisser plus d'espace à la saisie par rapport à ce que vous demanderiez si vous demandiez simplement le nom d'une personne pour que vous avoir quelque chose à les appeler dans votre nouvelle application web.
  • Adresse: Qu'allez-vous faire avec l'adresse? Quel type 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 voudrez probablement obtenir une adresse entièrement normalisée, auquel cas le modèle de données voudra probablement être très proche de votre adresse. outil de normalisation revient. Si vous voulez simplement que les gens puissent taper une adresse pour livrer un produit, quelques lignes pour le texte libre sont probablement suffisantes. La longueur des lignes peut dépendre des exigences des processus en aval, tels que l'impression d'étiquettes d'adresse.
  • Etat: en supposant que vous puissiez identifier les valeurs d'état valides, il est probablement logique de créer une STATEtable et de créer une relation de clé étrangère entre les tables STATEet ADDRESS. Mais la capacité d'identifier les valeurs valides implique que vous limitez au moins l'ensemble d'adresses valides à un ensemble particulier de pays. C'est bien pour de nombreux sites, mais vous devez ensuite faire un peu de travail pour soutenir un nouveau pays.
  • Ville: si vous traitez avec des données pour lesquelles il existe potentiellement des réglementations au niveau de la ville (c’est-à-dire différents types de taux d’imposition appliqués en fonction de la ville), vous voudrez peut-être traiter ces données à la manière de l’État et CITYtable avec les villes valides et une relation de clé étrangère entre les tables CITYet ADDRESS. D'un autre côté, si vous essayez simplement d'obtenir un produit livré et que vous ne vous souciez pas beaucoup de la présence de plusieurs versions de la même ville dans votre tableau, laisser le texte libre à l'utilisateur suffit. 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. Cependant, il existe des produits pour lesquels le problème est que l'entreprise a déjà effectué ce travail (c'est-à-dire des bases de données sur les taxes 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 choisi par l'utilisateur 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 en matière de stockage et d'affichage des numéros de téléphone. D'autres applications souhaiteraient ignorer le formatage entré, extraire uniquement les caractères numériques, puis formater les données lors de la récupération de sorte que tous les numéros de téléphone aient un formatage similaire. Si vous vous adressez aux entreprises, vous souhaiterez peut-être un champ séparé pour permettre aux utilisateurs de saisir un poste. Si vous essayez de prendre en charge un processus d’appel sortant, vous pouvez stocker l’indicatif régional et le code de pays dans des colonnes distinctes, car vous '
  • Sexe: Pour de nombreuses applications, il est parfaitement raisonnable de stocker un code de genre ('M' ou 'F') dans un tableau. D'autre part, il peut arriver que vous souhaitiez des options supplémentaires (Autre, Intersexuel, Transgenre) ou que vous ayez besoin de stocker quelque chose comme le sexe à la naissance et le sexe actuel.
Justin Cave
la source
réponse intéressante avec beaucoup de choses à penser - mais sans idée utile pour aider les gens à aller plus loin ... par exemple le téléphone, il y a une chose assez simple qui couvrira> = 80% des cas: le nombre que vous pouvez taper un endroit où vous pouvez joindre quelqu'un au téléphone, peut-être en ajoutant que cela devrait également couvrir d'autres pays. Alors oui, il y a une différence de quelques caractères si l' on considère un certain nombre pourrait être avec / sans le préfixe du pays, mais il defintely est une chose comme le plus long numéro de téléphone dans le monde et en utilisant ce plus quelques autres est assez sûr pour la plupart cas
Henning
24

Vous pouvez aussi bien deviner sur la base des données de l'échantillon 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 par rapport à la maison, autoriser le mobile par un seul numéro

gbn
la source
3
Les deux derniers liens ("Nom de famille en premier" et "Quel est le plus long ...") sont cassés.
Marc L.
1
@MarcL. J'ai corrigé le lien "Nom de famille en premier" (si ma modification est acceptée). Le "Quel est le plus long ..." SO questions ont été fermées comme "non constructif" et supprimé (vous pouvez toujours le voir si vous avez> 10k rep).
hache
2
Wayback Machine a l'article "Nom de famille, premier": web.archive.org/web/20160823135055/http://www.solidether.net/…
Av Pinzur
10

Outre les 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 email (vous pouvez vérifier la norme ANSI pour en être sûr). Pour 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 choses comme ça. La ville devrait être assez grande, il y a quelques noms de villes assez longs. Pour l'état aller avec une table d'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. Tout simplement parce que vous ne supportez 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 l'état devrait être facultatif car beaucoup de pays n'ont pas d'état.

mrdenny
la source
Lors de mon dernier projet, j'ai trouvé un document sur les normes postales internationales indiquant 39 comme longueur maximale. La France a un code séparé pour les destinataires de gros volumes qui va après la ville. J'autoriserais 3 ou 4 champs de format libre de cette taille plus pays.
BillThor
9

Mes fesses me font mal d'avoir été assises sur la clôture, alors je vais simplement lancer quelques réponses et espérer ne pas tomber dans l'oubli. S'il vous plaît offrir des critiques constructives.

Adresse e-mail:

min: 6 ([email protected]). Ou 3 si vous souhaitez suivre les adresses électroniques de domaines locaux au
maximum: 320 254 (RFC)

La quantité de code nécessaire pour valider un email est en fait insensée, alors supposons qu'il soit valide s'il contient un "@"

Vous voudrez peut-être utiliser une adresse électronique comme "méthode de communication" afin de pouvoir répertorier facilement toutes les méthodes permettant de communiquer avec un utilisateur.

Le genre

Le sexe peut changer avec le temps, vous pouvez donc 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 le moyen le plus économique et m'en tenir aux adresses nord-américaines.

Il est commode de résumer des pays, des divisions, des villes et des comtés, principalement à cause de la fiscalité. Les taxes peuvent s'appliquer à plusieurs niveaux. Par conséquent, si vous pouvez indiquer 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_(geography)

Maintenant, une adresse est une adresse. Plusieurs personnes peuvent vivre à une adresse et une personne peut avoir plusieurs adresses à la fois et au fil du temps. Vous avez donc besoin d'une table plusieurs-plusieurs pour cela.

PartyAddress

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

Ajouter un from_dateet nullable to_datesi 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 fax, les appels téléphoniques, les modems, etc., et peut avoir des extensions. Ceux-ci peuvent tous changer avec le temps aussi.

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 le diviser en code de 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 difficiles. Voici pourquoi:

  1. Certaines personnes ont un nom légal contenant un seul mot 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 mariés.

  5. Vous voulez faire abstraction des individus et des organisations pour diverses raisons

    create table party (clé primaire id bigserial);

    create table party_name (id bigserial, clé primaire, party_id bigint pas de références null parti, id, de type smallint non null de références parti_nom_partype (id) --lided, ex "maiden", "legal");

    create table name_component (clé primaire bigserial id, party_name_id bigint non null références party_name (id), type smallint non null références références name_component_type (id), --elided ex "nom de texte donné" non null);

Neil McGuigan
la source
3

Dans une perspective légèrement différente de celle des réponses précédentes, et puisqu'il semble bien de parler de LDAP , le document RFC 4519 intitulé "Protocole LDAP (Lightweight Directory Access Protocol): schéma pour les applications utilisateur" peut présenter un intérêt.

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

Ces définitions ne se limitent pas aux données, elles concernent également des opérateurs pouvant être utilisés sur les champs. postalAddress, par exemple est un caseIgnoreListSubstringsMatch. Je ne suggère pas que vous deviez adhérer strictement à ce schéma, mais examiner les principes pourrait être intéressant, en particulier la manière dont vous devrez peut-être comparer le nom et les adresses de votre application peut être pertinente pour la conception de votre base de données.

Bruno
la source
3

Concernant les noms, pensez à utiliser des guillemets doubles pour ne pas avoir à échapper aux apostrophes des noms irlandais ou italiens (par exemple, O'Hara ou D'Amato).

Je vous recommande également de vous procurer un bon ensemble d’expressions régulières afin que vous puissiez générer une partie de vos champs de nom (par exemple, initiale, pseudonyme, Jr / Sr, etc.).

KiloVoltaire
la source
1
Ou des noms néerlandais tels que mon nom de famille.
Colin 't Hart