j'effectue la requête suivante qui devrait me donner la liste de posts différents ordonnés par date décroissante:
 
$msgs = mysql_query("select distinct post from msg where ( cat = '".$cat."' ) order by date desc limit 0,10" );
 
le problème est que le "distinct" nique mon order by,
savez vous comment je pourrais faire?
 
merci

[edtdd]--Message édité par k666--[/edtdd]

raaaaaaaaahhhhhhhhhhhhh
 
 
exemple de valuers de ma base:
 
 
post  login  cat  titre  contenu  params  date  
359   azeaze   2   segundo mensaje posteado   texto del segundo      2002-01-04 15:47:44  
358   killer   2   testeando categoria 2   asi es, testeando, para variar conio!!!      2002-01-04 15:46:50  
1   kpoman   1   salut!!!   salut, ouverture de cette section du forum! sympa quoi      2002-01-04 12:55:24  
359   saraba   2   cool   cooooool man      2002-01-04 15:48:34  
358   sisisi   2   cataclismo   asi es loco, fiera, azeaze      2002-01-04 15:50:37
 
 
et quand je fais select distinct post from msg where cat = 2 order by date desc
 
et bin, il me sort 359 avant 358, or le dernier message posté pour 358 est plus noovo que pour 359
 
la clause distinct s'applique avant ma clause order by, et c vraiment pas cool!!!!
comment pourrais je contrer le blème?

[edtdd]--Message édité par k666--[/edtdd]

et un ptit up!!
à ceux qui n'auraient pas compris mon problème, dites le moi!

Normal, tu as mis DESC !!! DESC = Décroissant !

Aussi, petit conseil d'écriture, écrit bien les commandes SQL en majuscules c plus lisible ensuite !

Autres petit détails :
Les parenthèses ne servent à rien dans ton cas,
Quand ta chaîne est délimitée par des guillemets doubles, les variables sont interprètées.
DONC :  
"select distinct post from msg where ( cat = '".$cat."' ) order by date desc limit 0,10"
 
devient :
 
"SELECT DISTINC post FROM msg WHERE cat = '$cat' ORDER BY date DESC LIMIT 0,10"

c normal que j'ai mis DESC paske je veux le plus récent posteur tout en haut, d'abord! un peu comme ici sur hardware!!
et c pour ça que ma clause distinct est gênante!
paske je veux choisir Dix POSTS DIFFERENTS par ordre décroissant de dates!!!
sil vous plait!!! aidez moi!
 
(sinon pour les parenthèses j'ai oublié de les enlever paske j'avais un AND)
 
merci de m'éclairer!

Je ne comprends pas ! ! !
 
Et avec un GROUP BY au lieu du distinct, çà fait quoi ?
 
"SELECT post FROM msg WHERE cat = '$cat' GROUP BY post ORDER BY date DESC LIMIT 0,10"

et comment ca se fait que tes posts est des numero identiques parfois ?

A mon avis, il a une seule table avec tout dedans !
Donc pour lister les différents topics...

 
c ce ke j'ai moi, 1 table avec tous les posts pr mon forum

oué bah c ça que tu dis
 
g tout dans une table
 
et c vrai que j'avais pas pensé au group by et donc je gagne en requêtes car après je faisais un select * pour chacun des pots
et oué, c ça, en fait "post" = "sujet" et pour chaque post ya plein de réponses différentes ordonnées par date de postage pour un post donné !!!
je vais essayer avec le group by mecs, c vraiment sympa de votre part !

Tout dans une table ? Comment utiliser les bases de donner sans rien y comprendre...
 
Désolé mais c vrais, tout l'intéret de bases est de regrouper les données qui vont ensemble et séparer celles qui sont complémentaires...
 
Bref plustot que d'essayer des requettes SQL compliquées (et plus lourdes à l'exécution !) fait plusieures tables et utilise des requettes avec jointures...

tu veux que je crée une table différente par catégorie de forum???
paske des tables différentes j'en ai!
regarde: j'ai:
 
table actions
table msg
table users
 
tu proposes quoi de mieux?

mais sinon chuis prenant pour un bon cours, bien résumé, sur projections et relations de tables....

A vue de nez :
Tables : categories, topics, posts, users
 
C'est déjà mieux non !

mais c ça que je comprends pas, pourquoi c mieux????
j'ai l'impression que c du découpage que pour découper...
quel est l'intérêt de forcéent mettre des trucs dans d'autres tables?
 
pour topic, je suis d'accord:
en effet, je réserve une place pour le titre de CHAQUE message, or il n'ya de titre que dans le premier message d'un topic donné, donc là, je pige, ya une perte d'espace, dû à une grande qté de champs vides,
mais esque ça justifie de le mettre dans une autre table???
 
et d'ailleurs, pourquoi créer une table catégories, alors qu'il n'yaura a priori que une petite dizaine de catégories??? il yaura dans ce cas toute une série de reqûetes inutiles car faites sur 10 lignes? ne serait-ce pas mieux de créer une constante/tableau à include(r) dans les fichiers de bdd?
 
voilà,
pourquoi tout splitter en fin de compte?

C'est vrai que spliter tout n'est pas forcément la meilleure idée mais n'oublie pas que ca te permets:
 
1) De faire des requêtes isolées
2) D'otptimiser l'espace disque
3) D'optimiser les recherches
 
A+

Pour les catégories, par exemple la réponse est simple et évidente !
Ca te permet d'en ajouter sans avoir une seule ligne de code à modifier !
 
Il n'y a pas de raison que celà ajoute beaucoup de requêtes.
Je vois celle qui permet de lister les catégories, et c'est à peu près tout pour ce qui est de l'utilisation habituelle du forum !

[edtdd]--Message édité par Mara's dad--[/edtdd]

euh;
au fait c le même problème qu'avant avec group by,
qd il projette sur le group by (ou avant, le distinct) bin il court circuite le order by date desc....
quelqun a til une idée?

Pkoi séparer les tables ? Ben c un peu la base de la logique des bases justement...
 
Tu peut faire une table catégorie, une autre utilisateurs, enfin une troisième message (cela serait même plus propre de faire une table des sujets mais bon, c pas obligé car tu peut ajouter un booléen sur un des champs de ta table message...).
 
Une bonne organisation serait :
 
Table Catégorie :
Cat_id : entier unique, identifiant, nécéssaire.
Cat_Nom : chaine de caratères, nom de la catégorie, nécéssaire.
Cat_Desc : chaine de caractères, description de la catégorie.
 
Table Utilisateur :
Util_id : entier unique, identifiant, nécéssaire.
Util_login : chaine de caractères, login de l'utilisateur, nécéssaire et unique !
Util_pass : chaine de caractères, mot de passe de l'utilisateur, nécéssaire. A crypter pour plus de sécurité (merci MD5 ! ).
 
(tu peut rajouter d'autres info utilisateur tel que son site web, son adresse mail...). On aurrai put mettre Util_login en identifiant mais c plus long de gérer et comparer des string que des nombres...
 
Table Messages :
Message_id : entier unique, identifiant, nécéssaire.
Message_titre : chaine de caractères, titre du sujet du message, nécéssaire.
Message_cat : entier, identifiant de la catégorie du message, nécéssaire.
Message_user : entier, identifiant de l'utilisateur, nécéssaire.
Message_sujet : entier, si le numéro = 0 alors c un sujet, sinon, tu y met le numéro du sujet auquel tu répond...
Message_dateheure : date heure, nécéssaire, important
 
Voilà grosso-modo comment faire un début de base de forum clean...
 
Pour les requettes tout deviens simple alors :
Afficher la liste des catégories :
SELECT * FROM Categorie;
 
(tu peut rajouter un numéro d'ordre à tes catégories pour  pouvoir changer l'ordre, il suffira alors d'ajouter un ORDER BY Categorie_order).
 
Afficher la liste des sujets d'une catégorie :
SELECT * FROM Messages WHERE Message_cat=x AND Message_sujet=0 ORDER BY Message_dateheure DESC;
 
Afficher la liste des messages et réponses d'un sujet :
SELECT * FROM Messages WHERE Message_ID=x OR Message_sujet=x ORDER BY Message_dateheure DESC;
 
Pas dur hein

J'ta fait ça rapide, il y as peut-être une ou deux erreurs dans les exemples de requetes mais l'esprit y est

merci mec c très gentil de ta part
j'avais pas pensé au système du champ supplémentaire à 0 si noovo topic ou à n_topic si réponse à
merci je vais l'implémenter tout de suite!
 
mais!!!!!!
 
par contre, ça répond pas à ma question de départ, qui est: comment faire la fameuse requête dont je parlais?
 
 
 
 

 
exemple de valuers de ma base:  
 
 
post  login  cat  titre  contenu  params  date    
359   azeaze   2   segundo mensaje posteado   texto del segundo      2002-01-04 15:47:44    
358   killer   2   testeando categoria 2   asi es, testeando, para variar conio!!!      2002-01-04 15:46:50    
1   kpoman   1   salut!!!   salut, ouverture de cette section du forum! sympa quoi      2002-01-04 12:55:24    
359   saraba   2   cool   cooooool man      2002-01-04 15:48:34    
358   sisisi   2   cataclismo   asi es loco, fiera, azeaze      2002-01-04 15:50:37  
 
 
et quand je fais select distinct post from msg where cat = 2 order by date desc  
 
et bin, il me sort 359 avant 358, or le dernier message posté pour 358 est plus noovo que pour 359  
 
la clause distinct s'applique avant ma clause order by, et c vraiment pas cool!!!!  
comment pourrais je contrer le blème?  
 

Tu as un gros pb de base ! Tu n'as pas d'identifiant valide ! En effet tu as plusieurs fois le même numéro de post... Ne t'attend donc pas à un résultat fiable... C pas le DISTINCT ou le ORDER BY qui marchent mal là !

bin c pas un identifiant unique, c clair,
j'utilise ce numéro pour savoir à quel topic ça appartient, et il est en incrément automatique, donc si je poste kek chose sans fournir de numéro, il en choisit un tout seul,
mais tu es totalement sûr que c'est à cause de ça que casse mon order by????

Il FAUT un identifiant unique par table... C une rêgle d'or !

Le problème n'est pas un identifiant unique !
C'est sûr que c'est mieux, mais dans le cas de K666, on peut considérer que Numéro de post + DateHeure constitue un identifiant.
 
En fait ce que tu veux, c'est pour chaque numéro de post, avoir le DERNIER post, donc le order by, il peux rien pour toi (il est fait après le group by ) !
 
Ce qu'il te faut c'est : (Testé ET approuvé avec tes données ! ! !)
"SELECT post, max(date) AS dt FROM msg WHERE cat='$cat' GROUP BY post ORDER BY dt DESC LIMIT 0,10"  
 
En fait, avec le group by, ou le distinct (c'est pareil), il prends la première ligne qui va bien, donc en fait c'est les 2 première lignes de ta table.

[edtdd]--Message édité par Mara's dad--[/edtdd]

c exactement ce que je cherchais
 
merci bokoo mara
 
au fait tu peux m'appeler killer (pour k666 )
 
merci bokoo et @ bientôt!