C'est parti

J'ai mis un sondage

premier vote \o/

Merde j'avais pas voté.

1 partout, balle au centre.

 
ça peut etre intéressant
 
et col1, col2, col3 bien sur

A voté

Quel est l'âne qui a choisi SELECT * qu'on le pende par les couilles?

C'est BenO, le premier qui a voté

c'est pas bien de faire ça ?

Bon ben cross-post

Table d'article avec une date de début, une date de retrait et un booléen publié ou non.

t.boolean  :active        # publié ou non
t.datetime :starts_at     # date de publication
t.datetime :ends_at       # date de retrait

Mes requêtes types ressembleront à ça :

SELECT col1, col2 FROM articles 
WHERE (starts_at IS NULL OR .starts_at < DATE.now) AND (ends_at IS NULL OR ends_at > DATE.now) AND active = true 
ORDER BY starts_at DESC

Bref, choper tous les articles actifs en cours de publication, par ordre de mise en ligne

starts_at aura TOUJOURS une valeur;
ends_at quasiment jamais de valeur;
active quasiment toujours à true;

J'indexe quoi et dans quel ordre ?

Pour l'instant je pensais à juste starts_at. Et je ne sais pas comment MySQL réagi au OR dans les conditions..
Enfin bref, si qqun a une idée.

Arrêtez de foutre des NULL partout
 
Mettez une date à zéro par exemple, c'est moins relou.
 
Pour tout ce qui est indexage, vérifie déjà avec un EXPLAIN

C'est mieux dans le sens où le serveur doit pas deviner quels champs tu veux, tu fais potentiellement transiter moins de données sur le réseau si tu rajoutes des champs dont t'as pas forcément besoin
 
Bon sinon dans un registre différent, j'ai une chouette requête dont on voit qu'elle a été écrite puis maintenue par deux personnes différentes
 

SELECT * FROM Table1, Table2, Table3
WHERE Table1.id = Table2.table1id
AND Table2.id = Table3.table2id
 
UNION
 
SELECT * FROM Table1
INNER JOIN Table2 ON Table1.id = Table2.table1id
INNER JOIN Table3 ON Table2.id = Table3.table2id

Cross post aussi
 
Deux tables :
 
Shows qui a une relation one to many sur Episodes , je veux récuperer tous les épisodes liés à un show dont l'airdate est superieur à date.now
 

pending = session\
                .query(Show.id, Show.showname, Episode.id,  Episode.season, Episode.num, Episode.title, Episode.airdate)\
                .filter(Episode.show_id.in_(watched_shows))\
                .filter(Show.id == Episode.show_id)\
                .filter(Episode.airdate > datetime.now())

Ça me sort ça

SELECT
    shows.id AS shows_id,
    shows.showname AS shows_showname,
    episodes.id AS episodes_id,
    episodes.season AS episodes_season,
    episodes.num AS episodes_num,
    episodes.title AS episodes_title,
    episodes.airdate AS episodes_airdate 
FROM
    shows, episodes 
WHERE
    episodes.show_id IN (?, ?, ?, ?)
AND shows.id = episodes.show_id
AND episodes.airdate > ?

 
Hors c'est super lent, je vais retenter un explain mais je sais pas lire le résultat
Mais au pif si je dois indexer il faut que je le fasse sur quel column et pourquoi?
 

0 pour une colonne DateTime, ça va pas mettre le boxon ?
Quelle sera la différence avec NULL ?

pending = session\
                .query(Show.id, Show.showname, Episode.id,  Episode.season, Episode.num, Episode.title, Episode.airdate)\
                .filter(Episode.show_id.in_(watched_shows))\
                .filter(Show.id == Episode.show_id)\
                .filter(Episode.airdate > datetime.now())

SELECT
    shows.id AS shows_id,
    shows.showname AS shows_showname,
    episodes.id AS episodes_id,
    episodes.season AS episodes_season,
    episodes.num AS episodes_num,
    episodes.title AS episodes_title,
    episodes.airdate AS episodes_airdate 
FROM
    shows, episodes 
WHERE
    episodes.show_id IN (?, ?, ?, ?)
AND shows.id = episodes.show_id
AND episodes.airdate > ?

Fais un index multi colonne (show_id, airdate) qui te servira pour ta requête et toutes les jointures sur les show (left-most machin)
Et un autre sur airdate pour les cas ou tu auras à trier par airdate sans jointure.
ça devrait poutrer sa mère.

Quelqu'un sait quelle est la taille limite de set quand on fait un WHERE foo IN set? Pour postgres?

Enfin un 0000-00-00 00:00:00, du coup pas besoin de tests pour voir si c'est NULL (requête simplifiée). Et une colonne nullable prend plus de place.

Nan mais c'est juste instantané quoi

Merci

Need : Bouquin pour comprendre toute cette merde

Et si tu indexes ce champ, ça bouffe de la place inutilement dans l'index

Ouais enfin sauf si ta table a des dimensions gargantuesques osef

Ne pas prévoir, c'est déjà gémir.

 
J'ajoute mes indexes
 

 
Wait what?

et tant que t'y es, remplace donc ton  

FROM
    shows, episodes 
WHERE
    episodes.show_id IN (?, ?, ?, ?)
AND shows.id = episodes.show_id
AND episodes.airdate > ?

par

FROM
    shows INNER JOIN episodes ON shows.id = episodes.show_id
WHERE
    episodes.show_id IN (?, ?, ?, ?)
AND episodes.airdate > ?

je ne le répeterais jamais assez : les jointures par WHERE, c'est le mal

explique

FROM
    shows, episodes 
WHERE
    episodes.show_id IN (?, ?, ?, ?)
AND shows.id = episodes.show_id
AND episodes.airdate > ?

FROM
    shows INNER JOIN episodes ON shows.id = episodes.show_id
WHERE
    episodes.show_id IN (?, ?, ?, ?)
AND episodes.airdate > ?

C'est l'ORM qui génère son truc
 
Mais pendant que t'es là, on me suggère à la place de  

SELECT foo FROM mytable WHERE bar IN (1, 2, 3, 4, 5, ..., 999, 1000)

de faire un "join sur un values pattern".
 
J'ai trouvé VALUES dans la doc de postgres, mais je vois pas quel join faire, halp?

oh je me prends régulièrement la tronche ici avec plein de monde à ce sujet
le post le plus récent à ce sujet étant celui ci : http://forum.hardware.fr/hfr/Progr [...] 6363_1.htm
 
mais bon, si tu cherches, y'en a plein d'autres, y compris en MP

- je reviendrai lire les questions quand j'aurai le temps.

Mouais, rien de bien convaincant, donc.

SELECT foo FROM mytable WHERE bar IN (1, 2, 3, 4, 5, ..., 999, 1000)

ben tu génères une table temporaire avec tes 1000 valeurs, que tu appellera Tmp par exemple et un champ "bar"
puis ensuite tu fais ta jointure :
 

SELECT foo FROM mytable INNER JOIN Tmp ON mytable.foo = Tmp.bar

Non, il fait son intégriste.

Oui mais non, justement, apparemement je peux faire ça mieux avec http://www.postgresql.org/docs/8.4 [...] alues.html

edit: mmm d'après la page d'après ça pourrait donner:

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

du tout... sauf à mélanger critères de jointure et critère de filtre dans la même requête, multipliant ainsi les risques de CROSS JOIN (et donc de mise en croix du serveur aussi) en cas de suppression par mégarde d'un ou plusieurs critères de jointure là où on voulait supprimer un filtre...
moi je dis ça, je dis rien hein, ça arrive bien plus souvent qu'on ne le croit

tiens, l'array() de php en sql.

 
ouais. Et dans ton code, si on vire des lignes sans réfléchir, ca peut aussi casser des choses.
oh la la.

Utiliser JOIN c'est juste une question de bonnes pratiques/lisibilité, tes réactions sont toujours excessives.

pareil

Bah c'est pas mal pour créer une table temporaire OTF, et ça fait partie du standard en plus

Ça doit pouvoir s'arranger : SQLAlchemy. Ça devrait donner un truc du genre :

pending = session\
          .query(Show.id, Show.showname, Episode.id,  Episode.season, Episode.num, Episode.title, Episode.airdate)\
          .select_from(join(Show, Episode, Show.id==Episode.show_id))\
          .filter(Episode.show_id.in_(watched_shows))\
          .filter(Episode.airdate > datetime.now())

Edith :

SELECT
    shows.id AS shows_id,
    shows.showname AS shows_showname,
    episodes.id AS episodes_id,
    episodes.season AS episodes_season,
    episodes.num AS episodes_num,
    episodes.title AS episodes_title,
    episodes.airdate AS episodes_airdate 
FROM
    shows JOIN episodes ON shows.id = episodes.show_id 
WHERE
    episodes.show_id IN (?, ?, ?, ?)
AND
    episodes.airdate > ?

[noob]

C'est quoi inner/outer join?

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