Normas de facto para el registro de información del cliente [cerrado]

Actualmente estoy evaluando un nuevo proyecto potencial que implica crear una base de datos para la información típica del cliente (ID de usuario, contraseña, nombre y apellido, correo electrónico, dirección, telfnr ...). En este punto, los requisitos solo se definen aproximadamente.

La base de datos del cliente se espera en el O (millones) de registros. Para calcular algunos números al final del sobre para el tamaño de la base de datos y evaluar las posibles opciones y arquitecturas de bases de datos, estoy buscando algunos estándares de facto para este tipo de registros. En particular, el tamaño estándar de cada campo (nombre, apellido, dirección, ...) o promedio típico para un registro de cliente simple sería una gran información .

Con tantos sitios web de comercio electrónico, debería haber algún tipo de configuración típica que se pueda reutilizar y evitar reinventar la rueda.

¿Algunas ideas?

---- editar ----

Las respuestas parecen orientarse hacia la adopción de un registro de cliente estándar frente al diseño del suyo. Me gustaría enfatizar que el enfoque de esta pregunta es ubicar una referencia para el tamaño de campo para un objeto de cliente, y evitar descubrirlo por mi cuenta (he enfatizado esa parte en el texto original, ahora en negrita ).

Lo bueno de los estándares es que tienes tantos para elegir. - Andrew Stuart Tanenbaum

Cosas como esta son muy específicas para un cliente y la industria, cualquier cosa genérica incluirá todo y el fregadero de la cocina. Especialmente los formatos de tipo EDI, se definieron orgánicamente durante una década o más en la mayoría de los casos e incluyen todo lo que cada compañía en el comité quiso. Se suponía que eran genéricos de la industria, y se volvieron extremadamente específicos de la industria y extremadamente frágiles.

No hay un camino real hacia el diseño o la información que desea. Haga el tiempo y el esfuerzo para obtener los requisitos y obtener una estimación concreta. De lo contrario, estará más equivocado que correcto. La única forma de saber lo que necesita saber es hacer las preguntas y resolverlo usted mismo.

Muchos sistemas CRM usan lo que ahora se llama un patrón de objeto Expando, anteriormente conocido como un patrón de propiedad dinámica . Básicamente es una construcción de diccionario de pares de valores clave. Excepto en casos muy especiales, se considera un diseño antipatrón y debe evitarse.

He diseñado y construido por lo menos 8 soluciones a medida CRM en los últimos 20 años, todos y cada uno tenía diferentes requisitos y ninguno de los modelos de datos (físicos o lógicos) hubiera trabajado a través del tablero para todos los dominios.

Las soluciones específicas para casos específicos siempre serán mejores diseños.

Hay un hilo en la pila de DBA sobre las mejores prácticas para los campos de personas comunes que discute los problemas. Importa mucho lo que planeas hacer con los datos y cuán exhaustivo debes ser. Si realmente necesita admitir todas las direcciones de correo electrónico válidas o todos los nombres válidos, sus columnas necesitarán ser mucho más grandes que si simplemente desea admitir lo que su organización y aplicación considere un subconjunto razonable de los valores válidos.

Como señaló Jarrod, si sigue un estándar genérico, definitivamente terminará con un formato de registro que incluye muchas cosas que su sistema nunca necesitará. Como ya sabe que habrá un número bastante grande de registros, es probable que tenga problemas de rendimiento innecesarios porque admite datos que nunca se utilizarán. Por el contrario, también es probable que el estándar no incluya campos que sí necesita, lo que será un problema difícil de resolver; o rompes el estándar al agregar estos campos, o tendrás que encontrar alguna forma (probablemente torpe) de incluir los campos no estándar dentro del estándar.

Creo que el verdadero problema aquí no es encontrar un estándar de talla única (que casi siempre será de talla única), sino que se le ha asignado la tarea de estimar una solución donde los requisitos no son especificado todavía. En estos casos, creo que lo único profesional que puede hacer es hacer una estimación mínima basada en los requisitos que tiene, y luego hacer una estimación máxima basada en todos los requisitos indefinidos posibles que cree que podrían surgir. Efectivamente, la estimación puede volverse ridículamente aproximada, en cuyo caso debe explicar a quien le encargó esto, que no es factible hacer una buena estimación hasta que los requisitos estén más bien definidos.

Normas internacionales existentes

Existen bastantes estándares, pero específicos para ciertos campos, con requisitos variables para cada uno de ellos según sus necesidades de recopilación de datos.

Por ejemplo, pero no limitado a (y hablando de la experiencia con ambos):

• Software que trata con datos de pacientes y registros médicos si planea certificarse para ciertas especificaciones.
  • Estándares uniformes de datos para capturar información de registros médicos del paciente en el punto de atención (presenta una lista de diferentes estándares para registros médicos)
• Registros médicos electrónicos y sus estándares técnicos

• El campo más amplio de los registros electrónicos de salud y sus normas técnicas

• software que trata con registros de datos de llamadas y servicios de operadores móviles (no exactamente como estándar, sino para la interoperabilidad entre redes asociadas).

Algunos de los enlaces anteriores a documentos bastante detallados, que enumeran incluso los requisitos para el estado y el formato de los campos (por ejemplo, HL7 utiliza tipos de datos bien definidos ). Sin embargo, en muchos de ellos no entran en tanto detalle.

Estándares impulsados ​​por el gobierno para registros internos

Los gobiernos, nacionales o locales, a menudo tienen una fuerte necesidad de registrar y almacenar información personal para oficinas públicas, y obviamente han creado sus propios "estándares", que implementan en sus organizaciones (con diferentes niveles de éxito e interoperabilidad con las organizaciones asociadas) .

Un ejemplo podría ser este Estándar de formatos de datos para registros de identidad del Gobierno de Nueva Zelanda.

Estándares de facto en software

Puede inspirarse en ellos o utilizar la fuente de software CRM de código abierto conocido para usar como mejores prácticas y pautas para las especificaciones de datos de sus datos de cliente.

Consulte la lista de los 10 principales programas de software de CRM social y empresarial de código abierto , para los cuales puede buscar sus modelos de datos usted mismo.

Yo diría que necesita encontrar estándares para los sistemas EDI . Hay cientos de documentos 'estándar', por lo que deberá elegir uno según sus requisitos. Por ejemplo, aquí hay un formato para la factura de TRADACOMS que puede obtener de los campos que desee.

El Abierto de Aplicaciones Grupo publica un conjunto de estándares abiertos para la implementación de aplicaciones y la interoperabilidad. En su mayoría están orientados a XML, pero sí especifican un registro de cliente estándar con campos y tamaños individuales (busque CustomerPartyMasteren la lista de estándares del documento).

Yo diría "No lo vas a necesitar (todavía)". Y con Ron Jeffries: "Siempre implemente las cosas cuando realmente las necesite, nunca cuando prevea que las necesita".

Entonces, tal vez si es hora de agregar una base de datos concreta al proyecto, tenga mucho más conocimiento sobre los datos que se almacenarán allí.