On Mon, 23 Sep 2002 16:00:06 +0200 (CEST) Vincent Renardias <[EMAIL PROTECTED]> wrote:
> > > > MySQL ne supporte pas les 'subselects' (ie: "select champ1,champ2 from > > > table where champs2 in (select champ3 from table2 where condition)"), et > > > pour beaucoup d'applications c'est indispensable. > > > > Bof, dans quels cas c'est vraiment indispensable ? On peut toujours faire > > autrement, notamment avec des tables temporaires. > > C'est indispensable dans bcp de cas, car ca permet de simplifier bcp le > code et c'est souvent bcp plus rapide que de faire plusieurs requetes > successives... > > > J'ai boss� dans une bo�te sur une grosse base du genre 500 tables et 3000 > > proc�dures, les subselects �taient carr�ment interdits. > > je n'ai qu'une vingtaine de tables dans ma plus grosse DB (PostgreSQL), > certaines d'entre elles comportent plusieurs millions d'entr�es, et avec > les bons index aux bons endroits, les subselects se passent tres > bien, et heureusement: je me vois mal faire des tables temporaires avec > des 3 gigas de donn�es... L'argument est bidon parce qu'en interne quand tu fais un subselect il doit cr�er une table temporaire, tu peux toujours remplacer : select ... from a,... where a.x in (select ...) ... par : select ... into #x select ... from a,#x,... where #x.col=a.col drop table #x Et encore la plupart des cas simples une phase interm�diaire n'est pas indispensable, ca peut souvent se faire avec une seule jointure, m�me si ca para�t plus facile avec un subselect ca peut �tre nul pour les performances, donc interdire les subselects a au moins le m�rite d'�viter aux d�butants de faire des conneries. Une discussion des hackers de postgresql avant que ca soit impl�ment� : http://www.geocrawler.com/archives/3/12/1997/10/0/29796/ Quand c'est bien utilis� ca peut donner un code plus court mais ca ne change rien du point de vue des performances et ca n'est jamais bloquant, sinon je voudrais voir un exemple et pas du fud. Et puis les diff�rences entre MySQL et PostgreSQL c'est dans le manuel de MySQL. Alain
