[MySQL]1 ou 2 requêtes pour un "maitre détail"

[Ter Rowan]

Coucou

je me pose certainement une question très bête mais bon...

Supposons une table maître (de référence)
id objet / info 1 / info 2 / info 3

la clef étant id objet

et une table détail
id objet / type / valeur

la clef étant id objet + type

Imaginez une recette de cuisine
dans maitre, l'id, le temps de préparation, le temps de cuisson, la température du four
dans détail, les ingrédients, leur quantité



quand je crée une instance d'objet, j'ai forcément besoin des info 1 2 3 ET des enregistrements type/valeur. Je n'aurai jamais besoin que de l'un ou de l'autre

la question est donc la suivante, dois je récupérer les données par deux requetes (SELECT __ FROM maitre WHERE id...) et (SELECT __ FROM detail WHERE id...)

ou une seule : (SELECT __ FROM maitre , detail WHERE id = id AND ...)

Info complémentaire pour le contexte
le nombre d'enregistrements de maitre devrait tourner entre 100 et 400
le nombre d'enregistrements de détail devrait tourner entre 400 et 4000

pour les champs, dans les deux cas, des entiers, avec moins d'une dizaine de colonnes par table

Merci d'avance !

[Sephi-Chan]

Si ça peut t'aider, le choix qu'on fait les développeurs de Ruby on Rails est le suivant :

recipes = Recipes.includes(:ingredients)

Le framework va récupérer toutes les recettes avec une première requête, puis il va récupèrer les ingrédients avec une condition IN(...) (en spécifiant les id des recettes récupérées dans la première requête.

Et la variable contient un tableau d'objets Recipe, qui ont chacun un attribut ingredients qui contient un tableau d'objets Ingredient.


Sephi-Chan

[Ter Rowan]

Si ça peut t'aider, le choix qu'on fait les développeurs de Ruby on Rails est le suivant :

recipes = Recipes.includes(:ingredients)

Le framework va récupérer toutes les recettes avec une première requête, puis il va récupèrer les ingrédients avec une condition IN(...) (en spécifiant les id des recettes récupérées dans la première requête.

Et la variable contient un tableau d'objets Recipe, qui ont chacun un attribut ingredients qui contient un tableau d'objets Ingredient.


Sephi-Chan

merci ^^

ben j ai développé la même chose, c'est cool ça ^^ (bon a part l'histoire des requetes, je n'étais pas sur et que j'appelle mais "détails" "module")

si pas de contre avis d'ici demain soir je validerais cette solution

[Kihmé]

je trouve tes deux tables bizarrement faites, personnellement je n'aurais pas construit mes tables comme toi. Ceci dit pour ce genre de cas le curseur ça peut être bien, non?

Edit : en relisant ton poste je lis que j'ai mal compris tes tables semblent bien, c'est juste que tu dois avoir une table ingrédient quelque part, non? Ta table details c'est ta table issue de la relation n, n? Par contre l'idée du curseur ça me semble bien, tu le fais dans une procédure stockée

[Ter Rowan]

effectivement la référence des ingrédients (type) est dans une autre table par contre je ne vois pas l'intérêt du curseur dans le cas présent (je ne suis pas familier des curseurs faut dire)

globalement j'ai besoin de récuperer les ingrédients d'une recette, ça se fait avec un simple SELECT, pour moi le curseur ne devrait servir que lors de traitement de masse, et encore non ?

[cyberbobjr]

Bonjour,
je vais peut-être dire une bêtise mais une requête SELECT avec une jointure à gauche serait efficace non ?

[Argorate]

Si on reprend ton exemple, je pense que la bonne solution devrait ressembler à ça:

Une table "recette" {id_recette, info1, info2..}
Ainsi qu’une table "ingrédient" {id_ingrediant, autre info } (utile que si tu as des infos a y mettre)
Et puis une table qui fait le lien:
"ingrediant_recette" {id_recette, id_ingrediant, qte}

Qu'es ce que tu en penses? Si ce que tu appel "type" corespond a l'ingrediant, alors t'as structure ressemble a ce que je viens de dire^^

[Ter Rowan]

Si on reprend ton exemple, je pense que la bonne solution devrait ressembler à ça:

Une table "recette" {id_recette, info1, info2..}
Ainsi qu’une table "ingrédient" {id_ingrediant, autre info } (utile que si tu as des infos a y mettre)
Et puis une table qui fait le lien:
"ingrediant_recette" {id_recette, id_ingrediant, qte}

Qu'es ce que tu en penses? Si ce que tu appel "type" corespond a l'ingrediant, alors t'as structure ressemble a ce que je viens de dire^^

ma question n'est pas sur le modèle de données (c'est bien ça type = ingrédient dans l'exemple) mais sur la récupération des données

une seule requête jointure ou deux requêtes séparées (avec les filtres qui vont bien) ?

---

Bonjour,
je vais peut-être dire une bêtise mais une requête SELECT avec une jointure à gauche serait efficace non ?

bah justement c'est bien la question, une requête sur les deux tables (donc dupplication des données {info 1; info 2, etc...} dans le résultat) est elle plus pertinente que 2 ?

[pascal]

Info complémentaire pour le contexte
le nombre d'enregistrements de maitre devrait tourner entre 100 et 400
le nombre d'enregistrements de détail devrait tourner entre 400 et 4000

Je retourne la question :
Est-ce pertinent de renvoyer autant d'infos via une (ou deux) requête ?
C'est pour quelle utilisation ?
Et la pagination dans tout ça ?

A+

Pascal

[cyberbobjr]

bah justement c'est bien la question, une requête sur les deux tables (donc dupplication des données {info 1; info 2, etc...} dans le résultat) est elle plus pertinente que 2 ?

Si on se base sur les performances, une seule requête SQL sur 2 tables est plus performant que deux requêtes puis traitement derrière.
Essaye de faire un benchmark et choisi la plus rapide (donne les résultats par la même occasion ), mais mon instinct me donne la requête SQL unique vainqueur.