Compréhension SQL : jointures et "doublons" [Résolu]

[buxbux]

Bonjour,

Je développe dans le web depuis plusieurs année et me sert du langage SQL régulièrement. J'ai cependant très souvent utilisé les SGBDR de manière simple sans vraiment optimiser au mieux mes requêtes. Celà a cause de mon manque de connaissance dans l'usage avancé des SGBDR.

Aujourd'hui j'aimerais me débloquer sur la notion que je vais présenter ci-dessous.

Contexte: Trois table:

Code :

1
2
3
4
 
element:      [id, name]
elements_tag: [id, element_id, tag_id]
tag:          [id, name]

Lorsque j'effectue cette requête,

Code :

1
2
3
4
5
6
7
 
SELECT e.id AS eid, e.name AS ename, t.name AS tname
FROM element e
LEFT JOIN elements_tag et
  ON e.id = et.element_id 
LEFT JOIN tag t
  ON t.id = et.tag_id

disons que mon retour est:

Code :

1
2
3
4
5
6
7
8
eid    ename    tname
1    voiture    deplacer
1    voiture    moteur
2    velo       deplacer
3    porte      ouvrir
3    porte      bois
4    bureau      poser
4    bureau      bois

J'ai bien mes éléments et les tags qui y sont associés. Avec ça je peux hydrater mes objets dans mon programmes.

Ma question désormais est comment puis-je limiter ma requête a un certains nombre d’éléments et non a un certains nombre de résultats.
Si je rajoute une LIMIT a ma requête:

Code :

1
2
3
4
5
6
7
8
 
SELECT e.id AS eid, e.name AS ename, t.name AS tname
FROM element e
LEFT JOIN elements_tag et
  ON e.id = et.element_id 
LEFT JOIN tag t
  ON t.id = et.tag_id
LIMIT 3

Je limite mon nombre de résultats:

Code :

1
2
3
4
eid    ename    tname
1    voiture    deplacer
1    voiture    moteur
2    velo       deplacer

Or mon souhait est de limiter le nombre "d'élément" pour qu'en quelque sorte le résultats ressemble à:

Code :

1
2
3
4
5
6
eid    ename    tname
1    voiture    deplacer
1    voiture    moteur
2    velo       deplacer
3    porte      ouvrir
3    porte      bois

(3 e.id différents)

Est-ce possible en SQL ?

[CinePhil]

element: [id, name]
elements_tag: [id, element_id, tag_id]
tag: [id, name]

Déjà, id est inutile dans la deuxième table qui est une table associative. La clé primaire de cette table devrait être composée des identifiants des deux tables associées.

Or mon souhait est de limiter le nombre "d'élément"

Si tu veux 3 eid, comme element.id est semble t-il auto-incrémenté (ce qui est une bonne chose), il suffit de demander les eid < 4 mais j'ai l'impression que ce n'est pas vraiment ce que tu souhaites car tu n'aurais toujours que les 3 premiers eid.

Veux-tu 3 éléments au hasard et tous les tags associés à ces éléments ?

[buxbux]

Envoyé par CinePhil

Déjà, id est inutile dans la deuxième table qui est une table associative. La clé primaire de cette table devrait être composée des identifiants des deux tables associées.

Ok

Envoyé par CinePhil

Veux-tu 3 éléments au hasard et tous les tags associés à ces éléments ?

Non pas au hasard, je ne l'ai pas mis dans mon exemple mais des filtres peuvent intervenir pour choisir les éléments à récupérer.

Donc je cherche à récupérer 3 éléments en fonction de critères (par exemple avec un WHERE e.name LIKE 'a%') ainsi que tous les tags associés.

[CinePhil]

Tu veux dire qu'avec ton LIKE, plus de trois éléments sont susceptibles d'être retournés par la requête et tu ne veux que les trois premiers ?

Code :

1
2
3
4
5
6
7
8
9
10
11
SELECT e.id AS eid, e.name AS ename,
	t.id AS tid, t.name AS tname
FROM element e
INNER JOIN element_tag et ON et.element_id = e.id
	INNER JOIN tag t ON t.id = et.tag_id
WHERE e.id IN (
	SELECT id
	FROM element
	WHERE name LIKE 'a%'
	LIMIT 3
)

[buxbux]

Envoyé par CinePhil

Tu veux dire qu'avec ton LIKE, plus de trois éléments sont susceptibles d'être retournés par la requête et tu ne veux que les trois premiers ?

Exactement. Je suis obligé de passer par une requête imbriquée ?

[CinePhil]

Tu peux aussi faire une jointure sur la sous-requête mais en quoi la "requête" imbriquée te pose problème ?

[buxbux]

Je crois que j'ai été traumatisé à une période par une personne me répétant que si on écrivait une requête imbriquée c'est que l'on pouvait mieux écrire sa requête. Mais je te confie que ton exemple de requête imbriquée colle parfaitement à mon problème en production.

Merci en tout cas de m'avoir rappelé que les sous-requêtes sont là aussi pour ce genre de nécessités

Ps: Bon maintenant faut que j'arrive à mettre un LIMIT à la sous-requête .. dans doctrine héhé.

[CinePhil]

Envoyé par buxbux

Ps: Bon maintenant faut que j'arrive a mettre un LIMIT à la sous requête .. dans doctrine héhé.

Ne te laisse pas imposer la dictature de Doctrine. Fais lui exécuter la requête en SQL Natif. Tu perdrais ton temps pour rien à traduire cette requête dans le pseudo SQL de cette saloperie d'ORM.

[buxbux]

Envoyé par CinePhil

Ne te laisse pas imposer la dictature de Doctrine. Fais lui exécuter la requête en SQL Natif. Tu perdrais ton temps pour rien à traduire cette requête dans le pseudo SQL de cette saloperie d'ORM.

C'est tentant oui ... Mais d'un coté au sein du framework que j'utilise (symfony2) tout est bien imbriqué et l'utilisation de l'ORM a son avantage.
Mais c'est vrai que pour des requêtes de ce type Doctrine casse les coui**es sévère ^^

[Waldar]

Si vous êtes limité par l'ORM, n'hésitez pas à mettre votre requête dans une vue.

[SQLpro]

Envoyé par buxbux

Je crois que j'ai été traumatisé a une période par une personne me répétant que si on écrivais une requête imbriqué c'est que l'on pouvait mieux écrire sa requête.

Cette personne est sans aucun doute un imbécile, mais il est probable que sa bêtisé à été la conséquence de l'endoctrinement des pro MySQLite.

En effet, MySQL a longtemps été incapable de faire des sous requêtes et prétendait que toute sous requête pouvait être écrite à base de jointures. Ce qui est bien entendu totalement faux ! Lire mon cours sur SQL ou mieux, potasser mon bouquin...

Voila le résultat désastreux et pervers de l'utilisation aveugle de MySQL, qui rappelons le au passage n'est ps réellement un SGBD relationnel... http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/

A +

[SQLpro]

Envoyé par buxbux

C'est tentant oui ... Mais d'un coté au sein du framework que j'utilise (symfony2) tout est bien imbriqué et l'utilisation de l'ORM a son avantage.
Mais c'est vrai que pour des requêtes de ce type Doctrine casse les coui**es sévère ^^

Et pour en rajouter une couche, lisez ce que j'ai écrit sur les ORM... vous verrez que non seulement :
1) vous pouvez vous en passer
2) vous développerez beaucoup plus vite !

A +

[buxbux]

Voila le résultat désastreux et pervers de l'utilisation aveugle de MySQL, qui rappelons le au passage n'est ps réellement un SGBD relationnel...

J'en apprend chaque jours un peu plus ^^
J'utilise PostgreSQL en remplacement de MySQL depuis un moment. Je vais tout de même lire votre article.

Et pour en rajouter une couche, lisez ce que j'ai écrit sur les ORM... vous verrez que non seulement :
1) vous pouvez vous en passer
2) vous développerez beaucoup plus vite !

J'ai du mal a pouvoir penser qu'au sein d'un développement appuyé par un framework il soit plus judicieux de se passer de l'ORM embarqué. Je met votre article de coté pour le consulter bientôt il éveille ma curiosité tout de même ^^