Discussion :

[StringBuilder]

Dans la mesure où :
- Ça ne rends pas le MPD plus lisible (au contraire)
- Sans MPD sous les yeux, le développeur doit se poser la question en permanence de comment le concepteur a abrégé commande = cde ou cmd, client = clt ou cli ?
- L'utilisation d'un trigramme porte à confusion pro_id = identifiant de produit, provosion ou provision ?
- Ça alourdi inutilement l'écriture des requêtes (clauses SELECT et WHERE considérablement alourdies)
- Que pour les auto-jointures, donc ne peut pas utiliser le NATURAL JOIN
- Que pour les auto-jointures, on doit préfixer avec un nom de table qui n'existe pas

Je trouve que les avantages de préfixer systématiquement d'un trigramme "juste pour pouvoir utiliser des jointures naturelles" sont plus faibles qu'autre-chose.
Sachant qu'en plus seule une faible minorités de SGBD supportent cette syntaxe (et pour cause, vu qu'elle est aussi inutile qu'intrusive dans la conception et sa syntaxe non stable dans le temps), c'est pas un mal de la connaître, mais pas franchement un plus de l'utiliser : si c'est pour se coltiner des USING à chaque fois, aucun intérêt, et si on se passe d'un USING, on prend le risque d'avoir des requêtes qui se mettent à déconner à chaque modification du modèle des données.

Autant utiliser des INNER JOIN sur des noms de colonne explicites, et éviter de se coltiner des noms de colonne à rallonge inutilement.

Après, ça reste de la règle de nommage, donc les goûts et les couleurs... mais en attendant, j'ai plus souvent vu de la merde avec des concepteurs adeptes du trigramme qu'avec des adeptes des noms purement sémantiques et des jointures explicites.

Genre ça, désolé, mais moi je vomi :

Code sql :

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

1
2
3
4
5
 
select cli_id, cli_nom, sum(cde_valeur)
from client
natural join commande
group by cli_id, cli_nom

Dans le jeu de résultat, on n'a aucune certitude d'où vient chaque colonne.
Et le jour où je dois ajouter le client livré dans la requête :

Code sql :

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

1
2
3
4
5
6
 
select cli_id, cli_nom, cli_nom, sum(cde_valeur)
from client
natural join commande
inner join client on cli_id = liv_id
group by cli_id, cli_nom

WTF ?! comment ça se fait que ça marche pas ouin ouin...

Alors que si dès le début on bosse proprement :

Code sql :

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

1
2
3
4
5
 
select cli.id, cli.nom, sum(cde.valeur)
from client cli
inner join commande cde on cde.client_id = cli.id
group by cli.id, cli.nom

Et le jour où je dois ajouter le client livré dans la requête :

Code sql :

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

1
2
3
4
5
6
 
select cli.id, cli.nom, liv.nom, sum(cde.valeur)
from client cli
inner join commande cde on cde.client_id = cli.id
inner join client liv on liv.id = cde.clientlivre_id
group by cli.id, cli.nom, liv.nom

C'est limpide, naturel et sans surprise pour le développeur : aucun besoin de toucher à la partie déjà existante de la requête.

[aieeeuuuuu]

- Ça ne rends pas le MPD plus lisible (au contraire)

Pas plus lisible, certes, mais pourquoi "au contraire" ?

- Sans MPD sous les yeux, le développeur doit se poser la question en permanence de comment le concepteur a abrégé commande = cde ou cmd, client = clt ou cli ?

Sans le MPD sous les yeux, difficile dans tous les cas de faire la moindre requete, puisqu'il faut commencer par trouver le nom de la table dont on a besoin. D'ailleurs, à ce titre, je trouve utile d'inclure le trigramme dans le nom de la table également soit :

T_CDE_COMMANDE
    cde_id
    cde_date
    cde_...

- L'utilisation d'un trigramme porte à confusion pro_id = identifiant de produit, provosion ou provision ?

pro_id, ça porte quand même moins à confusion que id !!!!!
C'est donc tout l'inverse, ça évite les confusions, surtout si le trigramme est inclus dans le nom de la table.
ça permet aussi dans les requêtes simples de se passer des alias (quand par exemple une colonne "nom" se retrouve dans douze tables différentes) avec un avantage : le trigramme sera toujours le même, alors que l'alias pourra (et il le fera !) changer à chaque requete puisque définit au moment de l'écriture de celle-ci.

- Ça alourdi inutilement l'écriture des requêtes (clauses SELECT et WHERE considérablement alourdies)

personnellement, je trouve que ça les simplifie énormément au contraire, surtout si on utilise un système de complétion digne de ce nom (donc pas cette bouse par défaut sous SQL Server ) : il suffit de taper "nom" pour que la complétion propose "cli_nom" et "pdt_nom", et surtout, il suffit de taper "cli" pour que la complétion propose à la suite toutes les colonnes de la table client !

- Que pour les auto-jointures, donc ne peut pas utiliser le NATURAL JOIN

Le fait qu'il faille parfois faire des jointures externe ne rend pas pour autant la jointure interne inutile.
De la même façon, le fait qu'il faille parfois faire des jointures explicites ne rend pas la jointure naturelle inutile...

Genre ça, désolé, mais moi je vomi :

Code sql :

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

1
2
3
4
5
 
select cli_id, cli_nom, sum(cde_valeur)
from client
natural join commande
group by cli_id, cli_nom

Dans le jeu de résultat, on n'a aucune certitude d'où vient chaque colonne.

bah... justement... si !
bien plus que dans select id, nom, sum(valeur)

Alors que si dès le début on bosse proprement :
[...]

Et le jour où je dois ajouter le client livré dans la requête :
[...]
C'est limpide, naturel et sans surprise pour le développeur : aucun besoin de toucher à la partie déjà existante de la requête.

Certes, ça fait un peu moins de boulot puisque que dans le cas contraire, il faudrait aliasser la table client, mais ce n'est pas non plus le bout du monde ! (et puis avec tout le temps qu'on aura gagné par ailleurs grâce au trigramme, on peut bien perdre quelques secondes sur un point comme celui-ci).

Je rajouterais toutefois qu'il faut que la règle de nommage avec trigramme soit suivie de façon très rigoureuse à la conception. Car en effet, dans une base où le trigramme n'est utilisé que dans 90% des tables, ou qu'un même trigramme est utilisé pour plusieurs tables, alors l'ensemble ne sert plus a rien et ne fait au final qu'alourdir le truc. C'est peut-être des cas comme ceux-là que tu as rencontrés et qui te font raisonner ainsi.

Dernier point, personnellement, même pour les clef étrangères, je préfère ajouter le trigramme de la table qui la porte :

T_CDE_COMMANDE
    CDE_ID
    CDE_CLI_ID

ça permet de garder pas mal d'avantages évoqués plus haut (complétion, alias), mais empêche la jointure naturelle... que je n'utilise pas...

[StringBuilder]

Difficile d'atteindre un compris.
En effet, on est dans les habitudes et les règles de nommage.

Personnellement, j'estime que ne pas préfixer les colonnes par un alias, c'est s'assurer que la requête va planter ou devenir impossible à faire évoluer : à la moindre modification de la requête, il faut réécrire toute la partie existante, avce le risque de se tromper d'alias au moment où on le rajoute. A la moindre modification du modèle des données, la requête peut subitement s'arrêter de fonctionner si on ajoute une colonne du même nom dans une autre table.

Par conséquent "pro_id" n'est pas plus lisible que "id" dans la mesure où dans les requêtes on aura systématiquement "pro.pro_id" ou "pro.id" : dans le cas du préfixe, l'info est redondante avec l'alias. Si demain dans une requête, j'ai des produits et des "gratuits", j'aurai donc deux alias : "pro" et "grt".
Au moment de faire ma jointure, "grt.pro_id" ne sera pas du tout naturel comme choix de clé primaire, alors que "grt.id" sautera aux yeux.
En effet, l'avantage de "id" tout court, c'est que je sais, par convention de nommage, que je suis sur ma clé primaire. Alors que "pro_id", je n'ai pas la moindre garantie que c'est bien la clé primaire de ma table produit : ça peut être une clé alternative, un membre d'une clé composée, etc. Alors si en plus on doit se coltiner un "pro_pk_id" pour avoir une chance de s'y retrouver, on court tout droit à l'usine à gaz : aucun développeur au monde ne sera capable de retenir les noms des colonnes même s'il n'y a que 3 tables.

Ensuite, appeler la table contenant les produits "t_pro_produit", t'es honnêtement, je n'en vois absolument pas l'intérêt. "produit" a l'avantage d'être plus court et intuitif. Si ma table des produits s'appelle "produit", je n'ai pas besoin d'un MPD pour taper dedans. Je n'ai pas non plus besoin de savoir que c'est une table ou une vue. Si je dois faire une mise à jour, j'aurai tout le loisir de :
- tester unitairement ma requête et me rendre compte si ça déconne
- regarder le MPD pour déterminer si c'est une vue ou non
- et si le DBA a bien fait son boulot, la vue est dotée des triggers nécessaires pour que du CRUD fonctionne dessus sans problème
=> Donc aucun intérêt de préfixer par un T ou un V tous les éléments. Comme ceux qui mettent le type de données dans le nom de la colonne...
Surtout le jour où on remodélise, et qu'on :
- transforme une table en vue (ou inversement)
- change le type d'une colonne
=> 100% des requêtes font référence à un nom qui n'est plus en phase avec le type d'objet requêté, et induit complètement le développeur en erreur.

Quand au court d'auto-complétion, j'utilise "cette bouse de management studio", et quand j'ai besoin de retrouver le nom d'une colonne dans ma table produit, j'ai juste à taper le nom de mon alias suivi d'un point et hop, j'ai toute la liste des colonnes de la table. C'est quand même plus simple que de taper "cli" et avoir la liste de tous les objets de la base de données qui commencent (ou contiennent ?) "cli", même s'ils n'ont rien à voir avec ma requête en cours d'écriture...

Sinon, moi ce qui me faire raisonner ainsi, c'est pas des MDP avec des trigramme la respectés (quoique), c'est avant tout avoir dû repasser pendant près de 20 ans derrière des gens qui n'aliasent rien, avec des requête de 50 lignes avec sous-jointures...
Dès que tu modifies le moindre truc, tout te pète à la gueule, et tu passes 3 heures à comprendre ce que fait la requête et d'où vient chaque colonne avant de pouvoir rajouter la moindre colonne dans le select ou critère dans le where (et je parle pas quand tu dois commencer à ajouter des auto-jointures).

[Invité]

Ok, alors j'ai travaillé ce soir dessus, donc pour l'instant, avant d'essayer les autres solutions proposées, je reste avec mon système de 3 tables, et j'ai donc créé ce trigger sur Mysql Workbench :

Code :

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

1
2
3
4
5
CREATE DEFINER=`root`@`localhost` TRIGGER reassortCarburant AFTER INSERT ON reassortcarburant
FOR EACH ROW
UPDATE stockcarburant
SET stockcarburant.volume = stockcarburant.volume + new.volume
WHERE stockcarburant.idciterne = new.idciterne

Le trigger est lui affecté sur la table reassortcarburant, qui est un "journal" de réassort carburant qui se remplit lors du réassort de carburant dans l'application:





Ca marche bien : Voici le résultat de ma table stockcarburant, après que le trigger ce soit exécuté, lors du réassort d'un carburant dans le front end. Le dépassement de capaMax Citerne est géré par le front end avec Javascript, du coup l'utilisateur ne peux pas dépasser la capacité maxi de la citerne lors du réassort :
Le résultat négatif sur une des citernes provient du fait que le trigger soustrayait et je l'ai modifié pour qu'il ajoute le volume de réassort après hi hi.
Le trigger mets donc à jour automatiquement le volume de carburant présent dans une citerne, en fonction du journal de réassort.





Donc je précise que je vais essayer les solutions proposées (Essayer de tout réduire à une table unique et utiliser une vue.)
J'aime quand même bien ce système parce qu'il me suffit de requêter en AJAX pour connaitre l'état de mes citernes(C'est à dire de connaitre le volume disponible restant en faisant le calcul citerneCapacitéMax - stockcarburant) et de le soumettre à l'application , sans avoir à calculer de vue. Il existe évidemment une table citerne récapitulant les caractéristiques d'une citerne, dont sa capacité maxi.
Je précise aussi m'être inspiré de ce code

[StringBuilder]

Attention toutefois à une chose :
Le danger des triggers, c'est avant tout de ne pas traiter tous les cas.

En effet, ici, vous ne gérez que le INSERT.

Que se passe-t-il si vous faire un UPDATE ou un DELETE dans votre journal (erreur de saisie, etc.)

De même, votre trigger permet visiblement d'arriver à une quantité négative.
Il faut peut-être dans ce cas se poser la question ce ce qu'il faut faire dans ce cas.

En effet, quand vous êtes à -100, que la citerne est (à priori) vide, et que vous remettez 1000 dans la citerne, vous avez 1000 et non 900 (en toute logique).