¿Cuáles son las mejores prácticas más comunes en longitud y tipo de datos en campos comunes como:
etc ....
Respuestas:
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.
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.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).También puede adivinar basándose en datos de muestra y audiencia esperada. Depende de tu ubicación.
Algunas notas:
Direcciones:
Nombres:
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.
min: 6 (a@g.cn). 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.
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);
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
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, ...}
Los nombres son duros. Este es el por qué:
Algunas personas tienen un nombre legal con una sola palabra http://en.wikipedia.org/wiki/List_of_legally_mononymous_people
Algunas personas tienen nombres con muchas palabras http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior
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)
A veces, necesita rastrear los nombres de las personas a lo largo del tiempo, como los nombres de soltera y casados.
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.).