J'ai récemment réfléchi à des noms et à la façon dont nous les stockons. Généralement, une personne aura une première, du dernier prénom. Si vous souhaitez être particulièrement complet, vous pouvez ajouter un champ suffixe, peut-être même un champ de titre. Donc, si quelqu'un veut être "Dr. John Q. Public III", ils le peuvent. Mais une personne peut avoir plus d'un suffixe honorifique et plus d'un suffixe. Cela pourrait aussi avoir un nom de famille d'un trait d'union. Alors, que si vous êtes "Dr. John Quintus Maximus Public-Doe III Ph.D. MD. RPH."? Vous pourriez faire:
Mais alors il devient un ours pour travailler avec et personne ne cesse de les utiliser de toute façon. existe une "manière standard" généralement acceptée pour stocker des données de noms?
9 Réponses :
Je commencerais par regarder le VCARD Standard; il a besoin d'un peu de normalisation.
La manière standard consiste à examiner vos besoins et à stocker les données requises. Bien que ce soit un problème académique intéressant, la vérité est que, dans les dizaines de systèmes que j'ai travaillé, le premier et le nom de famille sont généralement suffisants. Parfois, nous stockons une initiale moyenne, mais la plupart du temps même que ce n'est pas nécessaire.
Si vous avez besoin de stocker tout le Dr John Quintus Maximus Public-Doe III Ph.D. MARYLAND. Les informations de RPH, alors vous conçus de stockage pour cela. Mais tant que votre nom de famille permet suffisamment de données, le Dr Maximus peut également taper autant ou aussi peu qu'il voudrait être stocké sur son nom et ses titres.
de mon expérience c'est généralement
Quelque chose d'autre a tendance à être surkill (sauf si nécessaire dans votre application spécifique) et une douleur à gérer
Je préfère Style de nommage de l'annonce < Pré> xxx
+1: Prénom, nom (pour le tri) et nom d'affichage (pour inclure toutes les décorations que les gens aiment avoir.) Et raisonnablement compatible avec d'autres moyens de stocker des informations sur les personnes. C'est ce que LDAP (et AD) sont pour.
+1 (au LDAP) pour encapsuler les champs les plus nécessaires de manière standard, -100 pour une nommage incohérent incohérent ( nom donné , sn ... Quoi?) Et bizarre camelcaps ( wwwhomepage ? Sérieusement?).
Ce qui suit est une mauvaise idée (voir le premier commentaire):
baiser! Libérez-vous et utilisez simplement «FULLNAME» :-) (Au cas où vous en auriez besoin, le dernier mot de la chaîne est le «Nom»)
Vous pouvez toujours utiliser: Cher "FullName".
Comment vous gérez honorifiques dépend de vos besoins et de votre public. Vous pouvez collecter "salutation".
Mauvaise idée en général. Oui, vous pouvez avoir un champ FULLNAME, mais il convient de construire sur des fichiers distincts, sinon la commande par nom de famille ou le désherbage par un nom de dernière nom signifie en utilisant comme «% Smith%», ce qui signifie que vous pouvez utiliser l'index. Je ne stockerais jamais que le nom complet.
Bon point :-) J'ai changé la réponse. (Peut-être pour certaines applications Web publiques, cela serait suffisamment bon - où vous appliquez Yagni et ne collectionnez même pas le nom de dernière personne. (Mais ce n'était pas la question). ...
Ne triez pas par "Nom", problème résolu.
Vous devez concevoir votre format de stockage sur la manière dont vous vous attendez à utiliser les données. Si vous devez connaître la différence entre le prénom (s) et le (s) nom (s) de famille, alors avez des colonnes pour chacun. De même, si vous (ou votre entreprise) se soucie de suffixe / préfixe / prénoms / etc ... suffisamment pour vouloir les utiliser de manière spécifique (par exemple spamming tous les clients qui sont des médecins), ont alors des colonnes pour chacun. Mais si tout votre besoin est de les identifier dans un rapport ou dans une salutation par courrier électronique, envisagez une approche plus facile des noms: les noms, last_ames, et laissez-le à cela.
Demandez-vous quel avantage réaliste votre organisation se ferait de stocker chaque composant d'un nom de personnes séparément. Regardez gouvernement forme et voyez combien Informations À propos d'un nom de personnes Ils ressentent la nécessité de capturer.
Sauf si vous avez affaire à un groupe spécialisé de PEOLE comme des médecins où vous pourriez avoir besoin de stocker tous les suffixes de manière facile à rechercher (nous recherchons souvent sur le suffixe professionnel ici), vous pouvez les stocker soit dans Le champ Nom ou dans un champ suffixé séparé (facilite la recherche de toutes les personnes nommées Smith plus fiables si Sufffix est un champ distinct). mais avec une liste délimitée par des virgules. Idem pour les préfixes. Je suggérerais que le prénom, le nom de famille et le Middlename (aide à distinguer les DUPS et sans le dépôt, il est moins susceptible d'être mis en place, même si l'utilisateur le sait) est généralement nécessaire pour pouvoir rechercher et signaler correctement les données. Je suggère également un champ calculé qui formate le nom complet de la manière dont vous le souhaitez affiché sur des courriels, etc.
Parfois, vous ne pensez que vous connaissez vos exigences. L'industrie de l'édition de livres a une norme d'information appelée Onix qui utilise ce qui suit. Il est intéressant de noter que les prénoms d'abord et de milieu sont combinés dans un seul champ.
J'adore celui-ci parce que ça marche à l'international. A également trouvé un lien vers le document actuel: Editeur.org/93/Release- 3.0-téléchargements / # Spécification
Wow, c'est génial. Peut utiliser celui-ci moi-même.
meilleur pour utiliser un seul champ Nom complet.
Voir: https://www.w3.org/international/Questions/qa-personal- Noms
Les noms sont déterminés culturellement, alors ne soyez pas aveuglé par votre propre culture.
Dépend de vos besoins. Avez-vous besoin de rechercher, par exemple. par prénom ou groupe par préfixe? Combien de noms allez-vous stocker? Quels types d'opérations allez-vous effectuer sur ces noms?
Pourquoi voudriez-vous jamais traiter les honorants séparément? Allez-vous gérer les commandes chevaleresques où un kg est classé avant un CGB?
@ S.Lott Je voulais avoir une discussion académique indépendante des exigences et semblait être un bon exemple où il y avait un compromis. Dans un scénario où vous vouliez interroger une population par une combinaison de créitides donnée (par exemple: tous les MCDBAS qui sont également MCITPS), la version normalisée peut alors être préférable à un «champ indésirable».
"Discussion académique indépendamment des exigences"? N'a aucun sens du tout. Nous n'écrivons que des logiciels en raison de "exigences". Si cela ne résout pas un problème, pourquoi déranger? Si vous n'avez pas de "exigences", il n'y a pas de mesure "fait" ou "correct", "complet" ou "cohérent". Sans exigences, un champ de texte est parfait pour ce dont vous parlez.
HMM Votre logique est fondée sur une fausse prémisse. Je n'écris pas logiciel seulement à cause des exigences. J'écris souvent un logiciel qui ne voit jamais la lumière du jour pour la pratique et pour le plaisir. Et ainsi vous ou vous ne seriez pas ici :)
Voir Stackoverflow.com/Questtions/1122328/...