Reprise du message précédent :

 
Outer retourne les enregistrements d'un table même s'ils n'ont pas de correspondance dans l'autre.
 
ça permet de faire des jointures externes pour remplacer des sous-requêtes couteuses, en ajoutant des clauses where qui ont l'air stupides :
 

SELECT count(i.cod_ind)
FROM individu i JOIN ins_adm_etp iae ON (iae.cod_ind = i.cod_ind)
     LEFT OUTER JOIN ins_adm_etp iae2 ON 
        (iae2.cod_ind = i.cod_ind 
            AND iae2.cod_anu = 2008 
            AND iae2.eta_iae = 'E' 
            AND iae2.cod_cmp IN (600, 700, 420, 400)
        )
WHERE iae.eta_iae = 'E'
AND iae.cod_cmp IN (600, 700, 420, 400)
AND iae.cod_anu IN (2007, 2006, 2005)
AND iae2.cod_ind IS NULL;

 
au lieu de  
 

SELECT count(i.cod_ind)
FROM individu i JOIN ins_adm_etp iae ON (iae.cod_ind = i.cod_ind)
WHERE iae.eta_iae = 'E'
AND iae.cod_cmp IN (600, 700, 420, 400)
AND iae.cod_anu IN (2007, 2006, 2005)
AND NOT EXISTS (
    SELECT 1 
    FROM individu i2 JOIN ins_adm_etp iae2 ON (iae2.cod_ind = i2.cod_ind)
    WHERE iae2.cod_anu = 2008 
    AND iae2.eta_iae = 'E' 
    AND iae2.cod_cmp IN (600, 700, 420, 400)
    AND i.cod_ind = i2.cod_ind
    );

http://en.wikipedia.org/wiki/Join_(SQL)

SELECT foo FROM mytable INNER JOIN (VALUES mes_valeurs) AS tmp (bar) ON mytable.foo = tmp.bar

ouais, je viens de lire aussi à l'instant
 

je reviendrais pas dessus... si j'insiste sur ce genre de truc, c'est pas par intégrisme ou prosélytisme, c'est juste que j'ai eu l'occasion de faire les frais d'une suppression de ce genre par un ex-collègue un peu trop zélé qui ne connaissait rien aux jointures (ni au SQL d'ailleurs) et qui a jugé, dans une requête assez conséquente, que supprimer 4 jointures "WHERE" ne ferait pas de mal car il ne comprenait pas leur utilité.
 
résultat : un week end complet passé à réparer ses conneries. la requête comportait une dizaine de tables jointes, chaque table comportant plusieurs centaines de milliers d'enregistrements (plusieurs millions pour certaines). ça a bien évidemment bousillé le serveur, qu'il a fallu redémarrer, avec toutes les contraintes qui vont avec (plusieurs sites connectés dessus, dont certains à l'étranger, pour lesquels il a fallu réveiller les admins à cause du décalage horaire, etc...), mais également le serveur Oracle (le logiciel), que j'ai du réinstaller et reconfigurer de A à Z et enfin la base qui n'a pas libéré quelques milliers de transactions en cours au moment de la coupure, ainsi que des curseurs. et restaurer une sauvegarde était impensable : on était en fin de journée, et on ne pouvait pas se permettre de perdre la journée.
 
bref, continuez de croire que j'exagère jusqu'au jour ou ce genre de mésaventure vous arrivera aussi. personnellement j'ai donné. sans parler des engueulades carabinées du client et de la direction (car oui, dans les SSII, les chefs n'assument pas leurs erreurs de casting et de recrutement...)

vous testiez pas vos commit sur une base de test avant ?

SELECT count(i.cod_ind)
FROM individu i JOIN ins_adm_etp iae ON (iae.cod_ind = i.cod_ind)
     LEFT OUTER JOIN ins_adm_etp iae2 ON 
        (iae2.cod_ind = i.cod_ind 
            AND iae2.cod_anu = 2008 
            AND iae2.eta_iae = 'E' 
            AND iae2.cod_cmp IN (600, 700, 420, 400)
        )
WHERE iae.eta_iae = 'E'
AND iae.cod_cmp IN (600, 700, 420, 400)
AND iae.cod_anu IN (2007, 2006, 2005)
AND iae2.cod_ind IS NULL;

SELECT count(i.cod_ind)
FROM individu i JOIN ins_adm_etp iae ON (iae.cod_ind = i.cod_ind)
WHERE iae.eta_iae = 'E'
AND iae.cod_cmp IN (600, 700, 420, 400)
AND iae.cod_anu IN (2007, 2006, 2005)
AND NOT EXISTS (
    SELECT 1 
    FROM individu i2 JOIN ins_adm_etp iae2 ON (iae2.cod_ind = i2.cod_ind)
    WHERE iae2.cod_anu = 2008 
    AND iae2.eta_iae = 'E' 
    AND iae2.cod_cmp IN (600, 700, 420, 400)
    AND i.cod_ind = i2.cod_ind
    );

J'avais en diagonale notamment la partie ou ils parlent de "implicit join notation" qui semble être mon cas.

?

si bien sur, mais là encore, ex-collègueG avait jugé que ça serait mieux, étant donné la modif "mineure" qu'il faisait, de tester directement sur la prod du client, lui faisant ainsi économiser 1 heure de temps de 2 consultants, persuadé qu'il était que sa modif se contenterait de virer des WHERE inutiles sans altérer les données...

faute professionnelle, on vire le connard et on enchaine.

Bon je crois que ma requête correspond pas à ce que tu suggères, les résultats sont pas les même et c'est 10 fois plus long

Edit : My bad j'ai écris une connerie, les résultats sont similaires et c'est plus rapide

Tu me parles à moi?
Si oui, j'ai raté un truc - genre la requête d'origine et ce que tu veux en faire.

Nan je m'adressais a Harko, désolé

le connard a été viré par la suite (il a fallu qu'il fasse 2 autres conneries avant quand même...) , les heures passées à réparer ses conneries n'ont bien sur pas été facturées et j'attends toujours que cette boite me rembourse frais de déplacement dus aux innombrables aller-retour que j'ai du faire chez ce client (je me suis assis dessus depuis longtemps).
bref, remplacer un WHERE par un JOIN prend 2 secondes et peut sauver des vies. je vois pas pourquoi s'obstiner personnellement.

Ici j'ai des devs qui ont appris sql sur oracle 7 et n'ont jamais vu la syntaxe JOIN...
Je suis tout à fait pour l'utilisation des join, mais pour ces collègues c'est compliqué à relire, c'est tout...je vais pas les forcer à changer de syntaxe alors qu'ils savent très bien ce qu'ils font avec des where.

[noob]
 
Mais donc, JOIN sans CLAUSE ( OUTER/INNER ) est INNER par défaut si je comprends bien?

Ils sont pas un peu noobs pour considérer que c'est plus compliqué à lire alors que ça divise limite ta construction de jointures en deux lieux différents de ta requête?
 
Perso je le cache pas, je suis à fond partisan du JOIN (mais pas encore fachisant sinon j'aurais déjà réécrit quelques requêtes ici) parce que je trouve justement ça plus simple à lire, à écrire, et à maintenir. Je trouve pas d'avantage à l'autre syntaxe. Faudrait les envoyer en formation ces collègues
 
Pour l'OUTER JOIN, merci au passage, j'avais jamais bien compris et pour le coup, j'avoue que j'écris encore tout avec le Machin NOT EXIST (SELECT 1 blablabla)

Oui, c'est INNER JOIN par défaut.

Question d'habitude.
...puis j'ai rapidement tendance à faire le genre d'outer join posté plus haut, et là c'est forcément moins lisible - sur des jointures à coups de where tu seras obligé de les écrire avec une sous-jointure, et c'est plus lisible, pour le coup.

...et je parle même pas de leur montrer la syntaxe de Zend_Db_Select

??
 

oui, là, forcément...
 
perso vu la proba que étant non DBA :  
- je fasse une requete foireuse qui engendre un produit cartésien qui me plie la base (ou mette un vieux poc niveau perf),  
- je perde des données en mettant mal mes clauses lors d'un delete ou d'un update
 
ça me viendrait pas à l'idée de jouer un script en prod sans l'avoir testé sur une base de test, puis sans l'avoir testé sur la base de prod avant avec des selects / sans commit histoire d'etre bien sur...
 
il était joueur ton collègue

On écrit du code de qualité qui fonctionne tout de suite en prod, pas besoin de base de test de n00b

idéalement t'as un site d'intégration dont la base est une copie conforme (clone journalier par exemple) de la base de prod, données comprises

C'est pour les riches ça.
Ici on dev sur la base de tests, copie conforme hebdo de la prod.

Bah c'est bien aussi, mais avec les grosses bases si chaque dev a sa machine, sauf si toutes les machines de dev sont des monstres c'est pas faisable
 
Parce que bon des DBs de 50Go sur le pauvre poste de dev, ça peut douiller, surtout si il faut la régénérer fréquemment parce qu'il y a des tests un peu dangereux qui sont faits

 
ah oui mais non, les bases de test sont sur les mêmes serveurs que celles de prod, faut pas déconner.
Non parce-que déployer un oracle sur AIX par dev ça va pas le faire non plus, stuveux.

Ah ok, donc pendant tes tests tu peux flinguer la base de ton collègue?

http://troels.arvin.dk/db/rdbms/
 
Ça sert à rien, la norme SQL, en fait

Also, PreparedStatementFail
 

cr.execute('select distinct child_id from some_table_rel where parent_id in ('+','.join(map(str, ids))+')')

Une base de dev, une base de test, une base de prod. Chaque base sur des machines différentes
 
Tiens j'ai 70GB de base en prod (je pensais qu'on était à 40GB, j'ai dû louper un truc)

Si je suis un gros boulet, oui. Mais ça n'est jamais arrivé, s'il y a bien un truc où les mecs savent ce qu'ils font ici c'est bien les bases de données.

6 prod, 6 test, 6 formation, le tout sur 3 serveurs.

Ca suppose qu'il ait jamais deux mêmes airdate pour un même show_id ça, nan ?

c'est justement pour ça qu'il faut utiliser JOIN. plus c'est compliqué à relire, plus le doute germe dans l'esprit de celui qui ne connait pas et qui serait tenté de faire le même genre de modif.
imaginons que je débute le SQL. j'arrive sur un chantier, on me demande de retoucher une requête. le fait de voir des JOIN me fera réfléchir à 2 fois (voir demander confirmation) avant d'y toucher. alors que le WHERE a une connotation "je restreint le recordset retourné, et si je le supprime, je ne risque rien sauf au pire renvoyer plus de données que nécessaires".
 
edit: et j'ai oublié de préciser que le serveur Oracle que ex-collègueG a bousillé tournait sous Linux. et ça, ben rien que pour la chierie satanique que représente l'install d'Oracle sous Linux, ça mérite de virer les Where

 
petite nature, linux c'est pas de l'aix 5.2.

ratibus

C'est vrai ça, pourquoi utiliser le null pour ce pour quoi il a été conçu

dans ce cas, la règle de base c'est de rajouter des index sur les champs utilisés dans le where d'une requête lente. Si ça n'est pas assez efficace, tu demande a un dba ou a un expert de ce topic.

Tu te bases sur un exemple qui implique un collègue particulièrement incompétent, difficile d'en tirer une règle générale a partir de ce point
 
AMHA c'est plus une question de style, les un préfèrent les join, les autres préfèrent faire ça dans le where, pas besoin de faire une flame war sur ce sujet.

Quand tu as des gens comme Oracle et MySQL, c'est effectivement pas très utile

Dans ma première boite, certains trucs étaient volontairement compliqués pour forcer les gens a réfléchir (en théorie). Dans la pratique, les seuls effets que ça avait étaient de ralentir ceux qui savaient ce qu'ils faisaient et d'embrouiller les autres qui faisaient n'importe quoi.

Les indexes mysql classique sont des B-Tree tous cons. (arbre de recherche balancé avec la valeur médianne de tout sous-arbre en haut du sous-arbre.
Un index multi-colonne c'est simplement un B-Tree dont les clés sont une concaténation des deux valeurs, genre show_id:airdate
C'est pour ça que l'ordre est important. Mais ça n'ajoute pas de contraintes niveau cardinalité.

insert flag into topic

prems

mauvais topic

meuh non.

Quelqu'un pourrait m'expliquer pourquoi MyWTFSql est sensible à la casse dans les noms de tables et de colonnes?