tutorial openrecordset currentdb database-design

database-design - openrecordset - recordset vba



Forma estándar de almacenar nombres en una base de datos (8)

Recientemente he estado reflexionando sobre nombres y la forma en que los almacenamos. En general, una persona tendrá un primer, último y segundo nombre. Si quieres ser particularmente completo, puedes agregar un campo de sufijo, quizás incluso un campo de título. Entonces, si alguien quiere ser "Dr. John Q. Public III", pueden hacerlo. Pero una persona puede tener más de un sufijo honorífico y más de uno. En ese caso, también podría tener un apellido con guiones. ¿Y qué si eres "Dr. John Quintus Maximus Public-Doe III Ph.D. MD. RPh."? Podrías hacerlo:

Persons PersonID Prefix FirstName MiddleName LastName Suffix PersonHonorifics PHID PersonID Honorific PersonNames PANID PersonID NameOrder Pero luego tiene que ser un oso con quien trabajar, y nadie termina usándolo de todos modos.

¿Hay una "forma estándar" generalmente aceptada para almacenar datos de nombre?

Algunas veces solo piensas que sabes tus requerimientos. La industria editorial de libros tiene un estándar de información llamado ONIX que usa lo siguiente. Es interesante observar que los nombres Primero y Medio se combinan en un campo.

  • Títulos antes de los nombres (ej .: Profesor, SAR el Príncipe, Santo)
  • Nombres antes de los nombres de las teclas (nombres y / o iniciales del segundo nombre, por ejemplo: Brendan JE)
  • Prefijo a los nombres clave (por ejemplo: van, como en Ludwig van Beethoven)
  • Nombre clave (apellido)
  • Nombres después de los nombres clave (por ejemplo: Ibrahim como en Anwar Ibrahim)
  • Sufijo a los nombres clave (ej .: Jr, III)
  • Calificaciones y honores después de los nombres clave (por ejemplo, MB, PhD)
  • Títulos tras nombres (por ejemplo: duque de Edimburgo)

A menos que esté tratando con un grupo especializado de médicos tipo humanos donde podría necesitar almacenar todos los sufijos de una manera que facilite la búsqueda (a menudo buscamos sufijo profesional aquí), entonces puede almacenarlos en el campo de apellido o en un campo de sufijo separado (hace que buscar a todas las personas llamadas smith sea más confiable si el sufijo es un campo separado). pero con una lista delimitada por comas Lo mismo para los prefijos. Sugeriría que firstname, lastname e middlename (ayuda a distinguir dúas y sin el archivo es menos probable que se coloque incluso si el usuario lo sabe) son generalmente necesarios para poder buscar e informar adecuadamente sobre los datos. También sugiero un campo calculado que formatea el nombre completo de la forma que desea que se muestre en los correos electrónicos, etc.

Comenzaría mirando el estándar vCard ; necesita un poco de normalización

Debe diseñar su formato de almacenamiento en torno a cómo espera usar los datos. Si necesita saber la diferencia entre el primer nombre (s) y apellido (s), entonces tenga columnas para cada uno. Del mismo modo, si usted (o su empresa) se preocupa por el sufijo / prefijo / segundo nombre / etc ... lo suficiente como para querer usarlos de una manera específica (por ejemplo, correo no deseado a todos los clientes que son médicos), tenga columnas para cada uno. Pero si todo lo que necesita es identificarlos en un informe, o en un saludo por correo electrónico, considere un enfoque más fácil de: First_names, Last_Names, y déjelo así.

Pregúntese qué beneficio realista obtendría su organización almacenando cada componente del nombre de una persona por separado. Mire los formularios del gobierno y vea cuánta información sobre el nombre de una persona sienten la necesidad de capturar.

Desde mi experiencia, por lo general es

  • Título (como FK, vinculando a una tabla de títulos)
  • Nombre
  • Segundo nombre
  • Apellido
  • Apellido anterior (si es necesario, para detectar el cambio de nombre de las mujeres casadas)
  • Sufijo

Todo lo demás tiende a ser exagerado (a menos que sea necesario en su aplicación específica) y un dolor para administrar

La forma estándar es observar sus requisitos y almacenar los datos requeridos. Si bien este es un problema académico interesante, la verdad es que, en las docenas de sistemas en los que he trabajado, el nombre y el apellido suelen ser suficientes. Algunas veces almacenaremos una inicial en el medio, pero la mayoría de las veces incluso eso no es requerido.

Si tiene el requisito de almacenar todo el Dr. John Quintus Maximus Public-Doe III Ph.D. MARYLAND. La información de RPh, entonces inventas almacenamiento para eso. Pero mientras su apellido permita suficientes datos, entonces el Dr. Maximus puede escribir tanto o tan poco como le gustaría que se almacenara sobre su nombre y títulos.

La siguiente es una mala idea (ver el primer comentario):

¡BESO! Libérate y utiliza "Nombre completo" :-) (En caso de que lo necesites, la última palabra de la cadena es "Apellido")

Siempre puedes usar: Dear "Fullname".

La forma en que maneja los honoríficos depende de sus requisitos y su audiencia. Puedes coleccionar "saludo".

Prefiero el estilo de denominación AD

First Name givenName Last Name sn Initials initials Display Name displayName Description description Office physicalDeliveryOfficeName Telephone Number telephoneNumber Telephone: Other otherTelephone E-Mail mail Web Page wWWHomePage Web Page: Other url