Quelles sont les meilleures pratiques les plus courantes en termes de longueur et de type de données dans des champs communs tels que:
etc....
Réponses:
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.
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.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).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
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.
min: 6 (a@g.cn). 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 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);
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.
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, ...}
Les noms sont difficiles. Voici pourquoi:
Certaines personnes ont un nom légal contenant un seul mot http://en.wikipedia.org/wiki/List_of_legally_mononymous_people
Certaines personnes ont des noms avec beaucoup de mots http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior
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)
Parfois, vous devez suivre les noms des personnes au fil du temps, tels que les noms de jeune fille et les noms mariés.
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.).