Reprise du message précédent :

Toi tu commences par ravaler ton orgueil et tu admets que t'as tord, même si c'est juste une fois, l'erreur est humaine, hein
 
Que tu saches pas comment faire sans sous requête (sub select comprends pas moi...) c'est une chose, que ça soit pas possible sans...
 
Donc tu restes humble et avant de devoir admettre de force je te laisse le temps depuis le début de trouver seul
 
J'adore toujours autant la confiture, c'est trop bon surtout de la voir sur les tartines des autres
 
edit: qui t'as parler d'order by, y'en a pas besoin en plus  

Moi je maintiens, je suis preneur d'une solution sans sub-select.
 
Sans être aussi "intégriste" que cinocks, très franchement, je n'y crois pas une seconde, et je demande à voir.
 
En tout cas, cinocks "te parle mal", mais pas plus que toi qui nous prend pour de sombres crétins.
 
Je pense que les personnes les plus callées en SQL de ce forum ont déjà participé à ce topic (je ne te présente pas Joce, membre de l'équipe de dev de MySQL entre autres), et on est tous tombés d'accord sur l'impossibilité de faire sans sous requête.
 
Après, par expérience, je m'attends au pire, et du coup je parle d'une solution "propre", c'est à dire sans spécificités ni requête de 4 kilomètres (parceque sinon, autant faire une sous-requête c'est pas plus lent).

Si le Joce est le Joce de ce forum qui s'est fait hacké méchament, on peut pas penser à tout soit je le sais, mais le vends pas en maitre STP
 
Et c'est encore pire s'il fait partie de l'équipe qui développe un truc qu'il sait même pas utiliser    
 
Maintenant je sais bien que c'est pas le premier truc qui vient à l'esprit, mais c'est simple et loi des 4km
 
Group by ça sert à quoi On a juste 2 tables et une pauvre jointure Donc je demande sincèrement à quoi ça sert de faire une sous requête
 
Et puis c'est du SQL de base enseigné dans les études de base! Donc pourquoi cherché compliqué, même si l'habitude du compliqué est le quotidient, faut savoir faire simple
 
Et la qui peut le plus, peut apparement pas le moins, c'est triste  

j'attends que tu me cites la methode dont tu me parles. Mets-moi la requete en question permettant de recuperer ce qu'il faut, et on commence à en parler.

Poste ta science vin dieu.
 
On est tous avides de voir ta solution.

J'ai relu les posts. Et pour le moment je ne vois pas.
Je précise que la question est bien de retourner pour chaque adresse, le prix actuellement en vigueur.

Punaise pour du SQL de base enseigné dans les études de base, c'est long. Pour le moment la confiture...

lelfos5 > t'es un super génie, on est tous contents pour toi.
 
Seulement, je crois que t'as un peu zappé le rôle d'un forum, ou tout du moins celui-ci.
T'es pas là seulement pour te faire mousser, t'es là aussi pour apporter des solutions à ceux qui les demandent.
 
Alors soit tu postes enfin ta solution, soit du nous laisse jouer avec notre caca tout mou, mais faut que tu te décides rapidement maintenant.

J'ai eu un doute à un moment. La seule solution que je voyais de probable etait de faire :
 

 
Bien sur ca ne passe pas. Il ne sait trouver le p.datetime. Normal, il ne figure pas dans la liste des champs selectionnés.

Je connais un moyen de faire sans sub-select mais bon, il y a un risque sérieux de crise cardiaque chez les puristes  
C'est un coup à se faire bannir définitivement de la section

On est pret à tout.

cette solution ce rapproche grandement de l'éventuellité que j'imagine (la création d'un truc qui sort tout droit de sa carverne une nuit de pleine lune )
 
m'enfin la maintenabilité étant de mise... (et tout le monde ne dormant pas sur un lit d'os au fond d'une grotte humide...)

Bon, tout d'abord, je précise que ce n'est pas de moi, je l'ai vu sur le site de MySQL  
 
Ca se base sur quelques remarques :
- un champ de type "date" ou "datetime" sera trié dans le même ordre selon qu'on se base directement sur le champ (ordre chronologique) ou sur sa représentation textuelle (ordre alphabétique)
- dans un tri de chaînes de caractères, c'est la partie gauche qui compte le plus. Si "BBB" est > à "AAA", alors si on concatène ce qu'on veut à "BBB", le résultat sera toujours > à "AAA" auquel on aura concaténé n'importe quoi
 
A partir de là, tout s'enchaîne : on va concatèner la date (à gauche) avec le prix (à droite), prendre le MAX de cette chaîne de caractère (donc le datetime le plus grand) et enfin récupérer le prix dans la partie droite de la chaîne de caractères  
 
Ca donne un truc du genre (en considérant qu'un "datetime" est sur 19 caractères) :
SELECT Adresses.*, SUBSTR(MAX(CONCAT(Prix.datetime,Prix.prix)), 20) AS prix
FROM Adresses, Prix
WHERE Adresses.id = Prix.id
GROUP BY Adresses.id
 
     

Je penses que celui qui se pose la question a de quoi y répondre C'était juste pour les génies méprisants dont tu fais pas partie
 
Donc ils vont se retourner le cerveau s'ils veulent se remettre en cause Moi je referais parler de moi que plus tard (on peut bien laisser un jour )

ha ouais. si ça te gratte derrière les oreilles, c'est pas grave, c'est la mousse

si t'attends que je me prenne la tête sur cette requête, tu va avoir de la mousse sur les épaules avant moi.
 
la solution de mrbebert fonctionne en effet, seulement le gars qui a trouvé ça, en plus d'être un autiste fini, a des problèmes à se faire pour trouver un boulot dans une équipe... et le conserver !
pondre un truc comme ça, c'est l'assurance de faire un code absolument immaintenable, c'est à dire un motif de licensiement pour faute lourde si on prouve que ça a été pondu sciemment.
 
niveau optimisation, j'ai de plus quelques TRES gros doutes.
 
pourquoi ?
-> Concaténer deux types "datetime" et "float" (ou number), déjà, ça bouffe des ressources à mort, puisqu'il faut déjà les caster, et l'un comme l'autre, c'est extrêment consommateur à faire.
-> Dès que tu fais un cast sur un type, tu peux dire "aurevoir" à tous tes index. preuve ? trie par ordre croissant un champ numérique, puis le même champ que tu cast en varchar. Idem pour un champ datetime. Edifiant n'est-ce pas ?
-> Une fois qu'on a fini ça, on va aller faire un MAX sur une variable de type varchar... Idem, ça demande le calcul de TOUTES les valeurs avant de pouvoir commencer à faire quoi que ce soit. J'imagine la tronche du serveur avec plusieurs millions de lignes...
-> Enfin, un petit substr sur le résultat du max... comparativement à tout ce qui c'est passé avant, le serveur peut enfin se reposer un peu... comme un faux plat à vélo après une côte quoi.

 
Tu es le génie de l'esquive.  

écoute, c'est un problème connu et reconnu cette requète, je ne compte plus le nombre de fois où j'ai vu passer la question sur la mailing de MySQL
Si tu penses à faire un SELECT id, MAX(date), prix ... GROUP BY id, tu as perdu, parce que le "prix" affiché de sera pas forcement celui associé à MAX(date).
sans subselect, la solution sur le site de MySQL est la seule qui existe pour résoudre ce style de requète.

moi en tout cas, j'en veux pas de leur solution, c'est encore moins pire de faire un "select max(date), id ... group by id" puis pour chaque ligne, à la main comme un goret un "select prix ... where id = $id and date = $maxdate"
Si ça se trouve, même nivau perfs c'est à peine pire (MySQL gérant assez bien les ouvertures/fermetures de connexions logiques). Et dans tous les cas, n'importe quel stagiaire sera capable de relire et comprendre le code sans passer 2 semaines à se prendre la tête...

honnetement, je parie sur le subselect de suite. Plutot que sur des fonctions de transformations.

tenu !

Qui se fait chi** pour nous preparer un jeu de test?

J'ai fait quelques tests, il semble que ce soit ma requête qui est la plus rapide    

Je vous met mon jeu de tests :
 
Création des tables :

 
Chargement (script PHP) :

Donc, 200 adresses, et 10 prix pour chacun.
 
Et les requêtes :

 
Le tout sur un P4 3.00 Ghz, MySQL 4.1.10  
 
Les résultats  
La requête 1, je l'ai tuée au bout de 860 secondes  
Requête 2 : 5 sec
Requête 3 : 1 min 50
Requête 4 : moins d'1 seconde  

C'est plutot bizarre ta chose. Si je prend la premiere requete, dans le pire des cas, je dis bien le pire elle va faire une premiere jointure avec 2000 resultats. Et pour faire crade, faire une recherche parmi 10 pour ces 2000 resultats. Meme sans index, c'est fait en 10 secondes sans probleme.
 
La 2 revient à la meme chose que la premiere sur le volume généré. Car il faut trouver tout les resultats pour un id donné avant de definir le premier ordonné.
 
J'ai commencé un jeu d'essai sur mon serveur. Mais n'ayant pas les subselect, je suis un peu coincé.
 
Bon, premier constat, les index devraient exister.

Oui, en définissant Adresses.id en clé primaire et en indexant Prix.id, les 2 premières requêtes sont instantanées (moins d'1 seconde)  
Par contre, la 3ème met encore une trentaine de secondes

Je dirais plutôt qu'elle fait une première jointure et, pour chacun des 2000 résultats, elle fait une recherche sur l'ensemble de la table Prix (2000 lignes)  

Maintenant l'interet serait de le faire sur un vrai jeu d'essai, du volume quoi.

 
oui, c'est ce qu'il fait puisque pas d'index.

Je vais le refaire avec 1000 adresses et 15.000 prix
(en version "avec index", sinon ce serait trop long )

La requête 3 est aux choux.
Le 1 se fait en environ 1,6 sec, la 2 en 2,3 sec ... et la 4 en moins de 0,2 sec  

Question idiote. Mais tu as bien les memes résultats?

Oui, bien sur  
Du moins, les 10 derniers enregistrements, j'ai pas tout vérifié non plus

Et ta requete est executée sous phpMyAdmin?

faut voir que MySQL transforme les subselect en requete de type EXISTS, et que les subselects seront toujours plus lent qu'une requete sans

Non, par le client en ligne de commande. Le client comme le serveur fonctionnent en local  

 
Je pensais tout de même que ce serait plus rapide que faire des transformations. Je suis étonné du résultat.  

 
comme dit à Joce, je suis étonné du resultat. Merci d'avoir fait le test

étonné aussi.
 
mysql, y'a des bouts optimisés, mais ils ont franchement oublié de penser à optimiser les parties qui permettent de conserver un code lisible
 
on va dire que c'est parceque les subselect sous mysql sont jeunes encore. parceque sur sql server comme sous oracle, les subselect n'ont aucun impact sur les performances (mise à part les cas tordus, notamment quand on transforme un champ, ce qu'on ne fait pas dans les requêtes ci-dessus)

perso je pense pas que transformer la requète en truc de type EXISTS soit toujours la bonne solution

Requète 1 :
 

 
Requete 2 :
 

 
Requète 3 :
 

 
J'ai été mauvaise langue, y a que la 3 qui est réécrite en type EXISTS