il vaut mieux:
- mettre a jour deux tables a chaque post
ou
- faire une sous requete?
 
j'explique...
prenons par ex le forum HFR
imaginons deux tables: une table_topic (contenant le nom du topic le posteur la date etc...) et une table_message (l'auteur, le texte etc...)
lorsque qqun poste un msg dans un topic (donc ds table_message), on peut voir sur la page de listing des topics son nom en tant que dernier posteur. (page generée grace a table_topic)
 
Pour cela, vaut il donc mieux, mettre a jour table_message (avec le corps du message, le nick etc..) ET la table_topic (modif du champ dernier_posteur)
ou
juste la table_message, sachant que pour la generation de la page topic, il y aurait une sousrequetes pour aller chercher le nom et la date du dernier post du topic?
 
 
j'espere que je suis assez clair.. c un brin confu encore ds mon esprit

methode 1 si tu cherches la rapidite au detriment de la place
methode 2 si tu cherches l'optimisation de la place et la normalisation de ta BDD

ok merci

Et j'opterai pour la possibilité 2, tout à fait personnellement.

ah? j'etais parti sur la 1ere plutot...
perso je prefere faire une seule requete (meme si plus complexe)
mais bon, je cherche la rapidité avant tout...
 
 
argumentes© stp

En fait, la normalisation de la base me paraît importante, parce que cela donne une structure conforme à la logique utilisée la plupart du temps (comprendre recommandée la plupart du temps). Ensuite, j'imagine qu'une table normalisée est plus capable de supporter une modification de structure, étant donné que les informations ne sont pas dupliquées et qu'il n'y a pas de multiples liens entre les enregistrements. Cette logique de conception me parait primordiale.
 
La rapidité est aussi un facteur important, mais la dénormalisation des tables devrait toujours être fait avec précaution. Ce serait bien si tu pouvais faire des tests de montée en charge avec les deux maquettes. C'est long à faire, mais la différence de rapidité pourrait te permettre de faire le choix qui est le plus adapté. Je ne connais pas les gains classiques entre méthode 1 et 2. Cela doit pouvoir se trouver, même si j'ignore où.
 
Voilà mon petit avis. N'hésite pas à demander, si ce que je raconte n'est pas clair.

faut voir que dans la méthode 2 la jointure effectuee n'est pas bien méchante non plus.

sinon, la methode 1 est plus pratique pour afficher le nom du modo qui a fermé le topic (:d)...
alors que la methode 2 est meilleure quand le dernier posteur efface son message

tu peux très bien mettre une condition sur ta requète SQL

sur laquelle de requête?  
 
(tirage de vers du nez ON )

celle qui rappatrie les donnees des titres.
A la limite tu fais un :
 
IF(close=1,modo,dernier_auteur) dans ta requète

merci tout le monde    
jvais m'y remettre

 
Houlà !!!
 
Méthode 1 sans réfléchir !!!
Tu te rend compte du gain de perfs ?
 
Avec la méthode 2, tu dois exécuter autant de sous-requètes pour trouver le dernier posteur qu'il y a de topic affichés !!!
 
Sois une bonne 30aine !
 
Et sur un table "message" qui comporterai un bon million d'enreg... tes perfs vont s'ecrouler !!!
 
Par contre, ça t'oblige à maintenir le champs "dernier posteur" dans la table des topic.
Donc, ne pas oublier de la mettre à jours dans TOUS les cas (réponse, suppression du dernier message...).
 
Et il en vas de même beaucoup d'autres infos qui paraissent etre facilement récupérable par simple requète :
Le nombre de méssages postés depuis 00h00 par exemple.
Un simple SELECT te ramène ce nombre, mais c'est trop couteux sur une table de 500.000 message.
Il faut passer par un champs, incrémenter ce champ à chaque post et le remettre à zéro à 00h00.
 

 
Et en réfléchissant, tu prends laquelle ?

 
Ben... lis l'argumentaire au lieu d'essayer de faire de l'humour...

 
pas d'accord, t'as juste une seule jointure a faire.

 
remets toi à tes bagnoles, toi, ça vaudra mieux....

en fait il suffit de savoir que
- le rafraichissement de la page (liste des sujets) est sans doute l'action la plus fréquente
- l'ajout d'un message est moyennement fréquent  
- la suppression de message est rare
 
à partir de là je dirais que l'option 1 est mieux, même si la base n'est plus "normalisée".

toute facon c'est assez evident
la methode 2 voudrait dire qu'il faut chopper le MAX du numero associe, donc faire un group by, etc etc

maintenant est-ce mieux de stocker dans la table topic  
- l'id du dernier posteur, son nom, la date du dernier post  
ou
- stocker uniquement l'id du dernier message ? (on sait retrouver la date, le posteur, ...)
 
-> donc avoir une table optimisée ou méga optimisée ?

 
   
 
Une jointure sur quel champs ?
 
Dans la méthode 2, tu es bien obligé d'aller faire, par exemple, un SELECT MAX sur la date ou l'ID des messages pour sortir le dernier message du topic non ?
 

 
T'es gentil, on parle technique ici.
Alors essaie de faire un effort pour suivre la discution et argumenter ou vas parler chiffon dans le topic bla-bla.
 

 
La solution de stocker l'id du dernier posteur n'est pas bonne, parceque tu ne serais pas retrouver le dernier message (dans le cas ou ce posteur aurait posté une autre réponse dans un autre topic).
 
Tu stock juste l'ID du dernier message.
 
Puis tu fais un JOIN pour récupérer l'ID du posteur et un autre imbriqué pour récupérer son pseudo !

oui bon ok j'aurais du dire :
- l'id du dernier message, l'id du dernier posteur, la date du dernier post, le nom du dernier posteur.
ou
- l'id du dernier message
 
je pensais que tout le monde l'aurais compris  

jointure sur le champ numeropost
 
tu fais un  
 
SELECT pseudo, titre_topic, ..., MAX(date) as a FROM titre,topic WHERE titre.numeropost=topic.numeropost GROUP BY numeropost ORDER BY a DESC LIMIT 0,30;
 
C'est bien horrible comme query ceci dit

T'inquiète. On avait tous compris.

 
Quel interet de mettre l'ID du dernier posteur ? tu vas de toute façon devoir faire des join pour récupérer les pseudo et la date.
L'ID du dernier message suffit.
 
Ou alors, si tu veux eviter les JOIN (couteux en temps) tu peux stocker la totale : ID de posteur, pseudo du posteur, ID du dernier message et Date du dernier message.
Mais c'est dommage de mettre tout ça et d'alourdir autant la table des topic qui est la plus sollicitée.
 
Sinon, pour le "je pensais que tout le monde l'aurais compris   " tu peux te le mettre ou je pense.
C'est déjà pas simple de correctement répondre aux questions, mais si en plus il faut deviner les oublis dans les formulations des questions, c'est plus de l'informatique, c'est du spiritisme.

 
Ton MAX, dans ce cas, c'est une sous-requète.
Je vois pas pourquoi tu parle de jointure.
 

ah bon    
 
kestuféla alors ? je croyais que t'étais en train d'étudier sérieusement l'asm moi, parce que vu ta seule réponse à un topic parlant d'assembleur, je me dis effectivement qu'il y a un mois, tu savais pas ce que c'est un compilo !

 
Vu la qualité de ta seul contribution à ce sujet (20 ligne pour rien dire et ne pas répondre à une problèmatique pourtant trés simple à évaluer) je m'abstiendrais de tout commentaire.
 
 
 

non c'est pas une sous-requète.
 
Et la jointure est là : titre.numeropost=topic.numeropost.
 
Une sous requete c'est ca :
 
SELECT pseudo, titre_topic, ..., numeropost as a, (SELECT MAX(date) FROM topic WHERE numeropost=a) as b FROM titre ORDER BY b DESC LIMIT 0,30;

 
   
 
Tiens, voilà le dieux de l'ASM.
Masi souvenir d'asm sont lointaint, mais les tiens n'ont pas l'air trés frais non plus.
Pour le "byte" j'avais faux, mais tu aurais pu dire à notre élève que cette syntaxe s'accompagne de "ptr" pour obliger le compilo à ne charger que l'octet de poid faible dans une variable 16 bit ou dans un registre, vu que tu sais tout.
 
Tiens, si tu veux vraiment m'etonner, rappelle moi comment on passe du mode réel au mode protégé en asm 80386    (je sais, c'est pas jeune, mais je me suis arreté il y a longtemps).

Pourrais tu éclairer ma lanterne et m'expliquer ce que tu appelle sous-requête, parceque manifestement je ne dois pas avoir la même définition ?

 
Oui, dans la syntaxe, ceci est bien une sous requète.
Mais de toute façon, un MAX, c'est une requète ! dans les faits, ton SGBD va faire une requète pour te sortir le max.

 
Une sous requète est une requète dans une requete, mais ça, tu dois le savoir.
Maintenant, quand, dans une requète SELECT, tu spécifie un MAX sur un des champs selectionné, ton SGDB va réaliser une autre requète pour se positionner sur l'enreg demandé. Puis il va te sortir les champs spécifiés dans le SELECT.
 
Ben, ça, typiquement, c'est une sous-requète.

ca n'a rien à voir, utilise les termes adéquats.
Le premier cas necessite une jointure entre les deux tables, tandis que le deuxième cas se base sur un dependent SUBSELECTs qui va crée une table temporaire en interne (ceci dit la premiere requete va generer aussi une table temporaire pour pouvoir faire l'order by).
Mais les deux requètes n'ont pour moi rien à voir.

tu ne connais pas le fonctionnement interne de la SGBD pour avancer ca. Un MAX n'est PAS une sous-requète.

 
Pas d'accord.
 
Je vais pas t'aprendre le principe d'une requète quand même !
 
Dans le cas qui nous interesse :  
 
1er requète : récuperer le jeux d'enreg de la table message qui satisfait la condition "appartient au topic".
 
2eme requète sur ce même jeux : récuperer celui qui a la date la plus récente.
 
Ensuite, tu peux formuler ta requète comme tu veux, dans le principe, tu fais une sous-requète.