Requete pas évidente en MySQL... - SQL/NoSQL - Programmation
Marsh Posté le 27-08-2004 à 20:59:24
oups j'ai pas bien lu ton post
euh et bien en mysql uniquement, ben je ne sais pas faire...
Marsh Posté le 03-09-2004 à 23:12:06
t es obligé de le faire en une seule requete ?
sinon iteration sur le type et pour chaque type une requete simple pour aller chercher la news qui convient !
Marsh Posté le 03-09-2004 à 23:24:54
SELECT *
FROM news
WHERE news_id IN (
SELECT max(news_id)
FROM news
GROUP BY news_typeid)
devrait fonctionner avec mysql 4
Marsh Posté le 03-09-2004 à 23:45:36
gizmo a écrit : SELECT * |
A ouai... Moi j'étais resté sur l'interdiction de faire des selects imbriqués en mysq
Intéressante cette version 4
Marsh Posté le 03-09-2004 à 23:46:46
pains-aux-raisins a écrit : |
Et les procédures stockés de la version 5 ont l'air interressante d'après ce que j'ai pu en juger
Marsh Posté le 03-09-2004 à 23:55:40
Faut que mon hébergeur (Free) se décide à installer cette nouvelle version
Marsh Posté le 04-09-2004 à 00:01:06
Tout d'abord ce n'est pas pour tout de suite, ensuite il n'est pas sur que les hébergeurs gratuits fassent la migration. S'ils intègrent PHP5, ils auront SQLLite en bundle dans php, ce qui pour un usage purement "perso" est tout a fait suffissant.
Dans tous les cas tu trouveras plus d'inos sur le site de mysql : http://dev.mysql.com/doc/mysql/en/News-5.0.x.html
Marsh Posté le 04-09-2004 à 00:03:30
Lord ii a écrit : Tout d'abord ce n'est pas pour tout de suite, ensuite il n'est pas sur que les hébergeurs gratuits fassent la migration. S'ils intègrent PHP5, ils auront SQLLite en bundle dans php, ce qui pour un usage purement "perso" est tout a fait suffissant. |
Euh, oui, mais alors VRAIMENT personnel. Ca signifie avec pas plus de 2-3 utilisateurs simultanés.
Marsh Posté le 04-09-2004 à 00:09:01
gizmo a écrit : Ca signifie avec pas plus de 2-3 utilisateurs simultanés. |
Je ne l'ai pas testé mais le verrou ( qui est total je te l'accorde) ne s'applique qu'en écriture. Dans le cas d'un site dynamique sans log cela ne doit pas poser de pbs.
De plus, pour avoir travaillé chez un FAI, c'est un peu ce que ceux-ci recherchent, des sites pas lourd et ne faisant pas trop de visites pour ne pas trop couter en Bande Passante et en serveurs
Marsh Posté le 04-09-2004 à 09:59:01
J'ai eu le meme probleme.
Une solution serait de rajouter un champ LAST_NEWS_ID dans ta table NEWS_TYPE (qui doit être mis à jour à chaque ajout de news).
Ca casse un peu la propreté de la modélisation mais ça améliore les perfs vu que ensuite tu n'as qu'une jointure à faire.
Marsh Posté le 04-09-2004 à 13:21:41
viiz a écrit : ouais bah je crois que ca va etre ca... |
bah c'est pas nouveau que c'est de la bouse MySQL...
Mais que veux-tu "c'est gratuit et Open Source". Vu que maintenant les gens ne jurent que par ça, on est entouré d'outils de merde
Marsh Posté le 05-09-2004 à 12:04:00
Bonjour,
Si j'ai bien compris ta deuxième table 'NEWS_TYPE' ne te sert pas dans ta requête ??
La seule table concernée est 'NEWS', dans ce cas essaie la requête suivante :
SELECT [NEWS_TEXT], MAX([NEWS_DATE]) AS 'DATE'
FROM News
GROUP BY [NEWS_TEXT];
Je viens de l'assayer sur ACCESS (je n'ai pas mysql chez moi), elle a bien marché (ACCESS car il est très susceptible
Si le mot clé AS te pose un problème tu peux l'enlever, il sert juste à rebaptiser la colonne.
Tiens-nous au courant.
Marsh Posté le 05-09-2004 à 12:16:51
motra a écrit : |
Ca marche pas, parceque NEWS_TEXT est forcément différent pour chaque ligne. Donc MAX(NEWS_DATE) revient à sélectionner toutes les dates, sans faire de MAX().
Il n'y a aucun moyen de faire ça "proprement". C'est une difficulté qui se pose régulièrement, et il n'y a pas d'autre solution que de retrouver le MAX() des ID pour chaque type dans sous-requête (ou PHP) puis dans la requête principale rechercher les textes de ces ID.
Marsh Posté le 27-08-2004 à 18:37:07
select [...]

order by news_date desc
limit 0,1 (ou 1,0 je sais plus)
Message édité par pains-aux-raisins le 27-08-2004 à 18:37:41