Discussion :

[Gennaker34]

Bonjour, je poste ici car je n'ai pas réussi à trouver les informations que je recherchais ailleurs !

Imaginons que je veuille construire une base de données qui me permette d'enregistrer des recettes de fondue.

J'ai :

une table fondue (ID, DATE, NB_PART, NOTE,...),

Ensuite je différencie dans deux tables distinctes des ingrédients qui possèdent des caractéristiques bien différentes pour les décrire.

une table vin (ID, NOM, ANNEE, CEPAGE_DOM, ROBE, ALCOOL,...)

une table fromage (ID, NOM, LABEL, ANIMAL, AFFINAGE,...)

Et c'est ensuite que je commence à coincer : comment construire une table ingrédients (ID_fondue, ID_ingredient {vin ou fromage du coup}, QUANTITE) qui me permette de faire le lien entre la table fondue et les tablesvin etfromage pour ensuite accéder facilement aux caractéristiques de ces différents ingrédients et que mes vin.ID et fromage.ID soient en quelque sorte des clés étrangères de cette tableingrédients.

J'ai pensé à contourner le problème en faisant une tableingrédient_vin (ID_fondue, ID_vin, QUANTITE) et une autreingredient_fromagemais cela ne me satisfait pas car cela multiplie les tables si je multiplie les "types d'ingrédients".

J'ai pensé à faire une seule table d'ingrédient en gardant des noms de colonnes génériques mais ce n'est pas satisfaisant et ne permet pas de facilement varier les types de données. Dans la même veine on pourrait aussi j'imagine faire une seule table d'ingrédients avec autant de colonnes que de caractéristiques différentes mais du coup entrer un fromage reviendrait à systématiquement laisser les cases relatives au vin NULL...

Bref, j'espère que je m'exprime assez clairement pour que vous puissiez m'aider et m'en remet à vous, débutant que je suis !

[al1_24]

C'est dans ce type de cas qu'une modélisation par héritage peut s'appliquer :

Ingredient(Id_Ingredient (PK), ... attributs communs à tous les ingrédients)
Fromage(Id_Ingredient(FK=Ingredient.Id_Ingredient, PK), ... attributs spécifiques au fromage)
Vin(Id_Ingredient(FK=Ingredient.Id_Ingredient, PK), ... attributs spécifiques au vin)
Composition(Id_Fondue(FK=Fondue.Id_Fondue), Id_Ingredient(FK=Ingredient.Id_Ingredient), Quantite)

[SQLpro]

Sur l'héritage, à me lire :
https://sqlpro.developpez.com/cours/...tion/heritage/

A +

[Gennaker34]

Merci à vos réponses qui m'ont éclairé et qui m'ont permis d'avancer sur ce point là !

À la lecture du lien que vous m'avez fourni, j'ai cependant quelques questions :

1) À l'insertion d'un ingrédient, j'imagine qu'il faut dans un premier temps insérer dans la table mère avant d'insérer dans la table fille. Mais comment fait-on pour récupérer le bon ID à l'insertion dans la table fille ?

2) À la suppression d'une entrée, est-ce possible de répercuter en cascade la suppression sur les tables filles ?

3) Ici, je me retrouve dans un cas d'héritage avec exclusion mutuelle (un ingrédients ne peut ici être à la fois du vin et du fromage) pour reprendre les termes de l'article. Concernant les triggers indiqués, leur code est donné en Transact SQL et je n'arrive pas à les adapter pour MySQL, auriez-vous des pistes ?

Merci encore par avance de votre aide !!

[SQLpro]

...
1) À l'insertion d'un ingrédient, j'imagine qu'il faut dans un premier temps insérer dans la table mère avant d'insérer dans la table fille. Mais comment fait-on pour récupérer le bon ID à l'insertion dans la table fille ?

Tout dépend du SGBDR que vous utilisez. Si c'est SQL Server, la fonction SCOPË_IDENTITY() renvoie le dernier autoincrément délivré dans votre session et dans le scope de code.

2) À la suppression d'une entrée, est-ce possible de répercuter en cascade la suppression sur les tables filles ?

Tout dépend de comment vous avez géré l'intégrité référentielle déclarative. Cela fonction parfaitement si vous avez mis le mode cascade.
À me lire : https://sqlpro.developpez.com/cours/...e=partie2#L7.3[QUOTE]

3) Ici, je me retrouve dans un cas d'héritage avec exclusion mutuelle (un ingrédients ne peut ici être à la fois du vin et du fromage) pour reprendre les termes de l'article. Concernant les triggers indiqués, leur code est donné en Transact SQL et je n'arrive pas à les adapter pour MySQL, auriez-vous des pistes ?

My SQL étant une grosse merde (et je pèse mes mots...) je ne sais même pas si c'est réalisable avec cette "chose".
À me lire : https://sqlpro.developpez.com/tutori...mysql-mariadb/

A +

[StringBuilder]

Tout dépend du SGBDR que vous utilisez. Si c'est SQL Server, la fonction SCOPË_IDENTITY() renvoie le dernier autoincrément délivré dans votre session et dans le scope de code.

Personnellement, depuis que j'ai découvert la clause "OUPUT", je n'utilise plus que ça.
https://docs.microsoft.com/fr-fr/sql...l-server-ver15
L'immense avantage, c'est qu'on peut du coup insérer plusieurs lignes d'un coup et récupérer les identifiants générés pour chaque ligne.

Tout dépend de comment vous avez géré l'intégrité référentielle déclarative. Cela fonction parfaitement si vous avez mis le mode cascade.
À me lire : https://sqlpro.developpez.com/cours/...e=partie2#L7.3

Certaines personnes trouvent que le mode CASCADE c'est le mal, et en effet ça peut être très dangereux : par exemple si vous supprimez un ingrédient, vous allez le retirer de toutes les recettes qui y font appel, sans le moindre avertissement.
Je vous laisse imaginer une compta où l'utilisateur supprime malencontreusement la monnaie "Euro".

Par conséquent, je préfère opter :
- soit pour des triggers, qui vont supprimer en cascade dans une sélection de table, mais pas d'autres, pour lesquelles je souhaite planter si elles ne sont pas vides
- soit pour des procédures de mises à jour/suppression, qui s'occupent de faire le même boulot
=> Je trouve ça plus souple et moins risqué.

[escartefigue]

Certaines personnes trouvent que le mode CASCADE c'est le mal, et en effet ça peut être très dangereux : par exemple si vous supprimez un ingrédient, vous allez le retirer de toutes les recettes qui y font appel, sans le moindre avertissement.
Je vous laisse imaginer une compta où l'utilisateur supprime malencontreusement la monnaie "Euro".

Non seulement c'est dangereux fonctionnellement mais aussi techniquement : la largeur et la profondeur de la cascade peuvent être telles que le nombre considérable de mises à jour peut mettre par terre la CPU.

[SQLpro]

Personnellement, depuis que j'ai découvert la clause "OUPUT", je n'utilise plus que ça.
https://docs.microsoft.com/fr-fr/sql...l-server-ver15
L'immense avantage, c'est qu'on peut du coup insérer plusieurs lignes d'un coup et récupérer les identifiants générés pour chaque ligne.

pour plusieurs ligne souk, mais pour une ligne, cas fréquent, c'est TRES lourd…..

Certaines personnes trouvent que le mode CASCADE c'est le mal, et en effet ça peut être très dangereux : par exemple si vous supprimez un ingrédient, vous allez le retirer de toutes les recettes qui y font appel, sans le moindre avertissement.
Je vous laisse imaginer une compta où l'utilisateur supprime malencontreusement la monnaie "Euro".

Là tu déconne, parce que c'est un mode à panacher. Si je crée une personne avec une table des téléphones, une autre des emails et une troisième des adresse, je met du DELETE CASCDE. mais je ne mettrait pas du delete cascade sur ses commandes, ses factures…. Là encore question de perf c'est le jour et la nuit comparé à un déclencheur !

Par conséquent, je préfère opter :
- soit pour des triggers, qui vont supprimer en cascade dans une sélection de table, mais pas d'autres, pour lesquelles je souhaite planter si elles ne sont pas vides
- soit pour des procédures de mises à jour/suppression, qui s'occupent de faire le même boulot
=> Je trouve ça plus souple et moins risqué.

A +

[StringBuilder]

Là tu déconne, parce que c'est un mode à panacher. Si je crée une personne avec une table des téléphones, une autre des emails et une troisième des adresse, je met du DELETE CASCDE. mais je ne mettrait pas du delete cascade sur ses commandes, ses factures…. Là encore question de perf c'est le jour et la nuit comparé à un déclencheur !

A +

Hmmmm, c'est vrai que le CASCADE se contrôle au niveau de la foreign key et non du DELETE...

Je suis déformé par ma première vidange de base accidentelle (avec rollback segment fault + crash du serveur sinon c'est pas drôle) sous Oracle 7.3
=> Je ne sais pas si ça a évolué, mais à l'époque c'était le DELETE qui pilotait le CASCADE avec l'option "cascade constraints". Et là, bah pas le choix des relations cascadées. Le mal absolu.

Depuis je suis resté sur ce traumatisme

[SQLpro]

C'est d'ailleurs une des raisons pour laquelle SQL Server s'est interdit de prévoir le mode cascade dans le DDL. Pour information dans le DDL tu peut faire un DROP SCHEMA toto CASCADE…

A +