Padrões de fato para registro de informações do cliente [fechado]

Atualmente, estou avaliando um potencial novo projeto que envolve a criação de um banco de dados para informações típicas do cliente (ID do usuário, senha, nome e sobrenome, email, endereço, telfnr ...). Neste ponto, os requisitos são apenas aproximadamente definidos.

O banco de dados do cliente é esperado em O (milhões) de registros. Para calcular alguns números do verso do envelope para o dimensionamento do banco de dados e avaliar possíveis opções e arquiteturas de banco de dados, estou procurando alguns padrões de fato para esse tipo de registro. Em particular, o tamanho padrão de cada campo (nome, sobrenome, endereço, ...) ou média típica para um simples registro de cliente seria uma ótima informação .

Com tantos sites de comércio eletrônico por aí, deve haver algum tipo de configuração típica que possa ser reutilizada e evitar reinventar a roda.

Alguma ideia?

---- editar ----

As respostas parecem estar direcionadas para a adoção de um registro padrão do cliente em relação ao design do seu. Eu gostaria de enfatizar que o foco desta pergunta é localizar uma referência para o dimensionamento de campo para um objeto de cliente e evitar descobrir isso sozinho (enfatizei essa parte no texto original - agora em negrito -)

O bom dos padrões é que você tem muitos por onde escolher. - Andrew Stuart Tanenbaum

Coisas assim são muito específicas para um cliente e a indústria; qualquer coisa genérica incluirá tudo e a pia da cozinha. Especialmente os formatos do tipo EDI, eles foram definidos organicamente ao longo de uma década ou mais na maioria dos casos e incluem tudo o que toda empresa no comitê já desejou. Eles deveriam ser genéricos e tornaram-se extremamente específicos e quebradiços.

Não há caminho real para o design ou as informações que você deseja. Faça o tempo e o esforço para obter os requisitos e obter uma estimativa concreta. Caso contrário, você estará mais errado do que correto. A única maneira de saber o que você precisa saber é fazer as perguntas e descobrir você mesmo.

Muitos sistemas de CRM usam o que agora é chamado de padrão de objeto Expando, anteriormente conhecido como padrão de propriedade dinâmica . É basicamente uma construção de dicionário de par de valores-chave. Exceto em casos muito especiais, é considerado um design antipadrão e deve ser evitado.

Eu projetei e construí pelo menos 8 soluções de CRM personalizadas nos últimos 20 anos, todos e cada um tinha requisitos diferentes e nenhum dos modelos de dados (lógicos ou físicos) teria funcionado em todos os domínios.

Soluções específicas para casos específicos sempre serão melhores projetos.

Há um encadeamento na pilha do DBA sobre práticas recomendadas para campos de pessoa comum que discute os problemas. É muito importante o que você planeja fazer com os dados e o quanto você precisa ser cuidadoso. Se você realmente precisar oferecer suporte a todos os endereços de email válidos ou a todos os nomes válidos, suas colunas precisarão ser muito maiores do que se você quiser apenas dar suporte ao que quer que sua organização e aplicativo considerem um subconjunto razoável dos valores válidos.

Como Jarrod apontou, se você seguir um padrão genérico, definitivamente terá um formato de registro que inclui muitas coisas que seu sistema nunca precisará. Como você já sabe que haverá um número bastante grande de registros, é provável que ocorram problemas de desempenho desnecessários, porque você oferece suporte a dados que nunca serão usados. Por outro lado, também é provável que o padrão não inclua os campos necessários, o que será um problema doloroso para resolver; ou você quebra o padrão adicionando esses campos ou terá que encontrar uma maneira (provavelmente desajeitada) de incluir os campos não padrão no padrão.

Acho que o verdadeiro problema aqui não é encontrar um padrão único (que quase sempre será único), mas você foi encarregado de estimar uma solução onde os requisitos não são especificado ainda. Nesses casos, acho que a única coisa profissional a fazer é fazer uma estimativa mínima com base nos requisitos que você possui e, em seguida, fazer uma estimativa máxima com base em todos os requisitos indefinidos possíveis que você acha que possam surgir. Com certeza, a estimativa pode se tornar ridiculamente grosseira; nesse caso, você deve explicar a quem pediu isso, que não é viável fazer uma boa estimativa até que os requisitos sejam mais bem definidos.

Normas internacionais existentes

Existem alguns padrões, mas específicos para determinados campos, com requisitos variados para cada um deles, dependendo das necessidades de coleta de dados.

Por exemplo, mas não limitado a (e falando da experiência com ambos):

• Software que lida com dados do paciente e registros médicos, se você planeja ser certificado para determinadas especificações.
  • Padrões de dados uniformes para a captura de informações de registros médicos de pacientes no ponto de atendimento (apresenta uma lista de diferentes padrões para registros médicos)
• Registros médicos eletrônicos e suas normas técnicas

• campo mais amplo dos registros eletrônicos de saúde e suas normas técnicas

• software que lida com registros de dados de chamadas de operadoras móveis e registros de dados de serviço (não exatamente como padrão, mas para interoperabilidade entre redes de parceiros).

Algumas das opções acima apontam para documentos razoavelmente detalhados, listando até os requisitos de integridade e formatação de campos (por exemplo, o HL7 usa tipos de dados bem definidos ). No entanto, muitos deles não entram em tantos detalhes.

Padrões do governo para registros internos

Os governos, nacionais ou locais, geralmente têm uma forte necessidade de registrar e armazenar informações pessoais para escritórios públicos e, obviamente, criaram "padrões" próprios, que eles implementam em suas organizações (com níveis variados de sucesso e interoperabilidade com organizações parceiras) .

Um exemplo pode ser este padrão de formatos de dados para registros de identidade do governo da Nova Zelândia.

Padrões De-Facto em Software

Você pode se inspirar nelas ou usar a fonte do software CRM de código aberto conhecido para usar como práticas recomendadas e diretrizes para as especificações de dados dos dados de seus clientes.

Veja a lista dos 10 principais softwares de CRM de negócios e sociais de código aberto , para os quais você mesmo pode procurar os modelos de dados deles.

Eu diria que você precisa encontrar padrões para sistemas EDI . Existem centenas de documentos 'padrão', então você precisa escolher um com base em seus requisitos. Por exemplo, aqui está um formato para a fatura TRADACOMS da qual você pode obter os campos que deseja.

O Open Applications Group publica um conjunto de padrões abertos para implementação e interoperabilidade de aplicativos. Eles são principalmente orientados para XML, mas especificam um registro padrão do cliente com campos e tamanhos individuais (procure CustomerPartyMasterna lista de padrões de documentos).

Eu diria "Você não vai precisar (ainda)". E com Ron Jeffries: "Sempre implemente as coisas quando você realmente precisa delas, nunca quando você apenas prevê que precisa delas".

Portanto, talvez seja hora de adicionar um banco de dados concreto ao projeto, você tenha muito mais conhecimento sobre os dados que serão armazenados lá.