J'évalue actuellement un nouveau projet potentiel qui implique la création d'une base de données pour les informations client typiques (userid, pwd, prénom et nom, email, adresse, telfnr ...). À ce stade, les exigences ne sont définies qu'en gros.
La base de données client est attendue dans les O (millions) d'enregistrements. Afin de calculer certains numéros de fond de panier pour le dimensionnement de la base de données et d'évaluer les options et architectures de base de données potentielles, je recherche des normes de facto pour ce type d'enregistrements. En particulier, la taille standard de chaque champ (prénom, nom, adresse, ...) ou la moyenne typique d'un enregistrement client simple serait une excellente information .
Avec autant de sites Web de commerce électronique, il devrait y avoir une sorte de configuration typique qui peut être réutilisée et éviter de réinventer la roue.
Des idées?
---- Éditer ----
Les réponses semblent orienter vers l'adoption d'un dossier client standard par rapport à la conception du vôtre. Je voudrais souligner que l'objectif de cette question est de trouver une référence pour le dimensionnement des champs pour un objet client, et d'éviter de le découvrir par moi-même (j'ai souligné cette partie du texte original - maintenant en gras -).
Réponses:
Des choses comme celles-ci sont très spécifiques à un client et à l'industrie, tout ce qui est générique comprendra tout et l'évier de la cuisine. En particulier les formats de type EDI, ils ont été définis organiquement sur une décennie ou plus dans la plupart des cas et incluent tout ce que chaque entreprise du comité a toujours voulu. Ils étaient censés être génériques pour l'industrie, et ils sont devenus extrêmement spécifiques à l'industrie et extrêmement fragiles.
Il n'y a pas de voie royale vers le design ou les informations que vous souhaitez. Faites le temps et l'effort nécessaires pour obtenir les exigences et obtenir une estimation concrète. Sinon, vous aurez plus tort que raison. La seule façon de savoir ce que vous devez savoir est de poser les questions et de le découvrir vous-même.
De nombreux systèmes CRM utilisent ce que l'on appelle maintenant un modèle d'objet Expando, précédemment appelé modèle de propriété dynamique . Il s'agit essentiellement d'une construction de dictionnaire de paires de valeurs clés. Sauf dans des cas très particuliers, il est considéré comme un anti-motif de conception et doit être évité.
J'ai conçu et construit au moins 8 solutions CRM personnalisées au cours des 20 dernières années, chacune et chacun avait des exigences différentes et aucun des modèles de données (logiques ou physiques) n'aurait fonctionné dans tous les domaines pour tous les domaines.
Des solutions spécifiques pour des cas spécifiques seront toujours de meilleures conceptions.
la source
Il existe un thread dans la pile DBA sur les meilleures pratiques pour les champs de personne commune qui traite des problèmes. Il est important de savoir ce que vous prévoyez de faire avec les données et à quel point vous devez être approfondi. Si vous devez réellement prendre en charge toutes les adresses e-mail valides ou tous les noms valides, vos colonnes devront être beaucoup plus grandes que si vous souhaitez simplement prendre en charge tout ce que votre organisation et votre application considèrent comme un sous-ensemble raisonnable des valeurs valides.
la source
Comme l'a souligné Jarrod, si vous suivez une norme générique, vous vous retrouverez certainement avec un format d'enregistrement qui comprend beaucoup de choses dont votre système n'aura jamais besoin. Comme vous savez déjà qu'il y aura un assez grand nombre d'enregistrements, il est probable que vous rencontrerez des problèmes de performances inutiles car vous prenez en charge des données qui ne seront jamais utilisées. Inversement, il est également probable que la norme n'inclue pas les champs dont vous avez besoin, ce qui sera un problème douloureux à résoudre; soit vous cassez la norme en ajoutant ces champs, soit vous devrez trouver un moyen (probablement maladroit) d'inclure les champs non standard dans la norme.
Je pense que le vrai problème ici n'est pas de trouver une norme universelle (qui sera presque toujours une taille unique) mais que vous avez été chargé d'estimer une solution où les exigences ne sont pas spécifié encore. Dans ces cas, je pense que la seule chose professionnelle à faire est de faire une estimation minimale en fonction des exigences que vous avez, puis de faire une estimation maximale en fonction de toutes les exigences indéfinies possibles qui, selon vous, pourraient apparaître. Effectivement, l'estimation peut devenir ridiculement approximative, auquel cas vous devez expliquer à la personne qui vous a demandé cela, qu'il n'est tout simplement pas possible de faire une bonne estimation tant que les exigences ne sont pas mieux définies.
la source
Normes internationales existantes
Il existe un certain nombre de normes, mais spécifiques à certains domaines, avec des exigences variables pour chacun d'entre eux en fonction de leurs besoins de collecte de données.
Par exemple, mais sans s'y limiter (et en parlant de leur expérience avec les deux):
le domaine plus large des dossiers de santé électroniques et de leurs normes techniques
logiciel traitant des enregistrements de données d'appel des opérateurs mobiles et des enregistrements de données de service (pas exactement comme standard, mais pour l'interopérabilité entre les réseaux partenaires).
Certains des liens ci-dessus vers des documents assez détaillés, répertoriant même les exigences relatives à l'intégrité et au formatage des champs (par exemple, HL7 utilise des types de données bien définis ). Beaucoup d'entre eux n'entrent cependant pas dans ces détails.
Normes régies par le gouvernement pour les documents internes
Les gouvernements, nationaux ou locaux, ont souvent un fort besoin d'enregistrer et de stocker des informations personnelles pour les bureaux publics, et ont évidemment élaboré leurs propres "normes", qu'ils mettent en œuvre dans leurs organisations (avec différents niveaux de succès et d'interopérabilité avec les organisations partenaires) .
Un exemple pourrait être cette norme de formats de données pour les enregistrements d'identité du gouvernement de la Nouvelle-Zélande.
Normes de facto dans les logiciels
Vous pouvez vous en inspirer ou utiliser la source de logiciels CRM open source connus pour les utiliser comme meilleures pratiques et directives pour les spécifications de données de vos données client.
Consultez la liste des 10 meilleurs logiciels de gestion d'entreprise et de CRM social open source , pour laquelle vous pouvez rechercher vous-même leurs modèles de données.
la source
De-Facto Standards in Software-> très intéressé par ces derniers. Pourriez-vous ajouter quelques références?Je dirais que vous devez trouver des normes pour les systèmes EDI . Il existe des centaines de documents «standard», vous devez donc en choisir un en fonction de vos besoins. Par exemple, voici un format de facture TRADACOMS à partir duquel vous pouvez récupérer les champs de votre choix .
la source
L' Open Applications Group publie un ensemble de normes ouvertes pour la mise en œuvre et l'interopérabilité des applications. Ils sont principalement orientés XML, mais ils spécifient un enregistrement client standard avec des champs et des tailles individuels (recherchez
CustomerPartyMasterdans la liste des normes de document).la source
Je dirais: "Tu n'en auras pas encore besoin". Et avec Ron Jeffries: "Mettez toujours en œuvre les choses lorsque vous en avez réellement besoin, jamais lorsque vous prévoyez simplement que vous en avez besoin."
Alors peut-être que s'il est temps d'ajouter une base de données concrète au projet, vous avez beaucoup plus de connaissances sur les données qui y seront stockées.
la source