Comment optimiser une requête SELECT sur une multitude de tables ?
Bonjour à tous !
Voilà j'ai une base de données sous la forme:
OBJET(idObj, nomObj, descObj, ...)
CARAC(idCarac, #idObj, nomCarac, descCarac, valeurCarac, ...)
INGREDIENT(idIng, #idObj, nomIng, descIng, quantiteIng, ...)
Un objet peut avoir 0 ou N caracs
Un objet peut avoir 1 ou X ingrédients
Si je veux récupérer le détail d'un objet, disons l'objet numéro 67, je fais une 1ère requête pour récupérer les informations de la table Objet (qui fonctionne un peu comme une table header):
Code:
SELECT idObj, nomObj, descObj, ... FROM OBJET WHERE idObj = 67;
Ensuite je fais une 2ème requête pour récupérer les informations de la table Carac (qui fonctionne un peu comme une table items):
Code:
SELECT idCarac, nomCarac, descCarac, valeurCarac FROM CARAC where idObj = 67;
Ensuite je fais une 3ème requête pour récupérer les informations de la table Ingredient (qui fonctionne aussi un peu comme une table items):
Code:
SELECT idIng, nomIng, descIng, quantiteIng FROM INGREDIENT where idObj = 67;
Cela me fait donc 3 requêtes SQL pour récupérer les informations d'un objet.
Maintenant disons que j'ai besoin de récupérer un ensemble d'objets.
J'effectue les requêtes suivantes:
1ère requête pour récupérer les informations de la table Objet (qui fonctionne un peu comme une table header):
Code:
SELECT idObj, nomObj, descObj, ... FROM OBJET WHERE idObj IN (67, 68, 69, 70);
Ensuite je fais une 2ème requête pour récupérer les informations de la table Carac (qui fonctionne un peu comme une table items):
Code:
SELECT idCarac, idObj, nomCarac, descCarac, valeurCarac FROM CARAC where idObj IN (67, 68, 69, 70);
Ensuite je fais une 3ème requête pour récupérer les informations de la table Ingredient (qui fonctionne aussi un peu comme une table items):
Code:
SELECT idIng, idObj, nomIng, descIng, quantiteIng FROM INGREDIENT where idObj IN (67, 68, 69, 70);
J'ai déjà pensé à créer une vue avec jointures mais je vois pas trop comment la faire car si je récupère dans la même vue les informations de OBJET, CARAC et INGREDIENT, je vais me retrouver avec les champs de OBJET répétés N fois (N Caracs) ou X fois (X Ingrédients) et puis ça paraît bien bancale car on aura max(N, X) lignes.
- Y a t-il un meilleur moyen de récupérer les informations d'un objet ou d'un ensemble d'objets que mes 3 requêtes citées plus haut ?
- Serait-il judicieux de passer par des vues formées de jointures, si oui lesquelles ?
Maintenant pour compliquer un peu les choses, j'ai besoin de faire des SELECT sur plusieurs critères d'objets. Par exemple, il arrive d'avoir besoin de trouver l'objet dont:
- nomObj LIKE 'foo%'
- ( (nomCarac = A ET valeurCarac > 5) ET (nomCarac = B ET valeurCarac > 10) ) OU ( (nomCarac = C ET valeurCarac > 10) ET (nomCarac = D ET valeurCarac > 20) )
La seule façon que j'ai trouvé pour rechercher un tel objet dans mes tables c'est:
Faire une 1ère requête sur la table OBJET:
Code:
SELECT idObj FROM OBJET WHERE nomObj LIKE 'foo%';
Puis faire une 2ème requête sur la table CARAC:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| SELECT idObj FROM CARAC
WHERE idObj IN ("resultat Requête 1")
AND
(
(nomCarac = A AND valeurCarac > 5)
OR
(nomCarac = B AND valeurCarac > 10)
)
GROUP BY idObj
HAVING count(idObj) = 2
UNION
SELECT idObj FROM CARAC
WHERE idObj IN ("resultat Requête 1")
AND (
(nomCarac = C AND valeurCarac > 10)
OR
(nomCarac = D AND valeurCarac > 20)
)
GROUP BY idObj
HAVING count(num) = 2 |
Cela me donne donc tous les IdObj qui remplissent les critères définis par l'utilisateur, et ensuite je peux faire mes 3 requêtes énoncées au début du message pour récupérer l'ensemble des informations de chaque objet.
Seulement je trouve cette méthode très lourde. Beaucoup de requêtes pour arriver à mes fins, et je ne parle pas du casse-tête pour générer dynamiquement ce genre de requêtes dans un langage comme PHP.
- Voyez-vous une façon plus simple et plus optimisée peut être de faire tout ça ?
Merci énormément pour ceux qui auront pris le temps de me lire et de me donner leurs conseils :)
Cordialement.
