Un problème récurrent quand on se balade dans un modèle de données d’une base pas connue est de comprendre rapidement quelle colonne pointe sur quoi (organisation) et ce que signifie la donnée (sens). Je parle là de lisibilité , au sens du développeur, qui rend rapide la compréhension d’un programme, et sa modification.
J’avais vu jusque récemment deux techniques habitudes cultures principales (parmi ce qui est plus ou moins correctement conçu, je laisse les gadgets Access bricolés de côté) :
- Le schéma aux noms de tables à rallonge, avec des noms de champs à rallonge.
Cas typique : Oracle Applications. On sait tout de suite ce que contient la colonneORDER_LINE_NUMBER
dans la tableOE_ORDER_LINES
, et la clé est de manière assez évidenteORDER_LINE_ID
. Inutile de se demander longtemps ce que contient une colonneCUSTOMER_ID
(pour un anglophone du moins) (quoique la notion de client soit parfois assez subtile...).
Avantage : la lisibilité, la facilité de compréhension immédiate, au moins dans les grandes lignes.
Inconvénient : des requêtes à rallonge, longues à taper, du code peu compact sauf à utilisermassivementjudicieusement des alias.
- Le schéma aux noms courts, assez cryptiques en fait.
Le pire exemple est SAP, avec ses noms de table à 4 lettres, aux noms de champs à peine plus longs. L’équivalent de l’exemple ci-dessus est la colonnePOSNR
dans la tableVBAP
, la clé est composée deVBELN
et dePOSNR
, et l’équivalent du dernier exemple ci-dessus estKUNNR
. Oui, c’est de l’allemand, en plus.
Avantage : du code compact et rapide à lire... si on connaît par cœur le modèle de données.
Inconvénient : la moindre nouvelle table ou colonne rencontrée force à se reporter à la doc, et la mémorisation est un cauchemar.
(J’ai déjà parlé de la différence entre les modèles de SAP et d’Oracle sur le plan philosophico-technique, ce n’est pas le sujet ici.)
J’ai récemment découvert, dans un logiciel qui n’a rien à voir avec un ERP, une troisième technique, proche de la seconde mais qui ne me donne pas immédiatement de l’urticaire, elle. Les principes sont :
- les noms de tables sont très courts, 4 lettres (ça c’est le point négatif) ;
- les noms de colonnes commencent par le nom de la table dont ils sont la clé !
Exemple : Un « code de collectivité » est défini dans la table COLL
et le champ COD
: la colonne sera en fait COLLCOD
, clé primaire. (Le fait que ce soit, là, du français, facilite la mémorisation :-). Idem pour la colonne OPEGANN
: une année (budgétaire) référencée dans OPEG
.
Le plus intéressant est que si ce code est repris dans une autre table comme clé étrangère, je n’ai pas à me casser le crâne à me demander « mais où BUPRNUMINT
pointe-t-il ? à quelle table BUDGEXE
fait-il référence ? » — chose parfois difficile avec les deux normes ci-dessus (et non, les modèles ne sont pas contraints, le prix en performance et administration est bien trop lourd pour un ERP, et/ou n’était pas prévu dans les softs les plus anciens).
Et quand on bosse dans la décisionnel et les ETL, ou dans l’intégration de données, où toutes les incohérences de données remontent comme le gaz carbonique dans une bouteille de champagne après un tour en centrifugeuse, ce genre de gadget est pain béni :-)
(Soyons lucide, il est impossible de généraliser cette astuce au-delà de quelques dizaines de tables, 4 lettres ne suffisent plus, on doit recourir aux soulignés (_
) et la lisibilité s’effondre.)
Derniers commentaires