Mejores prácticas en campos comunes de personas (nombre, correo electrónico, dirección, género, etc.) [cerrado]

¿Cuáles son las mejores prácticas más comunes en longitud y tipo de datos en campos comunes como:

• Primer nombre
• Apellido
• Habla a
• Email
• Sexo
• Estado
• Ciudad
• País
• Número de teléfono

etc ....

Tendería a sospechar mucho de cualquier conjunto de mejores prácticas universales porque, para la mayoría de estos campos, el diablo está en los detalles. El hecho de que la información sea relativamente común no significa que su aplicación use los datos exactamente de la misma manera que otras aplicaciones la usan. Eso significa que su modelo de datos puede necesitar ser ligeramente diferente.

• Nombre y apellido: ¿Por qué estás capturando el nombre? Si tiene el requisito de capturar el nombre legal completo de una persona (es decir, está preparando documentos legales o certificados de nacimiento), es probable que desee dejar más espacio para que la gente escriba de lo que lo haría si solo solicita el nombre de una persona para que pueda tener algo para llamarlos en su nueva aplicación web.
• Dirección: ¿Qué vas a hacer con la dirección? ¿Qué tipo de direcciones estás almacenando? Si está almacenando la dirección de una propiedad en los Estados Unidos en la que está creando una hipoteca, es probable que le importe mucho obtener una dirección completamente estandarizada, en cuyo caso el modelo de datos probablemente querrá ajustarse muy de cerca a su dirección herramienta de estandarización devuelve. Si solo desea que las personas puedan escribir una dirección para entregar un producto, probablemente sea suficiente con un par de líneas para texto de forma libre. La longitud de las líneas allí puede depender de los requisitos de los procesos posteriores que hacen cosas como imprimir etiquetas de dirección.
• Estado: suponiendo que pueda identificar los valores de estado válidos, probablemente tenga sentido crear una STATEtabla y crear una relación de clave externa entre las tablas STATEy ADDRESS. Pero la capacidad de identificar los valores válidos implica que está limitando el conjunto de direcciones válidas al menos a un conjunto particular de países. Eso está bien para muchos sitios, pero luego tienes que hacer un poco de trabajo para apoyar a un nuevo país.
• Ciudad: si se trata de datos donde existen regulaciones potencialmente a nivel de ciudad (es decir, donde hay diferentes tipos de tasas impositivas que se aplican en función de la ciudad), es posible que desee tratarla de manera muy similar al estado y tener un CITYtabla con las ciudades válidas y una relación de clave externa entre las tablas CITYy ADDRESS. Por otro lado, si solo está tratando de entregar un producto y no le importa mucho si tiene varias versiones de la misma ciudad en su tabla, dejar que el usuario ingrese el texto de forma libre es suficiente. Por supuesto, si está almacenando claves foráneas, tendrá una buena cantidad de trabajo para asegurarse de tener todos los valores válidos. Pero hay productos en los que el punto es que la compañía ya ha realizado ese trabajo (es decir, bases de datos de impuestos a las ventas).
• Teléfono: ¿Qué haces con los números de teléfono y por qué? Algunas aplicaciones querrán tomar números de teléfono en cualquier formato que el usuario decida ingresar y conservar ese formato para todas las consultas posteriores. Esto sería común si está diseñando una libreta de direcciones personal donde los usuarios tienen sus propias preferencias sobre cómo se almacenan y se muestran los números de teléfono. Otras aplicaciones desearían ignorar el formato que se ingresa, extraer solo los caracteres numéricos y luego formatear los datos en la recuperación para que todos los números de teléfono tengan un formato similar. Si está atendiendo a empresas, es posible que desee un campo separado para que los usuarios ingresen una extensión. Si está intentando admitir un proceso de llamadas salientes, es posible que desee almacenar el código de área y el código de país en columnas separadas porque '
• Género: para muchas aplicaciones, es perfectamente razonable almacenar un código de género ('M' o 'F') en una tabla. Por otro lado, hay casos en los que puede desear opciones adicionales (Otros, Intersex, Transgénero) o donde necesita almacenar algo como el género al nacer y el género actual.

También puede adivinar basándose en datos de muestra y audiencia esperada. Depende de tu ubicación.

Algunas notas:

Direcciones:

• No tengo un estado y me irrita cuando tengo que elegir "Fuera de EE. UU."
• Los condados postales del Reino Unido no se parecen a las principales regiones del gobierno local: consulte "Tipo y tamaño de columna para subdivisiones internacionales de países (estados, provincias, territorios, etc.)" en SO donde rompí las suposiciones de alguien

Nombres:

• No olvide el apellido, nombre de pila, conocido como, nombre tribal, patronímico, nombre de generación, etc.
• Consulte "Los programadores de falsedades creen sobre los nombres" y luego considere llorar
• Ver "Apellido primero" y solo llorar
• SO "¿Cuál es el nombre humano más largo que puedes esperar?" por un ejemplo trabajado

Número de teléfono: código internacional, longitud, móvil vs casa, permitir móvil como único número

Además de las excelentes respuestas anteriores, no olvides aceptar caracteres Unicode. El hecho de que esté en los EE. UU. No significa que no desee aceptar caracteres extranjeros en sus columnas.

Dicho esto, generalmente recomiendo 50 caracteres para los nombres. 320 debería ser más que suficiente para una dirección de correo electrónico (puede verificar el estándar ANSI para estar seguro). Para el error de dirección en el lado de la precaución con 255 caracteres. Si bien es probable que nunca necesite una dirección tan grande, podría incluir líneas de C / O y cosas así. La ciudad debería ser bastante grande, hay algunos nombres de ciudad bastante largos por ahí. Para el estado, vaya con una tabla secundaria, lo mismo con el país. Para el código postal, no se olvide de los códigos postales internacionales que son más largos que los códigos postales de EE. UU. El hecho de que no sea internacional aún puede serlo. Hay muchos ciudadanos estadounidenses que viven en diferentes condados, incluidos militares.

No olvide que el estado debería ser opcional, ya que muchos países no tienen estados.

Me duele el trasero por estar sentado en la cerca, así que voy a tirar algunas respuestas y espero no ser descalificado. Por favor, ofrezca una crítica constructiva.

Dirección de correo electrónico:

min: 6 ([email protected]). O 3 si desea realizar un seguimiento de direcciones de correo electrónico de dominio locales
max: 320 254 (RFC)

La cantidad de código para validar un correo electrónico es realmente una locura, así que supongamos que es válido si tiene una "@"

Es posible que desee abstraer una dirección de correo electrónico como un "método de comunicación", para que pueda enumerar fácilmente todos los métodos con los que comunicarse con un usuario.

Género

El género puede cambiar con el tiempo, por lo que puede rastrearlo si es importante para usted. Siga http://en.wikipedia.org/wiki/ISO/IEC_5218

NOT_KNOWN(0),
MALE(1),
FEMALE(2),
NOT_APPLICABLE(9);

Direcciones: NORAM

Voy a tomar el camino barato y seguir con las direcciones de América del Norte.

Es conveniente resumir países, divisiones, ciudades y condados principalmente debido a los impuestos. Los impuestos pueden aplicarse en muchos niveles, por lo que si puede apuntar una tasa impositiva a un área geográfica abstracta, es oro.

Área geográfica :

id: int  
type: {country, division, county, city, indian reservation}  
name: varchar(45)  [1]
abbreviation: nullable varchar(4)  
parent_id: nullable int  

Dirección :

id: int  
postal_area_id: int, references GeographicArea  
county_or_city_id: int, references GeographicArea  
street_address: varchar(255)  
suite: nullable varchar(255)  

Agregue line2 y line3 si es necesario.

Ver http://en.wikipedia.org/wiki/Address_(geography)

Ahora, una dirección es una dirección. Varias personas pueden vivir en una dirección, y una persona puede tener varias direcciones al mismo tiempo y con el tiempo, por lo que necesita una tabla de muchos para muchos.

PartyAddress

party_id: int references Party  
address_id: int references Address  
purpose: {home, work, ...}  

Agregue from_dateay anulable to_datesi realiza un seguimiento a lo largo del tiempo

Números de teléfono

Una parte puede tener múltiples números de teléfono, y varias personas pueden usar un número de teléfono. Un número de teléfono puede usarse para faxes, llamadas telefónicas, módems, etc. y puede tener extensiones. Todo esto puede cambiar con el tiempo también.

Número de teléfono

id: int  
value: varchar(15) - the max allowed by the ITU  

El mínimo puede ser 3 (para "911") o quizás 7 ("310-4NET", que es un tipo especial de número local que no le permite marcar el código de área)

Puede dividir esto en código de país, etc. si es necesario.

Debe usar el estándar 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, ...}  

Nombres

Los nombres son duros. Este es el por qué:

1. Algunas personas tienen un nombre legal con una sola palabra http://en.wikipedia.org/wiki/List_of_legally_mononymous_people

2. Algunas personas tienen nombres con muchas palabras http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior

3. Algunas personas tienen varios nombres al mismo tiempo (por ejemplo, en mi universidad hay muchos estudiantes asiáticos, pero les gusta usar nombres "preferidos" más occidentalizados)

4. A veces, necesita rastrear los nombres de las personas a lo largo del tiempo, como los nombres de soltera y casados.

5. Desea abstraer a individuos y organizaciones por una variedad de buenas razones.

   crear fiesta en la mesa (clave principal de ID bigserial);

   crear tabla party_name (id bigserial, clave principal, party_id bigint no referencias nulas party (id), tipo smallint no referencias nulas party_name_type (id) --elided, ex "doncella", "legal");

   crear tabla nombre_componente (id bigserial clave principal, party_name_id bigint no referencias nulas party_name (id), tipo smallint no null referencias name_component_type (id), --elided ex "dado" el texto del nombre no es nulo);

Desde una perspectiva ligeramente diferente a las respuestas anteriores, y dado que parece correcto hablar sobre LDAP , RFC 4519 - "Protocolo ligero de acceso a directorios (LDAP): esquema para aplicaciones de usuario" puede ser de interés.

Puede ser útil si su aplicación necesita ser asignada a dicho directorio. De lo contrario, probablemente no se adapte a sus requisitos.

Estas definiciones son más que solo datos, también se refieren a algunos operadores que se pueden usar en los campos. postalAddress, por ejemplo es a caseIgnoreListSubstringsMatch. No estoy sugiriendo que se adhiera estrictamente a este esquema, pero mirar los principios podría ser interesante, en particular cómo puede que tenga que comparar nombres y direcciones en su aplicación puede ser relevante para el diseño de su base de datos.

Con respecto a los nombres, considere usar comillas dobles para no tener que escapar de los apóstrofes en nombres irlandeses o italianos (por ejemplo, O'Hara o D'Amato).

También recomendaría usar un buen conjunto de expresiones regulares para que pueda generar partes de sus campos de nombre (por ejemplo, primera inicial, apodo, Jr / Sr, etc.).