Forum d'entraide PHPFrance

Bonjour,

Une petite chose me tracasse dans la création des tables, sur le net je trouve des avis contradictoires donc je suis un peu perdu...

2 simple questions :

Est-il préférable de nommer les colonnes avec un préfixe correspondant au nom de la table ?

Exemple table "gens" on aurait : "gens_id", "gens_prenom", etc...

Ensuite si dans une table "newsletter" j'ai besoin d'avoir en commun avec la table gens l'id, dois-je préciser dans le nom de la colonne, comme ceci ? :

newsletter_id_gens

Voilà j'ai d'autres tonnes de questions mais c'est les deux plus importantes
Car je suppose que pour faire des requêtes avec jointures il vaut mieux que les tables soient bien faites.

Salut,

Pour ma part j'utilise comme nom de champ seulement le nom de l'information : et pour un lien avec une autre table le nom de la table et le nom du champ : Après dans les requêtes avec jointure, de toute façon il faudra préciser le nom de la table donc on pourra facilement et rapidement savoir quel champ correspond à quoi.

Salut,

Pour ma part j'utilise comme nom de champ seulement le nom de l'information :

Code : Tout sélectionner

table gens : id, nom ,prenom

et pour un lien avec une autre table le nom de la table et le nom du champ :

Code : Tout sélectionner

table newsletter : gens_id

Après dans les requêtes avec jointure, de toute façon il faudra préciser le nom de la table donc on pourra facilement et rapidement savoir quel champ correspond à quoi.

Effectivement ça me parait logique comme technique

En ayant un préfixe, tu permet les jointures naturelles. Ensuite, ça te permet lors de l'écriture du code de savoir de quelle table sort l'id que tu traites s'il est préfixé. S'il ne l'est pas, tu risques fort de chercher régulièrement à quelle table ça correspond (et d'y perdre un temps considérable on cumulant les 1mn ici, 30 sec là et 2mn ailleurs).

Personnellement, je préconise toujours le préfixe, même si tu dois indiquer la table lors des jointures.

Personnellement, je préconise toujours le préfixe, même si tu dois indiquer la table lors des jointures.

Sur toutes les colonnes ou seulement sur l'id ?

Sur toutes, ça simplifie la relecture des requêtes SQL par la suite.

C'est question de goût.
gens.id est plus aisé à retenir et plus rapide à taper que gens.gens_id, et gens.gens_id fait une redondance d'informations, à savoir que l'on sait directement de quelle valeur on parle et elle ne sera pas dure à retrouver. Pour ma part, c'est la notation courte que je préconise.

Donc en définitive, c'est bel et bien question de goût, ce qui est sur, c'est que quoique tu décides, il faut éviter de mixer les deux, et une fois choisi sa convention, la garder pour tout le projet, sans quoi on s'emmèle les pinceaux avec des gens.gens._id d'un côté et des machin.id de l'autre et on ne saura plus si on a mis machin_id ou seulement id…

Pas d'accord, ce n'est pas une question de goût, c'est purement pratique.

Si j'ai tabe1, table2 et table3 dans une jointure, je ne suis d'abord pas obligé d'utiliser le nom complet en préfixe et pareil pour la table que je peux utiliser sous forme d'alias avec t1.t1_id, t2.t2_id et t3.t3_id.

C'est sûr que dans les conditions de jointure je saurai à quelle table appartient telle colonne, mais dans la partie SELECT, comment distinguerais-tu id de la table1 de id de la table 2 lors de la sortie ? Même si tu fais t1.id, t2.id, à la lecture de la requête, tu sauras tout de suite, mais les colonnes renvoyées en sortie seront toutes les deux "id" tout court à moins de leur mettre un alias... ce qui somme toute revient à utiliser un système permettant de les distinguer à la sortie. Alias que tu dois donc rajouter à chaque requête au lieu de préfixer une fois pour toutes chaque colonne.

CQFD...

Je suis de l'avis de Sekiltoyai.

Je pense que surcharger le nom des colonnes n'est utile que dans le cas où le nom ne se suffit pas à lui même, c'est à dire principalement dans le cas de jointure.
Je préfère donc ne pas surcharger les noms de tout mes champs pour simplifier qu'une partie de mes requêtes.

Par contre, je comprend ton point de vue et c'est ça qui me fait dire que c'est une question de gout plus qu'une question de pratique, comme l'identation par exemple (j'aurais du mal à croire quelqu'un qui me dit que ne pas identer son code, c'est mieux )

Il n'y a pas de mots pour dire à quel point j'appuie l'utilisation systématique des préfixes. Pour toutes les raisons invoquées par l'ami Cyrano et plus encore. Les jointures naturelles en sont une, mais même les jointures explicites sont simplifiées La relation entre les table est évidente : user_id appartient à la table users (le nom de la table est au pluriel car elle contient plusieurs "user") et si je te dis que ma table users_groups contient 2 champs : user_id et group_id, je suis sûr que tu vas deviner ce qu'elle fait.

Comme ça a été dit plus haut, tu n'auras pas à t'embêter avec des aliases à rallonge comme "g.id AS group_id, u.id AS user_id". D'ailleurs, la nécessité même d'utiliser un alias prouve que le nom de la colonne ne convient pas. Un peu comme si tes parents t'avait donné le même prénom que ton grand frère, alors quand il est à la maison en même temps que toi ils t'appellent Marcel. On voit régulièrement dans ce même forum des requêtes incompréhensibles parce que plusieurs colonnes portent le même nom, ou un même donnée est stockée dans des colonnes de noms différents.

Pour ta seconde question, en ce qui me concerne ça dépend des jours. Selon l'humeur et la taille de la base, j'appellerais cette table "newsletters_users" (plusieurs newsletters liant plusieurs users) en ajoutant peut-être un préfixe pour indiquer que c'est une , comme "rel_newsletters_users". La table aurait pour clé primaire (newsletter_id, user_id). Je n'ai pas trouvé de règles pour définir dans quel ordre mettre les colonnes dans la table comme dans le nom de la table mais tant que possible je fais en sorte que ce soit le même partout. Contrairement à zeus, je considère ces règles comme étant une méthode, plus qu'une simple histoire de préférences personnelles.

De plus, je mets en garde contre l'utilisation de franglais dans une base de données. liste/gens ou newsletter/users, choisis ton camps camarade

Je comprend bien vos arguments et je n'ai aucun argument contraire, mais vous ne m'avez toujours pas convaincu que c'était mieux (càd toujours plus utile/performant/leger) pour une application complète.
Au risque de passer pour un borné, je reste sur mon opinion que c'est surtout un choix.

Sinon, il y a quelque chose que je remarque dans toutes les interventions (et que j'aurais pu citer à la place de l'indentation), c'est la consistance des choix. Et là, j'adhère complètement (le 1er qui me parle de moule, je le baffe )

Je comprend bien vos arguments et je n'ai aucun argument contraire, mais vous ne m'avez toujours pas convaincu que c'était mieux (càd toujours plus utile/performant/leger) pour une application complète.

Tout dépend si tu considères "maintenable" et "lisible" comme des critères allant vers le mieux. Je dirais qu'on peut s'en passer, si et seulement si la base de données n'aura jamais à être manipulée par un tiers... Donc si on peut se passer complètement de l'aide d'autrui pour toute la durée de vie de la base, ce qui est rare.

Ce n'est donc pas un conseil à donner à ceux qui nous lisent Mais les codeurs chevronnés feront leur choix en leur âme et conscience.