select from *2 tables* where *pas jointées* [mysql] - SQL/NoSQL - Programmation
Marsh Posté le 20-02-2008 à 23:38:19
Qqch comme ca devrait fonctionner :
Code :
|
Marsh Posté le 20-02-2008 à 23:49:11
Merci, c'est bien ça
Ca fonctionne !
Marsh Posté le 21-02-2008 à 00:04:38
en plus efficace, en détournant LEFT OUTER JOIN :
Code :
|
Marsh Posté le 21-02-2008 à 00:19:05
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
Marsh Posté le 21-02-2008 à 00:33:11
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
Marsh Posté le 24-02-2008 à 18:50:27
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+
Marsh Posté le 25-02-2008 à 09:52:02
MagicBuzz a écrit : Dans le cas contraire, il reste toujours les solutions pourries utilisée jusque là : |
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.
Marsh Posté le 25-02-2008 à 19:01:26
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
Marsh Posté le 25-02-2008 à 19:13:41
MagicBuzz a écrit : 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) |
tu veux dire c'est bien/conseillé pour un truc avec des rubriques/sous-rubriques par exemple?
Spoiler : comme dans le sujet en fait |
Marsh Posté le 25-02-2008 à 21:34:25
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
Marsh Posté le 25-02-2008 à 22:09:06
Sauf qu'elle nécessite un hebergeur dernier cri
Marsh Posté le 25-02-2008 à 23:35:13
MagicBuzz a écrit : 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 ?) |
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
Marsh Posté le 20-02-2008 à 23:24:44
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
---------------
A VENDRE: Razer Chroma ARGB Controller / Boitier / Support Triple Screen / Ventirad / Carte USB3