vengeur002

Bonjour

j ai une question un peu bizzarre lol

d apres vous il est preferable de reduire le nombre de requete sql ou reduire la taille de la base de donnée (a long terme)

j explik enfin j essaie xD

imaginons deux tables :

table film :
id,id_membre,titre,resumer etc...

donc id_membre pour savoir qui a poster le titre.

et table membre

id_membre,username,mail etc...

il vaux mieux lors de la recup d info aller chercher username du posteur avec une seconde requete ou ajouter un champ posteur contenant l username du posteur dans la table film?

moogli

Salut,

En terme de performance be pense que la jointure s'impose simplement parce que c'est fait pour ;)

Plus sérieusement
La jointure va te retourner un membre par film et c'est ce que tu souhaite.

Si tu fait une requête et dans le traitement de celle ci une requête par tuple, même en gérant le fait que tu a déjà rencontré le membre (un tableau temporaire qui stock le pseudo en le réutilise plutôt que de faire une requête) tu peux potentiellement ajouter autant de requêtes que de membre. Si tu a 2 membres limite on s'en fou, si tu en a 10000 c'est 10000 requêtes de trop qui vont bouffer de la bande passante, du cpu, de la mémoire et du traitement (php) en trop.

Bref la jointure c'est fait pour, c'est bon manger z'en ;)

C'est pas les caractères en plus que tu va retourner qui vont plomber les perfs à côté du bouzion que j'ai indiqué plus haut

@+

vengeur002

merci moogli

LupusMic

Sur une table d'1M de tuples, la table temporaire nécessaire pour effectuer la jointure risque d'être conséquente.

Il n'y a pas de réponse universelle. Tout dépend :
- des fonctionnalités
- du trafic
- de la complexité

C'est là que le fait de ne pas baser la logique de son application sur la réprésentation des données en base de données est payant.

ploupy

Oui je te conseil également de faire une jointure et donc 2 tables car de cette facons, 1 membres peut poster plusieurs films, et si on fait une recherche des films qu'a poster le membre c'est direct.