modeler - mer online database
Primer nombre segundo nombre apellido. ¿Por qué no el nombre completo? (22)
Algunos de los problemas se pueden resolver almacenando también una columna adicional como PreferredName. Hacemos eso en nuestra base de datos y también almacenamos una columna de prefijo y una columna de sufijo. por ejemplo, "Prof Henry W Jones Jnr" con nombre preferido como "Indiana Jones".
Estoy tratando de encontrar un mejor enfoque para almacenar el nombre de las personas en la tabla. ¿Cuáles son los beneficios de 3 campos sobre 1 campo para almacenar el nombre de las personas?
ACTUALIZAR
Aquí hay una discusión interesante y recursos sobre el almacenamiento de nombres y la experiencia del usuario
Aquí está la cosa, ni siquiera los humanos pueden hacer esto bien todo el tiempo, hay demasiados datos y demasiados casos especiales. Podría cambiar mi nombre ahora mismo para tener 20 partes, con el 13 del medio como mi "primer nombre". Las partes de los nombres pueden contener cualquier cantidad de palabras, y puede haber cualquier cantidad de partes de nombres. Algunas personas solo tienen 1 nombre (sin apellido). Algunas personas tienen muchos segundos nombres. Algunas personas tienen primeros o apellidos compuestos de varias palabras. Algunas personas enumeran su apellido primero. Algunas personas usan su segundo nombre. Algunas personas usan apodos que obviamente no están relacionados con su nombre de pila.
Si intentas adivinar estas convenciones en el software, NO LOGRARÁS. Período. Tal vez lo haga bien algunas veces, tal vez la mayor parte del tiempo, pero ¿vale la pena? En mi opinión, debe almacenar los nombres como un campo y dejar de tratar de ser lindo usando los nombres para referirse a una persona. Si necesita información adicional sobre un nombre (por ejemplo, un apodo), ¡pregúntele al usuario!
Cada uno de los nombres individuales es una pieza atómica de datos. Cuando se almacenan por separado, es más fácil imprimirlos en diferentes formatos, como Firstname Lastname y Lastname, Firstname.
Como han dicho otros, ¿cómo se descompone un nombre completo en sus partes componentes?
- Colin Angus Mackay
- Jean Michel Jarre
- Vincent Van Gogh
- Pablo Diego José Francisco de Paula Juan Nepomuceno María de los Remedios Cipriano de la Santísima Trinidad Ruiz y Picasso
¿Cómo se puede descomponer de manera confiable ese lote?
Para obtener más información, vea kalzumeus.com/2010/06/17/… .
Cosas como ORDER BY firstname o ORDER BY lastname son posibles cuando divide el nombre en múltiples campos.
No es tan fácil de hacer cuando mezcla todos los nombres en un campo.
El problema i18n puede ser un problema de cualquier manera. Ciertas culturas usan primero el apellido y el nombre de pila al final, lo que afecta a la idea de los nombres y apellidos, por lo que pasamos a los campos para los apellidos y los nombres. Espera , algunas culturas no tienen un apellido o el apellido está modificado por el género del nombre.
Podemos adentrarnos en las culturas tribales donde la persona cambia su nombre a la edad adulta. El nombre de la infancia "Sitting Bull" fue "Jumping Badger".
Esto es algo así como un paseo, pero lo que estoy mostrando es que cuantos más campos tenga, más preciso será el diseño. Debe haber al menos un campo de ''nombre de pila'' not null y un campo de ''apellido'' optional vinculado a un PK que es un número entero. Si se cumplen los requisitos antes mencionados, los campos se pueden agregar sin problemas de interrupción de consultas.
Es posible que desee buscar en los 3 campos separados para uno y su bajo costo para concatenar el nombre completo.
por ejemplo, si desea buscar todos los Sr. Nolans su consulta sería
SELECT Title+'' ''+FirstName+'' ''+Surname As FullName
from table where firstname = ''Mr'' and surname =''Nolan''
hacer esto solo con los nombres completos sería un dolor.
Estaba buscando la Guerra Civil española el otro día, y encontré esta excepción a la mayoría de las reglas:
- Francisco Paulino Hermenegildo Teódulo Franco y Bahamonde, Salgado y Pardo de Andrade
- Padre: Nicolás Franco y Salgado-Araújo
- Madre: María del Pilar Bahamonde y Pardo de Andrade
La próxima vez que esté trabajando en un sistema que tenga que almacenar nombres, voy a intentar algo radical: diseñar a partir de los requisitos.
¿Para qué vamos a usar los nombres?
- Nombre en una etiqueta de dirección para el servicio postal
- Saludo en el sitio web
- Nombre informal
En función de para qué se usarán los nombres, determinaremos cuánta información se almacenará. Tal vez permitimos que el usuario ingrese los tres, incluidos los saltos de línea en el primer caso (el generalísimo Franco podría querer que se enumeren sus títulos completos y sus citas, si aún no estuviera muerto). Tal vez proporcionamos First, Middle, Last, Generation como una opción, y completamos el resto como valores predeterminados. Tal vez ofrecemos otras opciones comunes como Apellido, Nombre de pila.
Esto está en contraste con el estilo antiguo Primero, Medio, Último que hemos usado desde antes de comenzar a programar en COBOL en 1975, y desde ese momento he estado "en forma".
Flexibilidad.
por ejemplo, si alguien tenía un apellido de doble cañón y no un segundo nombre.
He votado algunas de estas respuestas, pero si está buscando evitar la concatenación repetitiva o redundante o desordenada en su código, siempre puede usar una columna calculada en la base de datos o un método en una clase que expone el nombre constantemente reconstruido. Si estas concatenaciones son costosas (porque está imprimiendo un millón de declaraciones), puede usar una columna persistente.
A menudo, permitirá que los usuarios especifiquen nombres como apodos o nombres descriptivos, para que no se refiera a ellos por el nombre en sus registros o siempre como el Sr. Smith.
Todo depende de tus requisitos. No hay una única respuesta buena sin el entorno que se espera que satisfaga.
La mayoría de las veces está ahí para apoyar la escritura de cartas como "el Sr. Fulano", o para buscar / ordenar por apellido, que es muy común.
Dado que el primero / medio / último puede no aplicarse a todas las culturas, podría haber un mejor enfoque. Se podría expresar mejor como "nombre informal" / "nombre formal" / "nombre legal" o algo así.
Aún así, en este punto, primero / medio / último es muy común, y desde el punto de vista de entrada de datos, es lo que todos esperan.
Lamentablemente, esto es como preguntar cuál es la mejor manera de almacenar un número en la base de datos. Depende de lo que vayas a hacer con él, a veces quieres un int, otras veces un byte y, a veces, un float. Con los nombres depende de cosas como de qué culturas espera que vengan sus usuarios, qué planea hacer con los nombres (¿usará estos nombres para conectarse con otro sistema que almacene nombres como "apellido, nombre"? ), y cuánto puede permitirse molestar a sus usuarios. Si se trata de una aplicación interna de Recursos Humanos, probablemente pueda permitirse molestar mucho a los usuarios y tener un desglose formal y estructurado de los componentes de los nombres (hay mucho más que 3, no se olviden mr / mrs, jr, III, múltiples nombres intermedios, apellidos con guiones y quién sabe qué más si intenta manejar nombres de todas las culturas. Si tiene una aplicación web que a los usuarios les puede importar o no, no puede pedirles que se preocupen demasiado.
Lo único que se me ocurre es buscar con fines de búsqueda. Es un poco mejor buscar un campo usando [=] en lugar de decir [como].
Si no necesita mostrar el nombre como palabras separadas, vaya con un solo campo.
Pero si necesita hacer algo como [Estimado Sr. Achu], entonces quizás un enfoque de 3 campos sería mejor.
Mantener separados los campos le permite admitir diferentes formatos de salida y culturas donde el apellido se escribe primero
No estoy seguro de lo práctico que sería, pero tal vez si la sensibilidad cultural es importante en el contexto de la aplicación que se está desarrollando, tal vez un nombre debe ser una colección con cada elemento de la colección con un valor que indique si el nombre es el "primer nombre" direccionable "o el" apellido "direccionable, y así sucesivamente para" título "o cualquier otra cosa que necesite ser identificada. Se podría usar un ID de nombre para identificar el orden de los elementos para volver a componer el nombre completo.
No hay beneficio si nunca necesita ordenar o buscar por nombre, apellido o apellido.
No siempre se puede separar el apellido del nombre completo de manera limpia y confiable, por lo que hay buenas razones para separarlo porque a menudo se necesita un apellido. Después de hacer eso, hay dos enfoques comunes:
- first_name y middle_name; o
- nombres dados.
(2) es sin duda más preferible porque las personas a veces tienen más que los nombres de pila y (1) es más inflexible en este sentido.
Además, otro campo común es preferred_name (además de lo anterior).
Para mí, simplemente es mejor almacenar 3 nombres para que el análisis explícito sea necesario más adelante si se necesitan los componentes individuales.
Siempre puede construir un nombre completo a partir de sus componentes, pero no siempre puede deconstruir un nombre completo en sus componentes.
Digamos que quiere escribir un correo electrónico que empiece por "Querido Richie"; puede hacerlo trivialmente si tiene un campo de nombre dado, pero averiguar cuál es el nombre de alguien a partir de su nombre completo no es trivial.
También puede buscar u ordenar de forma given_name por given_name , o family_name , o lo que sea.
(Tenga en cuenta que estoy usando given_name , family_name , etc. en lugar de first_name , last_name , porque diferentes culturas ponen sus nombres en diferentes órdenes).
Resolver este problema en el caso general es difícil: aquí hay un artículo que da una idea de lo difícil que es: representar los nombres de las personas en Dublin Core .
Solo tiene dos campos, ''Nombre completo'' y ''Nombre preferido'' - fácil. Admite todos los nombres existentes (siempre que el idioma tenga símbolos léxicos ... Por lo tanto, sí, eso excluye los idiomas que no tienen una forma escrita).
Solo asegúrese de que se manejen en algún formato Unicode, y que el código de la aplicación maneje adecuadamente la conversión Unicode.
Soy inglés y solo tengo un nombre. Normalmente lo coloco en el campo ''apellido'' para el menor agravamiento. Normalmente me veo obligado a poner algo en el campo ''primer nombre'' también, que por definición es incorrecto.
Cualquier intento de imponer algo más que "Nombre" está condenado a estar equivocado al menos algunas veces, y a veces puede ser muy frustrante para los usuarios. Los nombres individuales son comunes en el sur de la India, Indonesia y Pakistán (que son cientos de millones de personas), así como también el bicho raro en el Reino Unido como yo.
La primera, la segunda, la última cosa está muy centrada en los Estados Unidos. Pocos otros países piensan en los nombres de esa manera. Por favor deja de hacerlo.
¡Mantenga sus datos tan limpios como pueda!
¿Cómo?
Pregúntele a su usuario solo algunas cosas que realmente necesita al momento de preguntar.
Cómo almacena el nombre no importa. Lo que importa es eso
- la experiencia del usuario es tan buena como puede ser
- no tienes datos falsos en tu sistema
Si molestas a los usuarios con campos obligatorios para que los completen y los vuelvan a preguntar varias veces, pueden enfadarse y no comprar tu aplicación allí mismo. Desea evitar malas experiencias de usuario en todo momento.
A ningún usuario le importa lo fácil que es buscar en su base de datos su segundo nombre. Él quiere tener una experiencia fácil, sentirse bien, eso es todo.
¿Qué hacen los usuarios si se ven obligados a ingresar datos como su dirección postal o incluso su dirección de correo electrónico cuando solo desean una cuenta de "solo lectura" sin necesidad de notificaciones? Ponen datos basura en su sistema. Esto hará que tus algoritmos de súper búsqueda y clasificación sean inútiles de todos modos.
Por lo tanto, mi consejo sería que en cualquier aplicación recolecte la menor información de su usuario que realmente necesite para poder atenderlas, nada más.
Si, por ejemplo, tiene una tienda en línea para alimentos para mascotas, no solicite a sus usuarios que se registren en el tipo de mascotas que poseen. Haz que sea una opción para que completen una vez que inicien sesión y todos contentos (nuevos clientes). No les pregunte su dirección postal hasta que pidan cosas que realmente lleven a su casa, cosas que paguen y por lo tanto se preocupen de que USTED tenga sus coordenadas exactas .
Esto conducirá a una calidad de datos mucho mejor y esto es lo que debe preocuparse, no detalles técnicos del que el usuario no se beneficia ...
En su ejemplo, simplemente le pediría el nombre completo (aunque no estoy seguro) y una vez que el usuario se suscriba voluntariamente a su boletín informativo, deje que el usuario decida cómo quiere que se lo dirija ...