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

17

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 ).

maasg
fuente
1
Me gustaría ver información sobre esto también. Sin embargo, nunca he encontrado algo así. Lo que sería interesante es que alguien hiciera un estudio de caso al ver algunos proyectos de código abierto.
programador
2
lástima que hayas votado negativamente por lo que realmente es una buena pregunta sobre el "profesionalismo" del software al no reinventar tu propio formato de registro.
gbjbaanb
Hombre, desearía que hubiera algún tipo de consistencia en esta área. Importé bases de datos de clientes de una buena cantidad de sistemas, y están en todo el mapa.
TehShrike
¿planea almacenar información sobre número de teléfono, dirección, etc. para un solo país en particular? Puede hacer una diferencia en el tamaño que necesita.
HLGEM

Respuestas:

16

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.


fuente
¡Ojalá pudiera hacer +2 en la última oración!
Maxpm
Gracias. Estoy de acuerdo con la mayoría de sus puntos y ciertamente basaría un diseño en una fase de requisitos adecuada. Dicho esto, para los cálculos de tipo envolvente, ciertamente agradecería los valores predeterminados razonables que podrían tomarse de un estándar razonable 'de facto', por lo que no es un estándar como los formatos EDI, sino algo que la gente está usando de alguna manera generalizada. De esa forma podría ensamblar mi objeto de cliente y obtener una cifra de parque de pelota en un tamaño récord.
maasg
Se pierde mi punto, todo lo que se use de manera generalizada será demasiado amplio y generalizado para ser útil. Será hinchado y demasiado complicado. Aquí es donde SAP, PeopleSoft y Salesforce hacen su dinero. Su material se generaliza hasta tal punto que debe pagar consultores de $$$ altos para personalizarlo para satisfacer las necesidades de su empresa. Por lo general, esto cuesta muchas veces lo que costaría desarrollar y mantener una solución personalizada. Y hacen su dinero después del trabajo , con actualizaciones incompatibles constantes y similares.
4

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.

Justin Cave
fuente
Eso es lo más cerca que he llegado a una respuesta a mi pregunta. Esas pautas son bastante buenas, aunque no completas o concretas, pero definitivamente en el espíritu correcto.
maasg
3

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.

Christian Palmstierna
fuente
1

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):

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.

haylem
fuente
De-Facto Standards in Software-> Muy interesado en estos. ¿Podría agregar algunas referencias?
maasg
Votantes, por favor explique (había 2 en este momento).
haylem
0

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.

gbjbaanb
fuente
0

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).

TMN
fuente
0

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í.

habakuk
fuente