Salut tout le monde,
 
J'ai 2 tables qui representent une liste de taches a executer:
 
TABLE1 (ne contient que des taches de type 1)
id   |  type |  date_exec
___|______|________________
1         1         1er mars - 10h
2         1         2 mars - 15h
3         1         3 mars - 14h
 
TABLE2 (ne contient que des taches de type 2)
id   |  type |  date_exec
___|______|________________
1         2         1er mars - 9h
2         2         1er mars - 11h
3         2         3 mars - 14h
 
Je veux recuperer la prochaine tache a executer, tout type de tache confondu (c'est a dire sur toutes les taches des 2 tables).
 
La premiere requete rapide, bete et simple que j'ai trouve et celle-ci:
SELECT * FROM  
      (SELECT * FROM
                (SELECT id, TYPE, DATE_exec FROM TABLE1
                 UNION
                 SELECT id, TYPE, DATE_exec FROM TABLE2)
       ORDER BY date_exec)
WHERE ROWNUM=1 ;
 
Le (bon) resultat retourne est le suivant:
id   |  type |  date_exec
___|______|________________
1         2         1er mars - 9h
 
Existe-t-il une requete plus "fine" pour obtenir le resultat que j'attends?
 
Merci de votre aide.

n'est-il pas possible de tout mettre dans la même table ?

   
 
A moins d'avoir une très bonne raison de le faire, ça n'a aucun intérêt.
Par exemple, pour ton problème une requête de base suffit (sans jointure ou autre)...

 
En effet, s'il y a 2 tables, c'est qu'il y a une bonne raison derriere avec laquelle je n'ai pas envie de vous embeter.
 
Concernant ta reponse, effectivement il est possible de faire ca avec une requete de base comme celle qui est dans mon message initial (sans jointure explicite ou autre) par exemple. Je voudrais simplement etre sur qu'il n'y a pas mieux que ma requete, donc si vous avez des exemples de requetes plus optimisees, ils sont les bienvenus!

Pour le coup, on aimerait bien être "embêté" et avoir la "bonne" raison. Perso, je parie qu'au final, elle sera pas si bonne que ça ta raison... Tout ce que t'as à faire, c'est faire 1 table de tâches et rajouter une colonne qui va contenir son type si y'a besoin de filtrer par type de tâche...

 
Lol, bon ben j'aurais du me douter que tout le monde allait repondre a cote (comme dab) en remettant en question le ciel, la terre et les oiseaux mais bon j'aurais tente...J'en deduis donc que personne n'a de reponse a ma question et donc qu'il n'y a pas plus optimise avec 2 tables.
 
Merci quand meme.
 

Ca vous vient pas a l'idée que dans le cadre du boulot on vous fournit une base qu'on n'a pas le droit de modifier et qu'il faut faire avec? Tout le monde n'est pas un geek seul responsable de son appli perso développée dans son garage.
 
Alors au lieu de jouer au finot, autant dire "je sais pas" comme moi

 
Justifier que la BD a été modélisée avec 2 tables pour listes de tâches parce que c'est dans le cadre du boulot et qu'on ne peut pas modifier, c'est pas ce que j'appelle une bonne raison, c'est une erreur de conception qui a été fait auparavant et un boulet qu'il faut se traîner aujourd'hui
 
Il pouvait nous dire : y'a 2 tables actuellement, ça a été mal conçu, normalement il aurait fallu en faire qu'une mais bon, je peux pas modifier et je dois faire avec. Non, là, il nous dit qu'il y a une très bonne raison. J'aimerais bien la connaître, c'est tout.

et donc si tu connais pas cette raison ca t'empeche completement de répondre à la question?

Y'a normalement pas besoin de sous-requêtes :  
SELECT id, TYPE, DATE_exec FROM TABLE1
UNION
SELECT id, TYPE, DATE_exec FROM TABLE2
ORDER BY date_exec
LIMIT 0, 1
 
Comme le SGBD est pas précisé, je donne ce qui marche pour MySQL. Après, y'a qu'à trouver l'équivalent de LIMIT.

 
Autant pour moi je n'avais pas precise le SGBD et malheureusement je travaille avec Oracle donc le statement le plus proche de LIMIT sous mysql c'est ROWNUM (ROW_NUMBER) avec Oracle.
 
Et je cherche un moyen d'utiliser ROWNUM sans sous-requete mais apres des recherches sur le net, je n'ai pas trouve comment faire et ca ne parait pas possible. Je voulais juste verifier que c'etait bien le cas.

A partir du moment où il y a deux tables non liées, tu es obligé d'utiliser des sous-requêtes (de faire un UNION ou équivalent, quoi).
 
Après, rufo t'a proposé une autre manière de faire et sous Oracle tu peux les comparer et choisir la plus performante...

mets plutôt un "UNION ALL" a la place de "UNION"
 
si ton calendrier va très loin dans le temps et que tu sais que tes prochaines taches ne sont jamais très loin tu peux mettre un filtre sur 30 jours ou un truc du style.