Hello
 
Voilà j'ai un petit problème en mysql, que je n'arrive pas à resoudre, et que j'aimerais résoudre proprement sans avoir a recourir à plein de requête et du traitement en PHP.
 
J'ai 2 tables : pour les RUBRIQUES et les SOUS-RUBRIQUES
 

Une sous-rubrique a son champ *subrub* a la valeur *rub* de sa rubrique parente.
 
Quand je veux donc lister mes rubriques/sous rubriques, je fais une requête comme ça (avec une jointure simple)

 
Par contre, j'aimerais trouver les rubriques qui ne contiennent pas de sous rubriques, et là je ne sais pas du tout comment faire.
Peutetre avec un WHERE...COUNT ?
J'ai cherché sur google sans trouver grand chose pour l'instant
 
Si quelqu'un a une idée, ce serait sympa

Qqch comme ca devrait fonctionner :

SELECT * FROM rub WHERE rub NOT IN (SELECT DISTINCT subrub FROM sub)

Merci, c'est bien ça
Ca fonctionne !

en plus efficace, en détournant LEFT OUTER JOIN :

SELECT *
FROM run
LEFT OUTER JOIN sub ON subrub.sub = rub.rub
WHERE subrub.subrub IS NULL

Sinon, tu veux au final récupérer l'arborescence de tes données via une seule requête, non ? (c'est à dire récupérer tous les niveaux de rubriques en une passe ?)
 
Si oui, cet article sur le site de MySQL promet enfin le support de "CONNECT BY ... PRIOR" dans la version 5.1
http://dev.mysql.com/doc/refman/5. [...] uture.html
 
Et d'après cet autre article, il semblerait que ce soit chose faite (c'était promis depuis la 4.1, donc y n'y croyait plus)
http://rpbouman.blogspot.com/2005/ [...] olved.html
 
Dans le cas contraire, il reste toujours les solutions pourries utilisée jusque là :
http://dev.mysql.com/tech-resource [...] -data.html
 
Si MySQL supporte effectivement "CONNECT BY ... PRIOR" dans la version 5.1, alors je trouve TRES FORT REGRETTABLE que la syntaxe Oracle, qui n'est absolument pas standard, aie été retenue aux détriments de la syntaxe parfaitement standard utilisée par SQL Server : les CTE (common table expression)
http://www.thescripts.com/forum/thread183346.html
 
J'avais trouvé ici http://forum.hardware.fr/hfr/Progr [...] 2813_1.htm un très bon article extrêment clair qui expliquait en détail les CTE, mais maintenant faut s'enregistrer pour voir l'article (grrr)
http://www.sqlservercentral.com/ar [...] 2005/1846/
 
Quoique la doc de SQL Server est très bien fait en fait...
http://msdn2.microsoft.com/fr-fr/library/ms175972.aspx
 
Avant de tester la syntaxe avec connect by, tente celle-ci, qui a le mérite d'être absolument standard et supportée par d'autres SGBD non goretisants, tels que pgSQL

Merci pour ce complément d'info
En effet, a bien d'autres endroits, ça m'arrangerait de pouvoir recuperer TOUTES les Rubriques (Soit Vide, Soit Avec Sous rubriques et donc les SOUS RUBRIQUES) en une seule requete
 
Je regarderai ça plus en détail demain, là faut que j'aille dormir
 
Bonne soirée

Bon, pour rester compatible avec les vieilles versions (vu que c'est pour du mutu) je vais me concentrer sur ton lien la :
http://dev.mysql.com/tech-resource [...] -data.html
 
Faut que je revois un peu les LEFT JOIN pour y arriver, en general moi je fais mes jointures betement et simplement t1.xxx = t2.yyy sans me prendre la tete
 
A+

Les nested set ça a jamais été une solution pourrie
 
C'est la seule vraie méthode pour stocker des données hierarchisées et pouvoir remonter la structure complète en une requête sans connaitre la profondeur de l'arbre.
 
 

sauf que les nested posent deux problèmes majeurs :
- les liens de dépendance sont figés. c'est à dire qu'il est impossible de déplacer un noeud dans l'arbre, pas plus qu'il est aisé d'ajouter de nouveaux noeuds, de chemins alternatifs, etc. c'est parfait pour un faible volume d'informations statiques (menus d'un site par exemple), mais en aucun cas pour réseau complexe (recherche de chemin le plus court entre deux gares par exemple)
- la racine est figée, tu ne peux pas travailler dans un graph à proprement parler, uniquemement dans un arbre
 
c'est pour cette raison que pour moi cette solution reste "pourrie", au vue des possibilités offertes par SQL99 ou la syntaxe d'Oracle
 
en gros, t'as une table avec un nuage de villes, et des liens entre différentes villes paris-dijon : 300 km ; dijon-lyon : 200 km ; lyon-marseille : 200 km ; paris - le mans : 200km
 
à compter que tu choisi paris comme point d'entrée tu es incapable de déterminer un chemin du mans à dijon par exemple, ce que permettent SQL99 et le connect by d'Oracle

tu veux dire c'est bien/conseillé pour un truc avec des rubriques/sous-rubriques par exemple?

qui peut le plus peut le moins, ça sert à rien de s'encombrer la tête avec des bidouillages quand des solutions propres et robustes existent

Sauf qu'elle nécessite un hebergeur dernier cri

 
Tres interessant. Je ne connaissais pas cet notion de hiérarchie. Je lirais les articles quand j'aurai un peu plus de temps.  
Merci bcp pour les liens