Discussion :

[SQLpro]

Nous ne nous comprenons décidemment pas,

La norme que vous proposez est effectivement de grande qualité, mais l'appliquer dans une entreprise où il a déjà des centaines, des milliers de tables installées en production est chose impossible.

Je n'ai pas dit qu'il fallait l'utiliser sur une base existante. D'ailleurs la question initiale porte sur le nommage des tables d'un nouveau projet et non sur un projet existant avec déjà des tables en prod !!!! En sus elle n'aurait aucun intérêt dans ce cas précis.

Relisez-moi !

A +

[François DORIN]

Je n'ai pas dit qu'il fallait l'utiliser sur une base existante.
Relisez-moi !

Justement, je pense que la source d'incompréhension est là. Pour ma part, j'ai interprété ton "maintenant j'impose ma façon de faire sinon je me casse... " comme l'application de ces conventions même sur des projets existants. Maintenant, je comprends beaucoup mieux ton point de vue

[escartefigue]

Sans doute, mais dans une entreprise, il y a le plus souvent une et une seule norme pour une plate forme (une norme pour le distribué et une pour le mainframe par exemple).
Il arrive parfois, rarement, que les normes évoluent.

J'ai connu des refontes complètes de normes, à chaque fois c'était à l'occasion de refonte du S.I. (migration, downsizing ...), dans les autres cas, seules des modifications légères des normes sont effectuées

[SQLpro]

Une norme qui n'évolue pas est assurée d'une mort certaine. Un petit exemple, j'ai récemment vue une norme d'entreprise ou celle-ci spécifiait que les jointures devait se faire dans le WHERE (pas de JOIN) et en faisant un retour à la ligne pour chaque table dans la clause FROM... évidemment écrite dans les années 80.
Comme le nouveau projet passait d'Oracle à SQL Server (réduction de coût) je leur ait dit que nous devions donc faire les jointures externes à coup de UNION ALL et autres lourdeurs improductives et anti performantes !
Et je les aient priés de bien vouloir commencer par rectifier leur norme... Puis il a fallut intégrer l'opérateur APPLY qu'ils n'avaient pas encore vus et au final l'écriture de CTE (quels noms pour les CTE ?). EN définitive je leur ais soumis mon document et ils sont abandonnés leur norme inadaptée en faveur de la mienne déjà écrite !

Après avoir perdu une dizaine de jours...

En plus de cela tous mes outils sont synchronisés sur ma norme en particulier la batterie de déclencheur DDL de SQL Server la vérifiant et le driver Power AMC pour l'appliquer

A +

[Jean-Philippe André]

Salut,

sans repondre directement au probleme d'origine, je me permets de donner mon avis sur le nommage.

Il est certain que passer sur une BDD deja existante et la faire evoluer c'est un sujet.
Le cas de figure de la nouvelle base et/ou la creation d'une nouvelle entite pour remplacer une autre, cela permet pas mal de choses.

Le sujet etant d'aspect SQL complet et non pas limite a un SGBD en particulier, les elements que chacun a apporte me confortent dans l'idee qu'un bon nommage change tout sur la duree.

Le fait de pouvoir imprimer sa norme de table peut egalement permettre de gagner un temps considerable pour le lancement, une panoplie complete de fonctions potentiellement deja prete.

L'usage du trigramme au niveau table + champs c'est top, mais la langue utilisee reste a l'appreciation du client.

[SQLpro]

Un petit secret...

Enfin et pour continuer sur ce sujet, je vais vous donner un petit secret de ma norme. Elle compte beaucoup de déclencheurs DDL pour vérifier, mais aussi pour rajouter des objets de manière automatique.
En fait, le problème du SQL c'est qu'il n'est pas objet. Pour pouvoir automatiser certains comportement, si le sql était du "monde objet", ce serait facile alors de créer des tables selon un type objet, par exemple, table d'entité, table de jointure, table de référence, etc. Le seul moyen d'approcher cela reste la généricité et l'unique outil pour ce faire reste le nommage (on pourrait le faire par le schéma SQL, mais le schéma SQL relève plutôt du fonctionnel).

Un simple exemple :

Toutes mes tables de références doivent avoir un nom commençant par T_R_. Lorsque je modélise, via mon outil favori (Power AMC) une table de référence, je créé une entité qui ne comporte que la clef de ma table de référence comme attribut. Aucun autre attribut ne figure dans le modèle.

Par exemple une table des "civilité" aura le script SQL suivant au final :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE TABLE T_R_CIVILITE_CVT (CVT_ID   INT IDENTITY PRIMARY KEY);

Et c'est tout.
Au moment de la création de la table dans le SGBDR, le déclencheur DDL sur CREATE TABLE intercepte les tables de référence grâce au "tag" T_R_ (TABLE_NAME LIKE 'T?_R?_%' ESCAPE '?').
Et son code rajoute les colonnes suivantes :

• XXX_CODE CHAR(16) UNIQUE,
• XXX_LIBELLE VARCHAR(256) NOT NULL,
• XXX_DATE_CREATION DATETIME2(0),
• XXX_DATE_OSBOLESCENCE DATETIME2(0),
• XXX_BASE BIT NOT NULL DEFAULT 0,
• XXX_ORDRE INT

XXX étant le trigramme de la table.

En outre il rajoute un déclencheur qui interdit toute suppression des lignes pour lesquelles XXX_BASE = 1 et toute modification des informations sur ces mêmes ligne sauf pour le libellé.

Enfin il modifie la vue V_REF en ajoutant cette table par UNION ALL avec une colonne contenant le trigramme en sus.
Cette vue prend la forme suivant au final :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
CREATE VIEW V_REF
AS
SELECT 'CVT' AS REF, CVT_ID AS REF_ID, CVT_CODE AS REF_CODE, CVT_LIBELLE AS REF_LIBELLE, CVT_ORDRE AS REF_ORDRE
FROM T_R_CIVILITE_CVT
WHERE CVT_DATE_OSBOLESCENCE IS NULL
UNION ALL
SELECT 'PAY' AS REF, PAY_ID AS REF_ID, PAY_CODE AS REF_CODE, PAY_LIBELLE AS REF_LIBELLE, PAY_ORDRE AS REF_ORDRE
FROM T_R_PAY
WHERE PAY_DATE_OSBOLESCENCE IS NULL
UNION ALL
...
ORDER BY REF, REF_ORDRE;

J'espère que vous comprenez à quoi peut servir une telle vue au niveau des applicatifs !

Bien entendu, cela fait gagner un temps considérable en modélisation...

A +

[StringBuilder]

Bonjour,

Personnellement, je suis très mitigé quant à l'utilisation d'une règle de nommage contenant :
- Le type d'une information
- Son rôle fonctionnel (ou technique)

Surtout si ces éléments doivent être ensuite utilisé dans la couche métier.

Je m'explique :

Aujourd'hui, je modélise mon programme et ma base selon les besoins de mon instant T et mon périmètre applicatif P.
Aux quelques erreurs de conception près (type de colonne changé en cours de développement, relation entre tables revues suite à une incompréhension, etc.) je vais donc avoir un code version 1 tout propre avec des tables qui commencent par "T_", des vues qui commence par "V_", des entiers qui commencent par "INT_" et des floats qui commencent par "FLT_", youpi.

Et demain, le besoin évolue : intégration de nouveaux éléments dans le périmètre, évolutions fonctionnelles, etc.

Et je me retrouve, comme dans l'exemple de mon article sur la "remodélisation" avec un programme applicatif qui appelle des objets de base de données qui ont évolués dans le temps : mon "T_CLIENT" n'est en réalité plus une table, mais une vue qui fait un filtre sur "T_ENTREPRISE" avec "type = 'CLIENT'".

Et là, j'enduis d'erreur SQLPro qui va faire confiance dans la règle de nommage.
Le développeur C++ fait me faire un plantage en règle, ou une fuite mémoire, en chargeant dans un INT64 un FLOAT, car une colonne a changé de type, mais son nom n'a pas évolué (manque de temps, manque de rigueur, modification "en cachette", ou non volonté de réécrire toutes les requêtes existantes).

Bref, pas convaincu que la règle de nommage incluant le type soit autant un atout que ça, dans le cadre d'une application qui évolue.

[SQLpro]

Bonjour,

Personnellement, je suis très mitigé quant à l'utilisation d'une règle de nommage contenant :
- Le type d'une information

Je n'en ais jamais parlé

- Son rôle fonctionnel (ou technique)

Non plus !

Je ne parle que type de table et non type d'attribut.

Surtout si ces éléments doivent être ensuite utilisé dans la couche métier.

Je m'explique :

Aujourd'hui, je modélise mon programme et ma base selon les besoins de mon instant T et mon périmètre applicatif P.

Pour les besoins d'information de mon applicatif me conviendrait mieux. En effet, les données étant par nature ce qu'elle sont (des informations) on ne doit absolument pas les contraindre à adopter une forme particulière en fonction de l'application. C'est une hérésie que je rencontre de nombreuses fois en matière de modélisation. On a voulu faire coller les données à l'application et au bout du compte le résultat est inexploitable et interdit toutes évolutions !
Il faut modéliser les données pour ce qu'elle sont ! Et pour ce que l'on va en faire...

Aux quelques erreurs de conception près (type de colonne changé en cours de développement, relation entre tables revues suite à une incompréhension, etc.) je vais donc avoir un code version 1 tout propre avec des tables qui commencent par "T_", des vues qui commence par "V_", des entiers qui commencent par "INT_" et des floats qui commencent par "FLT_", youpi.

Et demain, le besoin évolue : intégration de nouveaux éléments dans le périmètre, évolutions fonctionnelles, etc.

Encore une fois les données sont dépendantes fonctionnellement les unes des autres en fonction de leurs état naturel ou au pire des règles métiers. Ceci n'interdit nullement les évolutions qui doivent se faire par ajout et non par refonte. S'il y a refonte c'est donc qu'il y avait une erreur de modélisation. Vous n'allez tout de même pas me dire qu'une règle métier utilisée à un moment n'est plus valable à un autre. L'habitude est de ne plus utiliser cette règle métier et d'en créer une autre, ce qui laisse l'ancienne inerte mais n'obère pas le modèle ni les données existante (historique...).

Et je me retrouve, comme dans l'exemple de mon article sur la "remodélisation" avec un programme applicatif qui appelle des objets de base de données qui ont évolués dans le temps : mon "T_CLIENT" n'est en réalité plus une table, mais une vue qui fait un filtre sur "T_ENTREPRISE" avec "type = 'CLIENT'".

Règle absolue en matière de développement : ON NE DEVELOPPE JAMAIS UNE APPLICATION EN ACCEDANT DIRECTEMENT AUX TABLES : on passe uniquement pas des vues, ce qui s’appelle MED (Modèle Externe de Données). Il est alors extrêmement simple de redéfinir une vue en fonction de l'évolution de la règle métier !
C'est d'ailleurs ce que je fais souvent en intervention chez mes clients chez lesquels j'ai modélisé les bases...

Et là, j'enduis d'erreur SQLPro qui va faire confiance dans la règle de nommage.
Le développeur C++ fait me faire un plantage en règle, ou une fuite mémoire, en chargeant dans un INT64 un FLOAT, car une colonne a changé de type, mais son nom n'a pas évolué (manque de temps, manque de rigueur, modification "en cachette", ou non volonté de réécrire toutes les requêtes existantes).

Bref, pas convaincu que la règle de nommage incluant le type soit autant un atout que ça, dans le cadre d'une application qui évolue.

Jamais au grand jamais de notion de type dans le nommage des colonnes. En revanche, souvent une notion d'unité ! (mètre, kg, seconde, ampère...)

A +

[StringBuilder]

Règle absolue en matière de développement : ON NE DEVELOPPE JAMAIS UNE APPLICATION EN ACCEDANT DIRECTEMENT AUX TABLES : on passe uniquement pas des vues, ce qui s’appelle MED (Modèle Externe de Données). Il est alors extrêmement simple de redéfinir une vue en fonction de l'évolution de la règle métier !
C'est d'ailleurs ce que je fais souvent en intervention chez mes clients chez lesquels j'ai modélisé les bases...

Effectivement, avec ce point, je suis d'accord, même si on remodélise une partie de la base, on va limiter les dégats.

Mais personnellement, je n'ai encore JAMAIS vu un programme qui respectait cette règle scrupuleusement (genre y compris pour les tables de référence des catalogues).

Pour ce qui est du type, le fait d'indiquer T_ ou V_ (ou VX_) me semble quand même assez hasardeux. Car à aucun moment on ne peut être certain que ça va rester figé dans le marbre.

Exemple d'évolution simple :
- t_contrat_mariage (id, id_epoux, id_epouse temoin_epoux_id temoin_epouse_id, date, regime, temoin_epoux_id)
=> Avec le PACS, on commence à être emmerdé, car on peut avoir plus de 2 personnes, et c'est pas forcément un homme et une femme : donc les règles fonctionnelles sur les dépendances ("époux sexe masculin et pas cousin de épouse" par exemple)
=> Bah avec le contrat pour tout, on ne parle plus d'époux et d'épouse, et un père peut s'unir avec sa propre fille...
Alors du coup on aura fait une nouvelle table t_pacs pour pas tout péter
=> Et voilà le mariage pour tous : faut quand même tout casser la table initiale.
On va donc modifier et créer des tables, et on va remplacer certaines tables par des vues, etc.

Les données peuvent donc, par nature, évoluer.

On aura la même chose sur tous les éléments légaux : du moment qu'on modélise tel que la lois le détermine, si la lois change, alors on doit changer la structure des données.

Mais aussi et surtout, la structure des données n'est pas seulement liée à la nature des données elles-mêmes (sinon, on aurait à la limite une table par attribut, au cas où un jour il devienne facultatif ou multivalué), mais bien de ce qu'on y met : si mon programme sert à gérer des locations de Ford T, je vais avoir 1 voiture = 1 moteur et 4 roues.
=> Mais si demain fort de son succès, Kiloutou se lance aussi dans la locations de camions, de grues ou de motoculeurs, je vais vite être embêté par mon choix de 1 véhicule = 1 moteur et 4 roues.

Certaines choses relèvent de la bonne pratique ou du lieu commun (une personne a 1 nom et 1 prénom), mais d'autres sont bien moins évidentes (en réalité, une personne peut avoir plusieurs prénoms, et plusieurs noms) qui sont totalement dépendantes du périmètre applicatif.

On a tous été confrontés à 1 cahier des charges "1 produit = 1 code et 1 nom" qui se transforme, dans la version 1.1 en "des fois le produit il a un code, et des fois il en a pas, et des fois il dépend du pays de commercialisation".

Qui n'a pas eu une base client où un jour "ouais, mais il faudrait aussi gérer les prospect, les suspect, les dormants et les morts, sauf qu'ils ont pas du tout les mêmes attributs et que les suspects peuvent pas passer de commande"

Je travaille actuellement sur des applications de CRM, selon le client que j'ai en fasse, la nature des données à gérer est totalement différente : parfois on veut un truc super léché millimétré qui gère tous les cas possible, et dans un autre, pour la même information on me répond "OSEF, si t'y passes plus de 5 secondes on fait pas". Et inversement. La structure même de la données dépend totalement du périmètre applicatif, qui peut très fortement évoluer dans le temps.

[SQLpro]

Exemple d'évolution simple :
- t_contrat_mariage (id, id_epoux, id_epouse temoin_epoux_id temoin_epouse_id, date, regime, temoin_epoux_id)
=> Avec le PACS, on commence à être emmerdé, car on peut avoir plus de 2 personnes, et c'est pas forcément un homme et une femme : donc les règles fonctionnelles sur les dépendances ("époux sexe masculin et pas cousin de épouse" par exemple)
=> Bah avec le contrat pour tout, on ne parle plus d'époux et d'épouse, et un père peut s'unir avec sa propre fille...
Alors du coup on aura fait une nouvelle table t_pacs pour pas tout péter
=> Et voilà le mariage pour tous : faut quand même tout casser la table initiale.
On va donc modifier et créer des tables, et on va remplacer certaines tables par des vues, etc.

Eh bien votre interprétation est fausse car bien que cela s’appelle le mariage pour tous (ça s'est le nom marketing) rien à voir avec le mariage tel que prévu antérieurement dans le code civil car les règles sont différentes. Pas d'enfantement possible, parentalité totalement différente...
https://www.legifrance.gouv.fr/affic...tegorieLien=id
Il faudra donc effectuer des traitements différents en fonction de l'homo ou l'hétero sexualité du mariage.
Il en est de même avec le PACS, qui à d'ailleurs été énormément remanié par Sarkozy qui l'a rapproché du mariage sur bien des points, notamment au niveau fiscal. Il a donc évolué indépendamment du mariage classique et le mariage pour tout suivra aussi sans doute une évolution par rapport aux manques actuels du mariage et lorsque les deux seront à même niveau un simple UNION ALL des deux tables fera l'affaire !

Les données peuvent donc, par nature, évoluer.

Oui, mais il faut aussi conserver l'existant. D’où l'intérêt des vues...

On aura la même chose sur tous les éléments légaux : du moment qu'on modélise tel que la lois le détermine, si la lois change, alors on doit changer la structure des données.

Mais aussi et surtout, la structure des données n'est pas seulement liée à la nature des données elles-mêmes (sinon, on aurait à la limite une table par attribut, au cas où un jour il devienne facultatif ou multivalué), mais bien de ce qu'on y met : si mon programme sert à gérer des locations de Ford T, je vais avoir 1 voiture = 1 moteur et 4 roues.

Faux... Il en existe à 3 roues. Certains scooter n'en sont légalement pas car leur écartement de l'essieu avant est d'une longueur qui la fait devenir voiture !!!

=> Mais si demain fort de son succès, Kiloutou se lance aussi dans la locations de camions, de grues ou de motoculeurs, je vais vite être embêté par mon choix de 1 véhicule = 1 moteur et 4 roues.

Certaines choses relèvent de la bonne pratique ou du lieu commun (une personne a 1 nom et 1 prénom), mais d'autres sont bien moins évidentes (en réalité, une personne peut avoir plusieurs prénoms, et plusieurs noms) qui sont totalement dépendantes du périmètre applicatif.

On a tous été confrontés à 1 cahier des charges "1 produit = 1 code et 1 nom" qui se transforme, dans la version 1.1 en "des fois le produit il a un code, et des fois il en a pas, et des fois il dépend du pays de commercialisation".

Qui n'a pas eu une base client où un jour "ouais, mais il faudrait aussi gérer les prospect, les suspect, les dormants et les morts, sauf qu'ils ont pas du tout les mêmes attributs et que les suspects peuvent pas passer de commande"

Cela se gère par un héritage de données, à tout moment !

Je travaille actuellement sur des applications de CRM, selon le client que j'ai en fasse, la nature des données à gérer est totalement différente : parfois on veut un truc super léché millimétré qui gère tous les cas possible, et dans un autre, pour la même information on me répond "OSEF, si t'y passes plus de 5 secondes on fait pas". Et inversement. La structure même de la données dépend totalement du périmètre applicatif, qui peut très fortement évoluer dans le temps.

Et donc on le paye cash 10 fois plus cher à l'arrivée... Courte vue !

A +

[StringBuilder]

Pour l'exemple du mariage, si je suis en train de travailler sur la refonte du SI d'une mairie, ça a son importance de connaître les différences.

Si je suis en train de travailler dans une agence Marketing qui doit envoyer des courriers pour des listes de mariage par exemple, osef qu'on puisse enfanter ou non, on n'en n'est pas là : l'important c'est d'avoir les noms des personnes qui s'unissent.

Il y a donc "la vérité", "ce qu'on voit" et "ce qu'on en fait".

Vous tendez à vouloir absolument vous approcher le plus possible de "la vérité", moi je dois ajuster le curseur entre ce que "je vois" et ce que "mon client en fait".

Si on doit modéliser un tas de pommes, selon si je suis un fermier, un magasin, un physicien ou un mathématicien, je ne vais pas voir du tout la même chose, et certainement pas du tout vouloir en faire la même chose.

Et quand je suis un industriel, je vais pas forcément raisonner en nombre de pommes, kilo de pommes, mètres cubes de pomme ou en container de pommes, mais peut-être en litres de jus de pomme, nombre de tartes à la pomme, ou même en K€, données qui vont complètement dépendre non seulement du volume et de la taille des pommes, mais aussi d'autres attributs (variété, maturité, durée de stockage, etc.)

[SQLpro]

Pour l'exemple du mariage, si je suis en train de travailler sur la refonte du SI d'une mairie, ça a son importance de connaître les différences.

Si je suis en train de travailler dans une agence Marketing qui doit envoyer des courriers pour des listes de mariage par exemple, osef qu'on puisse enfanter ou non, on n'en n'est pas là : l'important c'est d'avoir les noms des personnes qui s'unissent.

Il y a donc "la vérité", "ce qu'on voit" et "ce qu'on en fait".

L'un n'empêche pas l'autre. C'est au niveau des attributs que j'y mettrais. Dans tous les cas un héritage me parait la solution

Vous tendez à vouloir absolument vous approcher le plus possible de "la vérité", moi je dois ajuster le curseur entre ce que "je vois" et ce que "mon client en fait".

Si on doit modéliser un tas de pommes, selon si je suis un fermier, un magasin, un physicien ou un mathématicien, je ne vais pas voir du tout la même chose, et certainement pas du tout vouloir en faire la même chose.

Et quand je suis un industriel, je vais pas forcément raisonner en nombre de pommes, kilo de pommes, mètres cubes de pomme ou en container de pommes, mais peut-être en litres de jus de pomme, nombre de tartes à la pomme, ou même en K€, données qui vont complètement dépendre non seulement du volume et de la taille des pommes, mais aussi d'autres attributs (variété, maturité, durée de stockage, etc.)

Dans ce cas, l'unité, si elle diffère (cas des supermarché ou l'on vend tantôt à l'unité ou au poids), devra être une colonne de la table

A +