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 colonne ORDER_LINE_NUMBER dans la table OE_ORDER_LINES, et la clé est de manière assez évidente ORDER_LINE_ID. Inutile de se demander longtemps ce que contient une colonne CUSTOMER_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 à utiliser massivement judicieusement 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 colonne POSNR dans la table VBAP, la clé est composée de VBELN et de POSNR, et l’équivalent du dernier exemple ci-dessus est KUNNR. 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.)