Le portail francophone de la géomatique

Pas d'idée...

à l'origine, il doit y avoir des contraintes de taille mémoire en informatique, largement dépassées dans les systèmes actuels. Surtout dans des bases de données "objets", avec des héritages divers de diverses propriétés en cascade dont certains informaticiens sont friands.

ça se faisait même sur cartes perforées, donc la contrainte de largeur du nombre était très forte alors...
https://fr.wikipedia.org/wiki/Num%C3%A9 … Historique

Je ne sais pas si les codes des bibliothécaires peuvent vous inspirer quelque idée, ou non... Là, il s'agit plutôt de subdivisions en cascade, sans longueur uniforme...
Code Dewey
https://fr.wikipedia.org/wiki/Classific … uccessives


Dans votre cas présent à vous, certains codes seront-ils saisis sur des cahiers papiers ?
Ou tout le temps via une interface logicielle ?

à la main, il y a le risque d'oublier un ou plusieurs caractères en notant ou en reportant un identifiant...

à noter que dans le numéro INSEE, ou dans un code de RIB ou IBAN, il y a une clé de contrôle pour vérifier le bon report d'un identifiant lors d'une nouvelle saisie par un opérateur humain.

Dans une IHM, ça sera transparent pour l'utilisateur si la saisie se fait par des menus déroulants, le code étant "caché" à l'utilisateur final.

Et, enfin, ça risque de se compliquer quand vous avez à échanger / mutualiser / partager vos données avec plusieurs organismes différents...

Merci Pascal.
l'équipement représente la table mère d'un point de vue MCD. Cet équipement relie plusieurs services entre eux (exploitation, clientèle, compta,..).
Le code est le résultat d'une concaténation de codes de zones non administratives.

Le code est encore noté sur des cahiers papiers mais aussi dans des interfaces logiciels.

L'harmonisation de la codification de ces entités affectent donc plusieurs services mais aussi le lien avec les plans de récolement. Raison pour laquelle je cherche à uniformiser en réorganisant les caractères de l'ancien code.

Mis à part le coté mnémotechnique du code, il me semblait que les cours de base de données insistaient sur la nécessité d'avoir une longueur similaire d'un point de vue occupation en espace sur disque ou réseau. Dans mon cas le nombre est faible certes mais il y a 1000 entités à 6 digits puis 800 à 7 digits puis 200 à 8 digits, ce qui fait que l'on stocke des places vides de 1 à 2 digits pour au moins la moitié des entités. Je pensais également à la facilité de tri de ces entités et aux requêtes.

Bonjour,

C'est un choix possible mais risqué. Lorsque ces codes varient ou sont susceptibles de varier au cours du temps l'idée est d'utiliser une clef artificielle.
Un exemple, j'ai un objet "COMMUNE" qui a différents attributs (code département,Code insee, nom, taille, population, surface, géométrie ...) je peux parfaitement créer une clef basée sur la concaténation du code département et du code insee, mais si demain la commune fusionne avec une autre Aïe !!

L'autre solution consiste à ajouter un attribut artificiel nommé idcommune qui est une valeur numérique entière unique. Cette clef garantit l'unicité de l'objet indépendamment de la valeur de ses attributs. La commune de TRUC (idcommune=3724,codedep=28,insee=320,'TRUC' etc..) est la même commune que MACHIN (idcommune=3724,codedep=28,insee=460, 'MACHIN').

Bonjour

Bon " " c'est mieux que "0" si les codeurs initiaux n'avaient pas laissez place à l'espace dans leur code (vieille habitude héritée des lignes de commandes);
ou on utilise la fonction TRIM(machaine), qui supprime les espaces, comme cela, en combinaison avec LENGTH(machaine) on fait à peu près ce que l'on veut et on optimise le stockage.
C'est pas à Mr Quest que je vais apprendre que gérer des data à l'échelle d'un pays ça fait quand même son poids.