Quel est le meilleur format pour un numéro de client, un numéro de commande?
Une grande entreprise internationale déploie un nouveau système de gestion Web et MOTO (Mail Order et Telephone Order). Vous êtes notamment chargé de concevoir le format des numéros de commande et d'identification du client.
Quel serait le meilleur format à votre avis? Veuillez énumérer toutes les hypothèses et considérations.
Réponse acceptée
La réponse de Michael Haren a été sélectionnée en raison du plus grand nombre de votes, mais veuillez lire les autres réponses et commentaires car ils rendent la réponse de Michael plus complète.
Allez avec tous les chiffres ou toutes les lettres. Si vous devez le mélanger, assurez-vous qu'il n'y a pas de caractères ambigus (Il1m, O0, etc.).
Lorsqu'il est affiché/imprimé, mettez des espaces dans tous les 3-4 caractères mais assurez-vous que vos systèmes peuvent gérer les entrées sans les espaces.
Edit: Une autre chose à considérer est d'avoir une manière intégrée de distinguer les commandes, les clients, etc. les clients commencent toujours par 10, les commandes commencent toujours par 20, les fournisseurs commencent toujours par 30, etc.
NE PAS encoder TOUT informations client/commande modifiables en chiffres! Et vous devez supposer que tout est mutable!
Certaines des suggestions ci-dessus incluent un code de région. Les entreprises peuvent bouger. Votre propre entreprise peut réorganiser et modifier sa propre définition des régions. Les noms des clients/sociétés peuvent également changer.
Les informations client/commande appartiennent à l'enregistrement client/commande. Pas à l'ID. Vous pouvez modifier l'enregistrement client/commande plus tard. Les identifiants sont généralement écrits dans la pierre.
Même le simple encodage de la date à laquelle le numéro a été généré dans l'ID peut sembler sûr, mais cela suppose que la date n'est jamais fausse sur les systèmes générant les numéros. Encore une fois, cela fait partie du dossier. Sinon, il ne pourra jamais être corrigé.
Est-ce que plus d'un système générera ces chiffres? Si c'est le cas, vous avez le potentiel de duplication si vous utilisez uniquement des nombres basés sur la date et/ou séquentiels.
Sans en savoir beaucoup sur l'entreprise, je commencerais dans cette voie:
- Un code à un caractère identifiant le type de numéro. C pour les clients, R pour les commandes (n'utilisez pas "O" comme il pourrait être confondu avec zéro), etc.
- Un identifiant du système qui a généré le numéro. La longueur de cet identifiant dépend du nombre de ces systèmes.
- Un numéro de séquence, unique au système qui le génère. Juste un comptoir.
- Un nombre aléatoire, pour éviter les numéros de commande/client devinables. Faites cela aussi longtemps que votre paranoïa l'exige.
- Une simple somme de contrôle. Pas pour la sécurité, mais pour la vérification des erreurs.
Le diviser en segments le rend plus lisible par l'homme, comme d'autres l'ont souligné.
CX5-0000758-82314-12 est un nombre possible généré par cette approche. Cela comprend:
- C: c'est un numéro de client.
- X5: la station qui a généré le numéro.
- 0000758: il s'agit du 758ème numéro généré par X5. Nous pouvons générer 10 millions avant de retirer cet ID de station ou la station elle-même. Ou ne remplissez pas de zéros et il n'y a pas de limite.
- 82314: cela a été généré de manière aléatoire et entraîne une chance sur 1/100 000 de deviner un identifiant client.
- 12: somme de contrôle.
L'un des principaux avantages de n'utiliser que des chiffres est qu'ils peuvent être entrés beaucoup plus efficacement à l'aide de 10 touches.
La longueur de ce nombre doit être aussi courte que possible tout en englobant tout l'espace de l'entité que vous prévoyez de cataloguer avec de la place à épargner. Cela peut être délicat et devrait être réfléchi. Un peu théorie des ensembles peut vous donner le nombre de clés uniques auxquelles vous aurez accès, compte tenu d'un groupe d'éléments.
Il est naturel de parler en décomposant les nombres en ensembles de deux à quatre chiffres. En insérant des tirets dans un certain modèle, vous pouvez "forcer" le client à les répéter de manière plus efficace et sans ambiguïté.
Par exemple, le 323-23-5344, qui, bien sûr, est un format de numéro de sécurité sociale, aide à indiquer au locuteur où s'arrêter lors de la vocalisation du numéro. Il fournit également une délimitation visuelle lors de l'écriture du numéro et facilite la comparaison lors de la copie du numéro.
J'appuie la recommandation selon laquelle le système de commande masque correctement l'entrée afin qu'aucun tiret ne doive être saisi à tout moment. Ceci devrait être appliqué aux formulaires imprimés pour fournir une attente claire de ce qui doit être entré. Par exemple, une boîte imprimée pour chaque chiffre séparé par des tirets imprimés.
Je ne suis pas d'accord sur le fait que trop d'informations devraient être intégrées dans ce nombre, surtout si ces attributs peuvent changer. Par exemple, disons que nous donnons à "323" le sens de "est un client agréable", mais ils appellent quatre fois avec une attitude. Allons-nous alors changer leur clé client en "324", "est un con"? Et s'ils se trouvent dans la région 04 et déplacent leur entreprise dans la région 05?
Si cela se produit, vos options seront de mettre à jour cette clé primaire dans la base de données ou de vivre avec l'ambiguïté que les informations incorporées dans cette clé ne sont plus fiables, rendant ainsi toutes les informations incorporées dans les clés de l'utilité douteuse.
Il est préférable de stocker les attributs qui peuvent changer en tant que champs séparés dans la base de données et que le numéro de client soit une clé unique et immuable pour ce client.
Pour s'appuyer sur les questions de Daniel et Michael: c'est encore mieux si les nombres séparés SIGNIFIENT autre chose. Par exemple, j'ai travaillé pour une entreprise où les numéros de compte étaient comme ceci:
xxxx-xxxx-xxxxxxxx
Le premier ensemble de chiffres représentait la région et le second ensemble représentait le marché dans cette région. Une fois que vous vous êtes habitué à savoir d'où venaient les chiffres, il était très facile de savoir dans quelle zone se trouvait un compte sans même avoir à consulter le compte du client.
Il y a plusieurs hypothèses que je fais en répondant à cette question; certains sont basés sur le fait qu'il s'agit d'une grande organisation internationale, et certains sont basés sur le fait que le format est pour deux types de tableaux distincts.
Hypothèses basées sur le fait qu'il s'agit d'une organisation internationale:
- Il est probable que chaque région devra fonctionner de manière indépendante - c'est-à-dire que la région A doit pouvoir ajouter des numéros de client indépendamment de la région B
- Chaque région utilise probablement une langue différente.Pour que les identifiants puissent être facilement saisis par les utilisateurs du monde entier, il est préférable de s'en tenir uniquement aux nombres et aux espaces.
Hypothèses basées sur le fait qu'il existe deux tableaux pour lesquels ce format sera utilisé:
- Ce format peut être utilisé par plus des deux tables répertoriées, il doit donc être capable de gérer un nombre arbitrairement élevé de tables.
- Les utilisateurs expérimentés devraient être en mesure de savoir quel type d'identifiant ils recherchent en fonction des informations encodées dans l'identifiant lui-même.
- Ce serait bien si les identifiants étaient globalement uniques dans l'ensemble du système.
Considérations:
- Pour une entreprise mondiale, les identifiants peuvent être très longs si seuls des chiffres sont utilisés. Nous devons essayer de limiter autant que possible la quantité d'informations superflues encodées dans l'identifiant.
- Les identifiants devraient être auto-vérifiables dans une mesure limitée; c'est-à-dire qu'un programme devrait être capable de détecter un grand pourcentage d'identifiants invalides sans rien chercher du tout. Cela implique une somme de contrôle.
Format proposé: SSSS0RR0TTC
Le format proposé est aussi simple que possible, mais pas plus simple:
- C Le premier caractère (le plus à droite) sera une somme de contrôle de tous les autres caractères de l'identifiant. Une simple somme de contrôle suffira. Cela éliminera 90% de toutes les erreurs de frappe. S'il est décidé que cela ne suffit pas, cela peut être étendu à 2 chiffres, ce qui éliminera 99% de toutes les erreurs de frappe.
- TT Les N chiffres suivants représentent le numéro du type de table. Aucun numéro de type de table ne peut contenir le chiffre zéro.
- Le chiffre suivant est un zéro. Ce zéro sépare le numéro de type de table du numéro de région.
- RR Les N chiffres suivants sont le numéro de région. Aucun numéro de région ne peut contenir un zéro.
- Le chiffre suivant est un zéro. Ce zéro sépare la région du numéro de séquence.
- SSSS Les N chiffres suivants sont le numéro de séquence. Ce nombre peut contenir des zéros.
- Chaque ensemble de quatre nombres est séparé par des espaces lorsqu'il est imprimé ou tapé par convention. En interne, ils ne sont pas séparés, mais cela aide l'utilisateur à les transférer correctement.
Exemples
En supposant:
- Type de table client = 1
- Type de table de table de commande = 2
- Code de région pour les États-Unis-Alabama = 1
- Code de région pour CA-Alberta = 43
- Code de région pour Ethopia = 924
- 10 1013 - Client n ° 1 en Alabama (3 est la somme de contrôle: 1 +1 + 1)
- 10 1024 - Commande n ° 1 en Alabama
- 9259 0304 3016 - client # 925903 en Alberta, Canada
- 20 3043 4092 4023 - numéro de commande 2030434 dans Ethopia
Avantages de cette approche:
- 90% des numéros mal saisis seront capturés
- Il existe un nombre illimité de types de tables
- Il y a un nombre illimité de régions
- Il y a un nombre illimité de numéros séquentiels pour chaque table
- Les numéros d'identification sont globalement uniques au système. Ceci est important - un numéro de client ne peut pas être confondu avec un numéro de commande et vice versa.
- Chaque région peut ajouter indépendamment des numéros de séquence sans clé globale
Inconvénients
- Chaque identifiant comporte au moins six caractères
- les numéros de types de table et les numéros de région ne peuvent pas contenir de zéro car le zéro est utilisé pour séparer le numéro de séquence du numéro de région du numéro de type de table.
Je voudrais jamais utiliser les informations utilisateur dans les identifiants. Supposons que vous utilisiez les premières lettres du nom de famille du client suivies d'un certain nombre: par ex. Thomsom pourrait être le client THOM-0001. Seulement, il semble que vous ayez fait une erreur, et le nom de l'homme est Tomson au lieu de Thomson. Les données utilisateur peuvent être corrigées, les identifiants ne doivent jamais être modifiables. La prochaine fois que vous rechercherez Tomson sous TOMS -... vous ne le trouverez pas. Même chose avec d'autres données, comme un type de client. Cela peut toujours changer, l'ID ne peut pas.
Ceci est très basique pour le SGBDR.
Utilisez simplement des nombres de comptage. Pour plus de lisibilité, il est judicieux d'insérer des séparateurs de sorte que vous n'ayez jamais plus de 4 chiffres successifs: 9999-9999 est meilleur que 999-99999. Et ne faites pas le nombre plus long que nécessaire; les gens sont beaucoup plus ennuyés d'être réduits à un nombre à 20 chiffres que d'être simplement réduits à un nombre.
Mais il y a un hic. Surtout si vous avez une petite entreprise, les comptoirs simples peuvent donner plus que vous ne le souhaiteriez. Disons que je vous commande quelque chose et que le numéro de commande est 090145. Le mois prochain, je commande à nouveau et que le numéro de commande est 090171. Euh. 26 commandes en un mois? Idem, je ne me sentirais pas à l'aise de devenir le client 0006 dans une entreprise active depuis 10 ans.
La solution est simple: sauter les numéros. N'utilisez pas de nombres aléatoires, car vous voulez toujours qu'ils soient en séquence.
Faites le numéro aussi longtemps que nécessaire, mais pas plus longtemps. Chaque fois que je paie ma facture d'eau, je dois entrer mon numéro de client à 20 chiffres et un numéro de facture à 18 chiffres. Heureusement, un tiret dans mon numéro de client le sépare en deux parties.
Ne dépendez pas des zéros non significatifs. Devoir comprendre combien de zéros sont dans mon numéro de facture est extrêmement ennuyeux. Prenez par exemple 000000000051415432. Leur système ne reconnaîtra pas seulement 51415432.
Regrouper les chiffres. Si vous devez absolument utiliser des nombres longs, les blocs à quatre chiffres devraient bien fonctionner.
Je voudrais que mes numéros de commande suivent ce format:
ddmmyyyy-####-####
Où #### - #### est remis à zéro au début de chaque journée. Il est ainsi très facile de corréler les commandes avec la date à laquelle elles ont été passées.
Pour les identifiants clients, je mélangerais les majuscules et les chiffres, mais comme Michael l'a dit, évitez les lettres souvent erronées (0, o, L, 1,5, s). Cela vous donnera 30 caractères à gérer. Si vous utilisez 20 caractères, cela vous donnera une plage d'ID client de presque 64 bits - assez bonne pour la sécurité. Assurez-vous d'utiliser un générateur de nombres aléatoires sécurisé lors de la génération de l'ID. Quant à la façon dont vous affichez le format, il devrait être le suivant:
####-####-####-####-####
Comme l'a répété Michael, assurez-vous que votre système peut gérer les tirets, les espaces, aucun espace ou aucun tiret. (Il devrait simplement supprimer tous ces caractères de l'entrée avant la validation.)
J'espère que ça aide!
Vous pouvez ajouter une petite somme de contrôle (en utilisant XOR par exemple) pour assurer (améliorer) l'exactitude des identifiants donnés. Si c'est par courrier, pensez à l'encodage z-base-32 Mais ici, avec les commandes téléphoniques, vous pouvez préférer une identification décimale.
Nous utilisons des zéros non significatifs pour certaines de nos références "nombres" où je travaille et je ne peux pas vous dire combien d'heures perdues j'ai eu au cours des sept dernières années, forçant Excel à les traiter comme du texte. Ne le fais pas.
Les nombres entiers à incrémentation automatique conviennent parfaitement aux ordinateurs, mais ils réduisent considérablement la capacité des êtres humains à détecter les erreurs. L'importance de cela dépendra de votre entreprise. Je travaille avec des données liées à la propriété (logement) et notre référence principale a la porte d'entrée intégrée. Ce n'est pas élégant, mais cela signifie que le personnel administratif expérimenté peut détecter 90% des erreurs mineures (lorsque nous recevons des factures, etc.) avant de s'approcher d'une base de données. Mais dans un environnement où vous ne comptez pas sur ce type de processus, cet argument est moins convaincant.
(Maintenant, certaines personnes ont fortement mis en garde contre l'utilisation de données significatives dans les références car elles pourraient être modifiées, et il y a du vrai là-dedans, mais vous pouvez être intelligent. Vous n'avez pas à choisir quelque chose d'évident, comme si la personne est mariée - vous pouvez vous ancrer sur des événements passés comme un personnage représentant la région où ils ont ouvert un compte en particulier. Même si vous ne le faites pas, ayez une sorte de modèle pour faciliter la communication avec les clients. J'ai travaillé dans un certain nombre de centres d'appels et les gens viennent parfois au téléphone avec tous les documents à partir du certificat de naissance car ils essaient désespérément de trouver leur compte/commande/numéro de client. Je ne pense pas que dire "ce sera un nombre entre 1 et 100 billions" serait très utile)
Cela a été dit, mais ne créez pas de références extrêmement longues. Nous sommes des gens occupés, nous n'avons pas eu le temps de saisir cette merde sur un système téléphonique et de faire une erreur sur le chiffre 17 pour redémarrer (à nouveau). Certains de vos clients peuvent avoir un handicap et il est probable qu'un nombre croissant dépassera 55 ans et plus. Encore une fois, faites attention aux zéros. Vous voyez les numéros des bons de commande et autres avec quatorze chiffres. Combien de commandes pensent-ils qu'ils vont passer?
S'il doit y avoir une agrégation de données en dehors de votre réseau (et donc pas connecté à votre base de données) - ayez une sorte de modèle de chiffre de contrôle/d'expression régulière que vos partenaires/fournisseurs peuvent vérifier qu'ils n'ont pas commis d'erreurs. Un exemple de ceci est le système de numérotation de l'alimentation électrique (MPAN) du Royaume-Uni en est un bon exemple - conçu pour que les gens conservent leurs propres enregistrements sans avoir à télécharger la grande liste de chaque compteur d'électricité de l'univers pour vérifier qu'ils n'ont pas fait une faute de frappe.
en supposant que la création de commandes/clients n'est pas centralisée, ou ne sera pas toujours centralisée, utilisez un GUID
si la création de commandes/clients sera toujours centralisée, un entier non signé conviendrait
il n'y a aucune raison impérieuse pour que le numéro de commande du numéro de client "signifie" quoi que ce soit, et il est probable que tout schéma de numéros segmenté inventé devra être révisé en cours de route. Tenez-vous à quelque chose d'unique et de vide de sens.
EDIT: pour MOTO, tout identificateur alphabétique à plusieurs caractères causera des problèmes par téléphone, les GUID sont donc immédiatement sortis. En supposant plusieurs emplacements MOTO décentralisés, attribuez à chaque emplacement MOTO un préfixe (A, B, C, etc., ou 01, 02, ...) et utilisez un entier ou un grand entier pour le client et les ID de commande, par ex. 01-1 est la première commande de l'emplacement MOTO # 1. Notez que le remplissage nul n'est pas nécessaire, impose une limite de chiffres implicite aux nombres et oblige le client à distinguer entre six zéros et sept zéros lorsqu'il prononce le nombre. Si vous devez utiliser un format matelassé de longueur fixe, divisez le nombre en groupes de 4 ou 5 chiffres chacun au maximum.
ADDENDUM: le numéro de commande et le numéro de client n'ont pas à être les clés primaires de leurs tables respectives, juste des colonnes indexées uniques pour la recherche. Vous voudrez probablement utiliser quelque chose de plus simple/plus efficace pour les clés primaires de la base de données.
Respectez les chiffres (pas de caractères ni de trucs spéciaux):
- Peut être facilement entré dans un flux IVR
- son international - Pas de soucis de langue
- Aucune confusion entre les caractères et les nombres - O contre 0, I contre 1
- Tant que l'interligne 0 n'a pas de sens, vous pouvez les stocker/les manipuler plus efficacement
J'utiliserais des chiffres uniquement car c'est une entreprise internationale. J'utiliserais des espaces ou des tirets tous les 4-6 numéros pour le séparer. Je garderais également le format séparé pour une identification rapide
Exemple:
000-00000-00000 - pourrait être un numéro de client
00000-00000-00000-00000 - pourrait être un numéro de commande
Je suggère d'utiliser des identifiants à 16 chiffres qui, lorsqu'ils sont imprimés ou montrés aux clients, sont formatés au format xxxx-xxxx-xxxx-xxxx mais stockés sous forme de nombres sans les tirets dans votre système.
La raison d'utiliser ce format est qu'il facilite la lecture du numéro par téléphone car il peut le faire par lots de 4 plutôt que d'essayer de se souvenir de ce qu'il a déjà dit.
Si vous le souhaitez, les 4 premiers chiffres peuvent être utilisés pour identifier le type de numéro, 1000 pour les clients, 2000 pour les fournisseurs, 3000 pour les commandes, 4000 pour les factures, etc.
Le deuxième ensemble peut alors être identifié par un identifiant année/mois si vous souhaitez conserver ce type d'informations encodées dans le numéro lui-même, en utilisant un format yymm, de sorte que 1000-0903-xxxx-xxxx serait un client entré en mars 2009.
Cela vous laisse alors avec 8 chiffres pour les données réelles elles-mêmes.
Je considérerais l'utilisation de lettres dans les identifiants comme une très mauvaise idée pour tout système qui traite les téléphones, car les différences d'accents et de compréhension sont si variées que les gens sont vexés de vouloir faire reconnaître leur identifiant par quelqu'un qui ne peut pas comprendre correctement leur accent.
J'utiliserais un système entièrement numérique pour le numéro de commande et le numéro de client, cela vous permettra d'éviter les problèmes avec d'autres langues.
Évitez les zéros non significatifs, car cela peut entraîner des problèmes de saisie et de validation des données.
Le nombre de chiffres pour chacun dépendra de votre volume attendu. Vous aurez toujours un plus grand nombre de numéros de commande que de numéros de client. Un numéro de client à six chiffres commençant à 100 000 vous donnera toujours 899 999 clients. Ajoutez 3 à 4 chiffres supplémentaires pour le numéro de commande, vous obtiendrez 999 à 9 999 commandes par client (plus si vous considérez un client unique).
Il n'est pas nécessaire de créer une sorte d'identification dans votre séquence de numérotation. Vous avez d'autres champs de base de données pour identifier d'où vient un client, etc. Ne compliquez pas trop votre système.
KISS (garder le stackoverflow simple)
Une considération supplémentaire au problème de format - dans le code, créez une classe distincte pour OrderId et CustomerId. Ces classes sont immuables et valident leur entrée pour s'assurer qu'elles sont des identifiants acceptables. De plus, aucune valeur ne peut être et un ID de commande et un ID client.
L'approche la plus simple consisterait simplement à ce que les valeurs de support pour OrderId soient des entiers commençant par 1, et CustomerIds des entiers commençant par 2, ou quelque chose de similaire.
Je m'en tiens toujours aux nombres à incrémentation automatique, et je sème toujours la séquence suffisamment haut pour qu'ils aient tous un nombre cohérent de chiffres - semble être moins déroutant.
Je lance également parfois un numéro de commande, disons 6 chiffres, à partir de 200 000 et des numéros de client à 5 chiffres, à partir de 10 000, ce qui me donnerait par exemple 90 000 numéros de client uniques et 800 000 numéros de commande uniques à utiliser, et vous pourriez toujours le dire simplement en regarder si c'était un numéro de client ou un numéro de commande. (c'est-à-dire que si un représentant du client demandait un numéro par téléphone, il serait immédiatement évident de savoir lequel)
Cependant, je ne construirais pas de logique dans l'application qui dépendrait de cela, donc même si elle se retournait, le système s'en ficherait.
Pour moi, mon préféré est d'obtenir la combinaison de date + un compteur pour la transaction d'aujourd'hui. J'ai été mis au défi de proposer uniquement un numéro de commande à 5 chiffres. Donc, avec cela, je viens avec ce qui suit ci-dessous:
- Je dois alors obtenir la date actuelle
- obtenir le compteur actuel de la transaction d'aujourd'hui, puis ajouter 1.
J'ai décidé d'utiliser un comptage plus grand que décimal (10), donc j'utilise la base 16 pour le comptage. Donc, avec cela, si j'obtiens le maximum de 5 chiffres en hexadécimal (FFFFF), ce sera 1048575 comptes. En impliquant la date, je peux dire que je peux obtenir 1 048 575 chefs d'accusation par jour. Donc, pour rendre ce compte unique chaque jour, j'ai mélangé la date en obtenant la somme des éléments suivants:
- Décompte de l'année en cours à partir de l'année de mise en œuvre qui est 1
- Heure actuelle (max 24)
- Jour de l'année en cours (max 365)
Donc, avec cela, je vais commencer un maximum de 3 caractères pour mon comptage. Ce sera donc la transaction actuelle de XXX + Todays. Exemple:
Date actuelle: 31/12/2014 01:22 PM Date de mise en œuvre: 2010 Total cumulé pour la transaction d'aujourd'hui: 100
Nombre: (5 + 13 + 365) + 101 = 383101 Numéro de commande: AD-5D87D
ANNONCE il n'y a qu'un préfixe de numéro de commande personnalisé. Donc, au moment où je serai en panne, ce sera 1000000 ans à compter de la date de ma mise en œuvre.
Quoi qu'il en soit, ce n'est pas une bonne solution si vous pensez que votre transaction par jour peut être élevée car 1000000 compte.
Wow - quelle question simple mais révélatrice! Et quelles réponses contradictoires. Je pense qu'il y a 3 réponses évidentes de candidats ici:
1) Utilisez un entier long à auto-incrémentation. 2) Utilisez un GUID 3) Utilisez un type composé qui inclut d'autres informations dans l'ID.
Pour les systèmes plus simples, et en particulier les systèmes basés sur le Web où tous les utilisateurs accèdent à une base de données centrale, (1) fonctionne bien. Il a l'avantage que les chiffres restent aussi courts et simples que possible, mais pas plus courts, évite les caractères alphabétiques (vous seriez étonné de voir à quel point les noms des mêmes lettres sont différents dans différents pays - un pays E est un autre pays I). Cela ne différencie pas intrinsèquement l'ID de commande de l'ID client, mais vous pouvez toujours ajouter ou ajouter un "C" ou un "O" à chacun et les déposer silencieusement à l'entrée? Il n'a pas non plus de somme de contrôle ni de vérification d'erreur.
Pour les systèmes distribués où de nombreux composants logiciels doivent créer des nombres à la volée, sans référence à une base de données master (2) est la seule solution. Ils ont l'avantage de contrôler largement les erreurs, car l'espace d'adressage est si grand, mais du même coup, il est trop long et alphanumérique pour être lu confortablement par téléphone.
En ce qui concerne (3) - l'intégration d'informations sur la région ou la date d'aujourd'hui dans le nombre - ce sont les types d'idées dont les développeurs expérimentés se forment. Cela semble être une bonne idée au début, mais revient toujours vous hanter. Considérez le cas où un client passe à un nouvel état, ou une commande est retapée manuellement une semaine après l'émission initiale? Ces informations appartiennent à des tableaux associés où elles peuvent être modifiées indépendamment de l'ID, qui ne doit représenter que l'identité des entités. Pour répéter: NE JAMAIS ENCODER LES DONNÉES D'AFFAIRES DANS UN ID OR CLÉ PRIMAIRE - chaque fois que vous faites cela, vous laissez une bombe à retardement pour que d'autres nettoient un jour.
Étant donné qu'il s'agit d'un système centralisé (basé sur le téléphone), j'irais avec l'option (1) jusqu'à ce qu'un besoin clair se fasse sentir. Plus simple est généralement meilleur. Insérez des tirets comme d'autres suggèrent et ajoutez ou postpendez une somme de contrôle et/ou une lettre d'identification si nécessaire.
Le plus gros problème ici est d'essayer de ne pas trop penser au problème.
Bien que je sois plus expérimenté dans les systèmes de commerce électronique, je pense que certains des points soulevés dans ce message pourraient être appliqués aux systèmes de vente par correspondance et par téléphone.
Pour les commandes, un entier à incrémentation automatique fonctionne parfaitement comme clé primaire dans la base de données ainsi que le numéro que le client verra sur sa facture. Il n'y a absolument aucune raison de créer un algorithme trop compliqué pour vos numéros. Si vous souhaitez savoir de quel pays/région ils proviennent, utilisez un champ séparé dans votre base de données. Aussi si vous êtes préoccupé par le fait que vos concurrents vous espionnent; laisse les! Si votre entreprise consiste à espionner vos concurrents parce que vous ne générez pas suffisamment de revenus, votre idée commerciale n'est probablement pas bonne en premier lieu. De plus, si vous voulez duper votre concurrent, vous pouvez simplement créer votre propre script qui créera automatiquement de fausses commandes. Si votre système de commerce électronique est bien conçu, ce ne sera pas un problème.
Trucs clés utilisant un entier à incrémentation automatique:
- Tous les nombres/chiffres => plus facile à communiquer, pas d'ambiguïtés par téléphone, fonctionne pour toutes les langues/cultures qui utilisent 0-9 comme système numérique
- Pas de codage supplémentaire
- Est joli sur la facture et c'est le nombre de chiffres le plus court possible qu'un client aurait besoin de préciser par téléphone
- Fonctionne pour les petites et grandes entreprises
- C'est évolutif
- Serviceminded/Customerminded (Quoi de mieux pour le client) (voir les puces 1 et 3)
- Facile
Chaque fois que vous concevez, vous devez toujours commencer par ce qui est le mieux pour le client. À la fin de la journée, ce sont eux qui mettent de la nourriture sur votre table. Un client satisfait est un client fidèle.
Première étape: dans une organisation suffisamment grande pour nécessiter un tel système, il existe un système existant que vous remplacez. Si possible, poursuivez le schéma du système précédent. Cela facilite beaucoup de choses si vous pouvez accéder, même à un niveau de base, aux données de l'ancien système.
Cela dit, il y a souvent une bonne raison de modifier le schéma, en particulier lorsqu'il provient d'un système hérité. je trouve cependant qu'il est souvent utile d'exclure formellement l'ancien régime avant de poursuivre.
Deuxième étape: des systèmes comme celui-ci n'existent jamais dans le vide. Existe-t-il déjà un schéma à l'échelle de l'organisation pour les ID utilisateur et/ou de commande, comme dans la comptabilité, la gestion des stocks ou le système CRM? Dans l'affirmative, envisagez d'adopter les schémas existants pour faciliter l'interopérabilité. De nombreuses grandes organisations ont plusieurs façons de spécifier un seul client ou une seule commande, ce qui rend plus difficile l'obtention d'informations utiles sur les données.
Troisième étape: si le schéma de l'ancien système est trop affreux pour continuer et qu'il n'y a pas d'autre schéma à adopter, lancez le vôtre. Dans ce cas, examinez les lacunes du schéma d'origine, quelles qu'elles soient, et corrigez-les. La bonne réponse dépendra des exigences spécifiques de l'application. L'énoncé du problème que vous nous avez donné est trop vague pour spéculer utilement sur ce à quoi pourrait ressembler le formulaire final.