Discussion :

[Shinja]

Bonjour,

voilà des heures et des heures que je réfléchis sur comment bien nommer mes tables. J'ai bien lu toutes les conventions, mais je n'arrive toujours pas à me décider. Là où j'hésite sur le nom des tables c'est sur la question des préfixes. Par exemple, j'ai la table "users", dois-je appelé la table des profils "user_profiles" ou juste "profiles" ? "article_comments" ou juste "comments" ?

Merci.

[SQLpro]

Bonjour,

voilà des heures et des heures que je réfléchis sur comment bien nommer mes tables. J'ai bien lu toutes les conventions, mais je n'arrive toujours pas à me décider. Là où j'hésite sur le nom des tables c'est sur la question des préfixes. Par exemple, j'ai la table "users", dois-je appelé la table des profils "user_profiles" ou juste "profiles" ? "article_comments" ou juste "comments" ?

Merci.

Déjà si vous êtes sur un développement en français par des développeurs français et en plus pour des clients français, je voit pas l'intérêt de causer en anglais à cause de possible erreurs d'interprétation...

Ensuite j'utilise personnellement cette façon de faire :
http://www.sqlspot.com/Norme-de-developpement.html
...que j'impose à tous mes clients, sans quoi je ne travaille pas avec eux. Lorsque cette façon de faire n'est pas respectée à la lettre, les temps de développement sont doublés...

Enfin, il est important d'utiliser différents schémas SQL afin de ventiler les objets de la base relatifs à un même pan fonctionnel de la base. Exemple : schéma SQL VENTE pour les ventes, STOCK pour les stocks, PUB pour la publicité, COMPTA, RH, MARKET...



A +

[Arkhena]

Bonjour,

Je vais être plus souple que SQL Pro...

Je considère que nous avons tous des manières de fonctionner différentes. Alors vous pouvez utiliser la normalisation qui vous convient, du moment qu'elle est acceptée par l'équipe et qu'elle ne fait pas perdre de temps... Bien sûr il faudra documenter votre démarche.

Bonne journée,

Arkhena

[escartefigue]

...que j'impose à tous mes clients, sans quoi je ne travaille pas avec eux. Lorsque cette façon de faire n'est pas respectée à la lettre, les temps de développement sont doublés...

Avoir des règles de codification, c'est très bien, mais les clients ont souvent déjà défini ces règles, on démarre rarement de rien, du coup, imposer sa propre nomenclature est très, très exceptionnel

[François DORIN]

Ensuite j'utilise personnellement cette façon de faire :
http://www.sqlspot.com/Norme-de-developpement.html
...que j'impose à tous mes clients, sans quoi je ne travaille pas avec eux. Lorsque cette façon de faire n'est pas respectée à la lettre, les temps de développement sont doublés...

Il ne faut pas exagérer non plus La question porte sur le nommage des éléments (et en particulier ici, des tables). Ne pas respecter vos conventions ne fera pas doubler les temps de développement. D'ailleurs, il y a plusieurs préceptes qui sont loin de faire l'unanimité, comme l'utilisation des trigrammes à foison ou le préfixage d'un nom par le type de l'élément (T_ pour table, V_ pour vue, etc... par exemple).

Comme le souligne Arkhena, il faut que les conventions de nommage soient respectées par l'ensemble de l'équipe, et quelles soient les mêmes pour l'intégralité du projet (potentiellement des projets s'il y en a plusieurs). Il y a plusieurs tendance, plusieurs pratiques, elles ont des avantages et des inconvénients, mais il n'y en a pas une qui surclasse toutes les autres dans tous les domaines. Il faut que le nom des éléments soit clair, précis et sans ambiguïté. Bref, comme d'habitude, les conventions sont une question de choix !

[SQLpro]

Pour information, je suis chez un client et je viens de passer 20 minutes à comprendre un problème parce que ce que je croyais être une table est une vue... Et qi plus est une vue indexées....
Évidemment cela change toute mon analyse... Bref, 2h de boulot de foutu a étudier des requêtes complexes dans des procédures sans me rendre compte que ce que je croyais être une table était une vue indexée...
Si le client avait mis en place une norme de nommage cela m'aurait immédiatement sauté aux yeux. En effet dans ma norme, les vues c'est V_ et les vues indexées c'est VX_.

Même les requêtes systèmes sont plus couteuses et plus complexes à élaborer pour retrouver ces informations sans cette foutue norme !

Exemple :


La première requête est relativement plus complexe à élaborer que la seconde et coute juste 10 fois plus cher en exécution que la seconde...

Après vous pourrez dire que que vous voudrez des normes de nommage d'un vieux con comme moi... Mais ça fait maintenant 30 ans que je bosse dans ce métier et des exemples comme ça j'en ai presque tous les jours !

A +

[Arkhena]

Bonjour,

Je pense que vous n'avez pas bien compris ce que nous essayions de dire (en tous cas ce que moi j'essayais de dire)...

Pour ma part, je suis persuadée que normer les noms des objets est nécessaire, c'est juste qu'il existe différentes manières de faire et pas une seule.

Cordialement,

Arkhena

[François DORIN]

Après vous pourrez dire que que vous voudrez des normes de nommage d'un vieux con comme moi... Mais ça fait maintenant 30 ans que je bosse dans ce métier et des exemples comme ça j'en ai presque tous les jours !

Mais personne n'a dit qu'elles étaient stupides Elles ont leurs avantages et leurs inconvénients. Par exemple, inconvénient : si les conventions ne sont pas respectées, cela peut faire très mal ! J'ai eu a intervenir sur une BD où il y avait le préfixage en fonction du type d'objet. J'ai mis 3h à comprendre pourquoi ça ne marchait car une vue était préfixée... T_ ! (et du coup, je la considérais comme une table). On pouvait faire des inserts sur la vue via un trigger et c'est le trigger qui était foireux, d'où un INSERT de la valeur 1 qui me renvoyait la valeur 2. Avant d'en arriver à remettre en cause le INSERT... on cherche dans le code de l'application cliente.

L'origine du problème ? Initialement, c'était bien une table. Il y a eu des évolutions et la table est devenue une vue. Pour éviter de réécrire plein de procédures stockées, le nom de la table/vue avait été conservée. Ce qui soulève un autre inconvénient de cette approche. Une modification du schéma (transformer une table en vue et vice-versa), oblige à réécrire toutes les procédures stockées les référençant, voire les applications si elles accèdent directement à l'entité en question.

Donc oui, cette méthode à des avantages, mais elle a aussi ses limites et il faut en avoir conscience. D'un point de vue architecture de données, oui, cette approche est très bien, car d'un seul coup d'oeil, on sait ce que l'on manipule. D'un point de vue développement et maintenance à long terme d'applications, mon expérience me montre qu'on atteint très vite des limites...

[SQLpro]

Mais personne n'a dit qu'elles étaient stupides Elles ont leurs avantages et leurs inconvénients. Par exemple, inconvénient : si les conventions ne sont pas respectées, cela peut faire très mal ! J'ai eu a intervenir sur une BD où il y avait le préfixage en fonction du type d'objet. J'ai mis 3h à comprendre pourquoi ça ne marchait car une vue était préfixée... T_ ! (et du coup, je la considérais comme une table).

C'est pourquoi chez mes clients je met des déclencheurs DDL qui oblige à respecter ce nommage à la lettre.

On pouvait faire des inserts sur la vue via un trigger et c'est le trigger qui était foireux, d'où un INSERT de la valeur 1 qui me renvoyait la valeur 2. Avant d'en arriver à remettre en cause le INSERT... on cherche dans le code de l'application cliente.
L'origine du problème ? Initialement, c'était bien une table. Il y a eu des évolutions et la table est devenu une vue.
Pour éviter de réécrire plein de procédures stockées, le nom de la table/vue avait été conservée. Ce qui soulève un autre inconvénient de cet approche. Une modification du schéma (transformer une table en vue et vice-versa), oblige à réécrire toutes les procédures stockées les référençant, voire les applications si elles accèdent directement à l'entité en question.

Il y avait encore plus simple : respecter à nouveau la norme de développement en interdisant toute utilisation directe des tables dans les requêtes applicatives et obliger de passer par des vues... Là aussi ça s'automatise avec des audits...

Donc oui, cette méthode à des avantages, mais elle a aussi ses limites et il faut en avoir conscience. D'un point de vue architecture de données, oui, cette approche est très bien, car d'un seul coup d'oeil, on sait ce que l'on manipule. D'un point de vue développement et maintenance à long terme d'applications, mon expérience me montre qu'on atteint très vite des limites...

Il suffit qu'elle soit intelligente et qu'elle possède les outils pour en obliger l'application.

A +