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

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

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.

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:

• Je n'ai pas d'état et ça m'énerve quand je dois choisir "Outside USA"
• Les comtés postaux du Royaume-Uni ne ressemblent en rien aux régions où se trouvent les administrations locales: voir "Type et taille des colonnes pour les subdivisions de pays internationales (États, provinces, territoires, etc.)" à la SO où j'ai cassé les hypothèses de quelqu'un

Noms:

• N'oubliez pas le nom de famille, le prénom, le nom connu, le nom de la tribu, le nom patronymique, le nom de la génération, etc.
• Voir "Les concepteurs de mensonges croient au sujet des noms" et ensuite envisager de pleurer
• Voir "Nom Prénom" et pleurer
• SO "Quel est le plus long nom humain auquel vous pouvez vous attendre?" pour un exemple travaillé

Numéro de téléphone: Code international, longueur, mobile par rapport à la maison, autoriser le mobile par un seul numéro

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.

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

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.

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