Normes de facto pour l'enregistrement des informations client [clôturé]


17

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


1
J'aimerais aussi voir des informations à ce sujet. Mais je n'ai jamais rien trouvé de tel non plus. Ce qui serait intéressant, c'est que quelqu'un fasse une étude de cas à ce sujet en consultant des projets open source.
programmeur

2
dommage que vous ayez des votes négatifs pour ce qui est vraiment une bonne question sur le «professionnalisme» des logiciels en ne réinventant pas votre propre format d'enregistrement.
gbjbaanb

Man, je souhaite qu'il y ait une sorte de cohérence dans ce domaine. J'ai importé des bases de données clients à partir d'un bon nombre de systèmes, et elles sont partout sur la carte.
TehShrike

prévoyez-vous de stocker des informations sur le numéro de téléphone, l'adresse, etc. pour un seul pays en particulier? Cela peut faire une différence dans la taille dont vous avez besoin.
HLGEM

Réponses:


16

Ce qui est bien avec les normes, c'est que vous avez tellement de choix. - Andrew Stuart Tanenbaum

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.


J'aimerais pouvoir +2 pour la dernière phrase!
Maxpm

Merci. Je suis d'accord avec la plupart de vos points et je fonderais certainement une conception sur une phase d'exigence appropriée. Cela dit, pour les calculs de type enveloppe, j'apprécierais certainement les valeurs par défaut sensibles qui pourraient être tirées d'une norme de facto raisonnable, donc pas une norme comme les formats EDI, mais plutôt quelque chose que les gens utilisent d'une manière très répandue. De cette façon, je pourrais assembler mon objet client et obtenir un chiffre approximatif sur la taille record.
maasg

Mon point est raté, tout ce qui est utilisé de façon généralisée va être beaucoup trop large et généralisé pour être utile. Il sera gonflé et trop compliqué. C'est là que SAP, PeopleSoft et Salesforce gagnent de l'argent. Leurs produits sont généralisés à tel point que vous devez payer des consultants à prix élevé pour les personnaliser en fonction des besoins de votre entreprise. Habituellement, cela coûte plusieurs fois ce qu'une solution personnalisée simple coûterait à développer et à maintenir. Et ils gagnent leur argent en allant après le travail , avec des mises à niveau incompatibles constantes et similaires.

4

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.


C'est le plus près que je suis venu à une réponse à ma question. Ces directives sont assez bonnes, bien qu’elles ne soient ni complètes ni concrètes, mais définitivement dans le bon esprit.
maasg

3

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.


1

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

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.


De-Facto Standards in Software-> très intéressé par ces derniers. Pourriez-vous ajouter quelques références?
maasg

Downvoters, veuillez expliquer (il y en avait 2 tout à l'heure).
haylem

0

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 .


0

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


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.