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 +

[François DORIN]

Sur le fait de recoller et d'obliger à respecter une convention, je suis d'accord avec toi, d'un point de vue théorique. Et c'est d'autant plus faisable lorsqu'il n'y a pas d'existant. Par contre, en pratique, quand tu arrives sur de l'existant, parfois très vieux, c'est très difficile d'y arriver.

[Shinja]

Et bien mince, je ne pensais pas que mon topic était parti en débat.

Je travaille uniquement en anglais, c'est plus pratique et cohérent pour le code source. Je trouve tellement moche un code en anglais avec des variables ou valeurs en français. Mais bon, c'est juste mes habitudes, je suis pas professionnel, je développe pour moi. En l’occurrence, je suis en train de mettre en place une base de données pour mon blog et j'hésitais sur le nom de plusieurs tables.

Je voulais donc savoir si c'était une bonne chose de mettre en préfixe la table vers laquelle il y a une relation comme par exemple :

articles => article_comments ou comments
articles => article_types ou types
articles => article_metas ou metas

games => game_reviews ou reviews
games => game_genres ou genres
games => game_platforms => platforms

users => user_profiles ou profiles

Après l'utilisation de l'anglais est demandée dans la convention de mon framework php, donc ce n'est pas juste une questions de goûts.

Je me demande s'il ne faut pas mettre un préfixe dans le cas où on aurait deux tables qui porteraient le même noms.

Pour le moment je me suis dis lorsqu'une table possède plusieurs relations vers d'autres tables, on utilise par de préfixe. Dans le cas où elle est en relation avec une seule table, oui.

Par exemple :

articles => article_comments (car article_id comme foreignkey)
games => genres => games_genres (table de jointure)

par contre si les commentaires étaient en relation avec plusieurs tables :
articles => comments => articles_comments
games => comments => games_comments
pictures => comments => pictures_comments


Je pense que c'est la meilleure façon, car mettre sans cesse de préfixe partout, ça rend plus compliqué le code alors que le but est de simplifier la chose.

[François DORIN]

Pour le moment je me suis dis lorsqu'une table possède plusieurs relations vers d'autres tables, on utilise par de préfixe. Dans le cas où elle est en relation avec une seule table, oui.

C'est généralement l'approche que je choisi.

Après l'utilisation de l'anglais est demandée dans la convention de mon framework php, donc ce n'est pas juste une questions de goûts.

Ca aussi c'est un aspect qui fait parfois débat. Pour ma part, d'un point de vue dev, je préfère l'anglais. Plus court, plus concis, cela permet aussi de garder un tout cohérent. Les Framework sont tous en anglais, et donc quand on a un getter quelque part, je préfère que ce soit Get partout et pas tantôt "Get" tantôt "Recupere", etc...

Après, c'est une question de choix.

[SQLpro]

Pouvez-vous m'affirmer à l'avance que jamais au grand jamais il n'y aura qu'une seule table traitant de zigzornifle au sujet des macheprolux ?

• Si oui, alors table => zigzornifle
• Si non, alors macheprolux_zigzornifle

Pensez simplement qu'une base évolue.... Donc si vous êtes capable de le certifier pour l'avenir, alors tout est parfait dans le meilleur des mondes. Pour ma part je n'y crois jamais, donc toujours macheprolux_zigzornifle même si une seule table est concernée par les zigzornifle, car cela ôte tout ambiguïté.

Quand au nom des PRIMARY KEY et FOREIGN KEY => utilisation du trigramme de table + ID, par principe toute colonne clef étrangère doit avoir le même nom dans les deux tables afin de permettre le "natural join"...

A +

[escartefigue]

Tous les arguments qui précèdent sont passionnants, mais encore une fois, les entreprises ont leurs propres normes auxquelles il est impossible de déroger.
J'ai travaillé en poste fixe et en prestation de service chez de nombreux clients, dans des secteurs d'activité très divers, et chez aucun de ces clients, ces codifications n'étaient applicables.
On peut le déplorer, mais c'est un fait.

Quand je vois déjà le mal que j'ai de convaincre les responsables de choisir des identifiants non fonctionnels comme clefs primaires, de choisir les bons types de données ou encore de ne pas modéliser à plat, je n'imagine même pas essayer de les convaincre de changer la nomenclature interne des objets , même si bien souvent ce serait la meilleure des choses à faire

[SQLpro]

Tous les arguments qui précèdent sont passionnants, mais encore une fois, les entreprises ont leurs propres normes auxquelles il est impossible de déroger.

pas du tout. Il faut le bon argumentaire et les couilles. J'avais la même approche que toi quand j'étais jeune et maintenant j'impose ma façon de faire sinon je me casse...
Néanmoins, avant je donne quelques exemples et je laisse le choix possible :
démontrer moi que votre approche de nommage et meilleure que la mienne sur les exemples que je viens de donner !
Comme c'est évidemment impossible, alors j'emporte la décision.
À ce jour et depuis 15 ans, aucune entreprise ne m'a contredite.

A +

[François DORIN]

démontrer moi que votre approche de nommage et meilleurs que la mienne sur les exemples que je viens de donner !
Comme c'est évidemment impossible, alors j'emporte la décision.

Du coup, c'est biaisé, puisque c'est toi qui choisi les questions. Forcément, tu vas choisir des cas qui mettent en valeur tes conventions. Mais c'est mettre de côté les besoins réels des clients.

[Arkhena]

démontrez moi que votre approche de nommage est meilleure que la mienne sur les exemples que je viens de donner !

Et si leur démarche n'est pas meilleure mais équivalente à la votre, imposez-vous toujours la votre ?
Et s'ils vous fournissent d'autres exemples sur lesquels votre démarche n'est pas la meilleure ?
Sur quels critères objectifs définissez-vous que votre démarche est meilleure ?

Ne vous méprenez pas, je suis ravie pour vous si votre manière de faire fonctionne, c'est juste qu'elle ne colle pas avec ma philosophie de la vie... ça doit être parce que je n'ai "pas de couilles"

[SQLpro]

Du coup, c'est biaisé, puisque c'est toi qui choisi les questions. Forcément, tu vas choisir des cas qui mettent en valeur tes conventions. Mais c'est mettre de côté les besoins réels des clients.

Oui et non, car la plupart du temps il me disent, oui, mais si on cherche ça alors comment vous faites avec votre truc... Et comme ça a été pensé depuis fort longtemps (130 pages de description) j'ai réponse à presque tout !
A +

[SQLpro]

Et si leur démarche n'est pas meilleure mais équivalente à la votre, imposez-vous toujours la votre ?

Oui, sinon je leur facture 5 jours de plus pour me l'approprier avec un avenant qui va mettre 15 jours a être accepté... Donc ils y renoncent systématiquement. En fait j'ai jamais trouvé à ce jour une norme capable de faire plus de 50% de ce que fais la mienne. j'ai même démontré à Joe Celko que son livre "SQL style" était nullissime à ce sujet !

Et s'ils vous fournissent d'autres exemples sur lesquels votre démarche n'est pas la meilleure ?

Je ne sais pas... Jamais rencontré ! Sans me plierais-je à leur règles en les intégrants gratuitement à ma démarche

Sur quels critères objectifs définissez-vous que votre démarche est meilleure ?

La facilité à rechercher certaines informations de manière immédiate et évidente. Quelques exemples très simples :

• l'impact d'un changement de type sur toutes les tables et vues de la base...
• quelle sont les colonnes d'une table qui sont des colonnes de FK, de PK...
• quel alias de table dois-je utiliser dans les requêtes afin qu'il n'existe aucune ambiguité...

Ne vous méprenez pas, je suis ravie pour vous si votre manière de faire fonctionne, c'est juste qu'elle ne colle pas avec ma philosophie de la vie... ça doit être parce que je n'ai "pas de couilles"

Il va falloir donc que je rajoute dans ma table de référence des sexe, hermaphrodite ou asexué !!!

A +

[escartefigue]

pas du tout. Il faut le bon argumentaire et les couilles. J'avais la même approche que toi quand j'étais jeune et maintenant j'impose ma façon de faire sinon je me casse...

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. On ne peut pas démonter l'existant, même s'il est fait en dépit du bon sens.

Sans compter que, chez la plupart des clients chez lesquels j'interviens, une grosse partie du S.I. est hébergée sur mainframe, or si la base de données (en l'occurrence DB2 for Z/OS) pourrait tout à fait utiliser une nomenclature telle que vous la proposez, certains langages de développement eux, ne le permettent pas : il existe encore des sites dont la limitation sur la taille des noms d'objet est de ... 6 ou 8 caractères !

Le patrimoine applicatif est ce qu'il est, il faut bien faire avec