[mysql] select from *2 tables* where *pas jointées*

select from *2 tables* where *pas jointées* [mysql] - SQL/NoSQL - Programmation

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
 

Code :
  1. CREATE TABLE rub (
  2.   rub int(9) NOT NULL AUTO_INCREMENT PRIMARY KEY,
  3.   rubname text NOT NULL
  4. );
  5. CREATE TABLE sub (
  6.   sub int(9) NOT NULL AUTO_INCREMENT PRIMARY KEY,
  7.   subname text NOT NULL,
  8.   subrub int(9) NOT NULL
  9. );


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)

Code :
  1. SELECT rubname,subname FROM rub,sub WHERE subrub = rub


 
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 :jap:


---------------
A VENDRE: Razer Chroma ARGB Controller / Boitier / Support Triple Screen / Ventirad / Carte USB3
Reply

Marsh Posté le 20-02-2008 à 23:24:44   

Reply

Marsh Posté le 20-02-2008 à 23:38:19    

Qqch comme ca devrait fonctionner :

Code :
  1. SELECT * FROM rub WHERE rub NOT IN (SELECT DISTINCT subrub FROM sub)



---------------
Feedback : http://forum.hardware.fr/hfr/Achat [...] 2666_1.htm
Reply

Marsh Posté le 20-02-2008 à 23:49:11    

Merci, c'est bien ça
Ca fonctionne ! :jap:


---------------
A VENDRE: Razer Chroma ARGB Controller / Boitier / Support Triple Screen / Ventirad / Carte USB3
Reply

Marsh Posté le 21-02-2008 à 00:04:38    

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

Code :
  1. SELECT *
  2. FROM run
  3. LEFT OUTER JOIN sub ON subrub.sub = rub.rub
  4. WHERE subrub.subrub IS NULL


Message édité par MagicBuzz le 21-02-2008 à 00:04:59
Reply

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

Message cité 2 fois
Message édité par MagicBuzz le 21-02-2008 à 00:23:05
Reply

Marsh Posté le 21-02-2008 à 00:33:11    

Merci pour ce complément d'info :jap:
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


---------------
A VENDRE: Razer Chroma ARGB Controller / Boitier / Support Triple Screen / Ventirad / Carte USB3
Reply

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+ :hello:


---------------
A VENDRE: Razer Chroma ARGB Controller / Boitier / Support Triple Screen / Ventirad / Carte USB3
Reply

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à :
http://dev.mysql.com/tech-resource [...] -data.html


Les nested set ça a jamais été une solution pourrie [:w3c compliant][:w3c compliant][:w3c compliant]
 
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.
 
 


---------------
Software and cathedrals are much the same - first we build them, then we pray.
Reply

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

Message cité 1 fois
Message édité par MagicBuzz le 25-02-2008 à 19:02:05
Reply

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 :o



Message édité par anapajari le 25-02-2008 à 19:14:25

---------------
Software and cathedrals are much the same - first we build them, then we pray.
Reply

Marsh Posté le 25-02-2008 à 19:13:41   

Reply

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 :o

Reply

Marsh Posté le 25-02-2008 à 22:09:06    

Sauf qu'elle nécessite un hebergeur dernier cri ;)


---------------
A VENDRE: Razer Chroma ARGB Controller / Boitier / Support Triple Screen / Ventirad / Carte USB3
Reply

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 ?)
 
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


 
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  :jap:  

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed