Reprise du message précédent :

j'avais pas vu ta question
 
Essentiellement pour approfondir C# et pour me concentrer sur un seul langage. Après on verra. Mon plus grand défi cependant est de sérieusement me mettre à ASP.NET, pas d'apprendre un langage.

ben un reseau social, c'est un forum avec un table "amis"    
 

Ah merde! C'est à ça que sert la liste de contacts sur HFR?

oué, mais comme ya pas de partie privé, ca sert pas à grand chose sur un forum  
 

Est-ce que vous vous servez souvent de la fonctionnalité qui affiche les "drapeaux" (les favoris, abonnements, coups de coeur, ...) sur la page d'index d'un forum à côté des topics suivis pour savoir si un message a été posté depuis notre dernière visite?
 
Personnellement dans 99% des cas je clique directement sur le bouton qui affiche ma liste des sujets suivis.
 
Je dis ça car mélanger les "drapeaux" sur les pages d'index du forum ça résulte en une jointure un peu moche à écrire et pénible à maintenir, alors que si le suivi des sujets ne se fait que sur une page dédiée, c'est beaucoup plus simple.
 
Je souhaiterais faire sauter les drapeaux mélangés afin de faciliter la maintenance de mon forum. Qu'en pensez-vous?
 
EDIT: argh ce n'est pas possible, j'ai besoin d'afficher si un visiteur a déjà lu ou pas tel sujet.

 
Perso pour cet usage, j'ai viré la jointure et je fais 2 requetes:  
 
- 1ere requete : Récupérer les ID de threads consultés par le membre dans le (sous-)forum concerné (ambiance SELECT thread_id FROM forum_drapals WHERE user_id=%d)
 
Je boucle les résultats pour les mettre dans un joli tableau.
 
- 2nde requete: Récupérer les threads, classiquement, pour afficher la page de forum.
 
Le mix des deux: topic consulté == in_array(liste_des_threads_consulté, id_du_thread_en_question).
 
C'est moins propre objectivement d'un point de vue SQL, mais c'est plus performant (2 requetes simples VS 1 requete alambiquée), et ca scale mieux.

 
ça doit pas être si complexe niveau sql à faire en une fois, faut pas déconner...
Si j'ai bien compris c'est juste un truc du style :
 

SELECT thread.*, type_drapal
FROM thread JOIN drapals ON drapal.id_thread = thread.id
WHERE drapal.id_user = ...

 
Après c'est facile à découper en php par type de drapeau...non?

SELECT thread.*, type_drapal
FROM thread JOIN drapals ON drapal.id_thread = thread.id
WHERE drapal.id_user = ...

+1
Avec un petit LEFT JOIN qui va bien, et le tour est joué. La requête n'est pas si alambiquée que ça, pas de problème de perf en perspective.
 

SELECT thread.*, type_drapal
FROM thread LEFT JOIN drapals ON drapal.id_thread = thread.id
WHERE drapal.id_user = ... OR drapal.id_user IS NULL

SELECT thread.*, type_drapal
FROM thread JOIN drapals ON drapal.id_thread = thread.id
WHERE drapal.id_user = ...

 
J'ai pas dit que c'était complexe, j'ai dit que c'était moins performant: un rapport 5 entre les deux, sur ma page "index du forum", méthode jointure = 55ms de génération, méthode requetes splitées = 10ms. Et question maintenance, ca se vaut bien ; question scalabilité, tu peux envisager de serialiser les drapeaux et les mettre dans memcache ou un de ses copains, pour un acces direct. Apres, savoir si tu acceptes de scinder une jointure pour une histoire de perfs, c'est un choix personnel en fonction du contexte, j'apporte juste mon retour sur le coté "perf brute".

C'est étonnant le problème de perf. Parce qu'avec une BDD correctement indexée, calculer une jointure externe c'est quand même pas grand chose pour le serveur.

@skeye: ta requête ne marche pas pour un affichage de l'index de topics d'un sous-forum (lu, non lu, participé ou pas), car si un topic n'a pas de drapeau associé pour le user, le topic ne sera pas retourné (à cause de ta clause WHERE). Par contre ça marche dans un menu qui n'affiche que les topics suivis.
 
@NazzTazz: j'ai pensé faire ça. J'avais peur des performances à cause des boucles à répétition (je bosse en Ruby), donc suite à ton post je vais creuser cette voie. Niveau maintenabilité c'est inégalable donc préferrable.
 
Question subsidiaire: vous séparez les drapeaux rouges et bleus? Personnellement je trouve qu'ils sont très similaires, et qu'un seul tableau avec une colonne supplémentaire "kind = read / write" pourrait faire l'affaire, mais j'ai peur de tomber dans un piège auquel je n'avais pas pensé.

La solution de skeye devrait fonctionner avec une jointure externe !

 

Il te manque pas des indexes quelque part?
 

Jointure externe dans ce cas, il y a deux mots à rajouter dans la requête.

 
Pas forcément, une requete avec jointure est en regle générale toujours plus gourmande que ses deux "parties jointurées" prises de maniere indépendante. Ca dépend aussi beaucoup de la charge du serveur sql j'ai l'impression, il faudrait que je teste dans un environnement "0 charge" et dans mon environnement habituel pour voir si y'a un point de recoupement entre les deux méthodes.
 
Enfin, c'est un point de vue strictement performances que j'expose ici: c'est le genre de conneries qui fait que j'ai pu faire passer la charge moyenne de mon cluster sql de 8 (en loadaverage) a 2 en scindant les jointures qui brassent le plus de lignes. Et, oui, mes tables sont correctement indexées

WTF?

si chez toi php est systématiquement plus rapide que l'équivalent direct en SQL il y a manifestement un gros problème avec ta bdd.

 
Je sais pas écoute, je remarque ca systématiquement quand je travaille sur un environnement ou web et sql sont éclatés sur plusieurs machines, j'ai tenté de réduire le phénomene en installant des liens directs entre mes nodes web et sql (oui, carrément un double réseau, un pour servir le contenu vers l'interweb, un pour écouler mon trafic "de service" (sql, nfs, toussa) en 1 gbps), j'arrive toujours a la meme conclusion Et ce, sur des DB simples comme sur des DB a 40 tables.

 
40 tables c'est une petite DB, vu d'ici (je travaille 90% du temps sur des DB >400 tables).
T'es sûr que ce n'est pas tout simplement que tes serveurs de DB sont sous-dimensionnés par rapport à tes serveurs http?

Je pense pas...

Nodes web:

Q6600 intel
2048 Mo registered
Raid 1 hardware 750 Go

Filers:

Q6600 intel (oui j'aime les Q6600 )
2048 Mo registered
Raid 1 hardware 147 Go SAS 10krpm

Nodes sql:

2 x L5410 intel (quadri-xeon)
4096 Mo registered
Raid 1 hardware 73 Go SAS 10krpm

Tu remarques que les serveurs sql ont en gros un proc 4 fois plus pechu que les nodes web et nfs, et aussi 2 x plus de ram ...

en terme d'utilisation:

...alors des indexes manquants ou un sgbd moisi sont les seules explications qui restent...
Jamais des opérations sur des tableaux php devraient aller plus vite que l'opération équivalente via une jointure...ou en tout cas uniquement sur des cas très particuliers...

Il utilise mysql? Puis si ça se trouve il join sur des colonnes en varchar en bonus?

(note: le commentaire est sur les backends "builtins", il y a des backends third-party avec des stratégies de joins moins limitées, mais uniquement à l'intérieur du backend en bypassant partiellement le query engine)

 
ok.

Je pensais qu'on l'avait assez dit sur ce topic, justement
 
Perso j'avais commencé avec des jointures, c'était bien indexé et tout, pour réaliser que ça allait franchement plus vite sans, et le coût de le faire en PHP est quasi nul. J'étais dégoûté

CAD ? Tu fais une requête, t'itère sur les résultats et pour chaque tu refais une requête ?
 
Et tu veux nous faire croire que c'est plus performant qu'une seule requête réellement optimisée faisant avec jointure ?

Quand je vois ça, ça me conforte dans l'idée que mysql, c'est un sgbd en carton

Non, tu fais deux requêtes dans deux tables sur un critère commun, et tu assembles le résultat en fonction de ce critère dans PHP
 
Dans le cas de drapeaux, le critère commun sera l'ID de sous-forum (ou catégorie, ou quelque soit le nom).

Si avec Mysql les jointures n'apportent rien (voir pire), cela signifie qu'on peut largement utiliser sqlite comme BDD? Des arguments contre?

Regarde peut-être du côté de postgres !?

Je tourne déjà avec Postgres, mais je pense que c'est un peu overkill pour mon utilisation. Avec Rails, par défaut ActiveRecord split les jointures en multiples requêtes.
 
J'ai lu des choses à propos de lock avec sqlite, et j'ai peur de faire une bêtise en basculant à sqlite  

Sinon, faut faire comme tous les gens biens et passer la db sous postgres

Tu peux avoir des problèmes de concurrence au niveau des écritures, me semble que ça lock tout le fichier donc faut faire gaffe avec ça si t'accèdes à ta db sqlite depuis des threads multiples. À noter que sqlite sait parfaitement faire des joins, je connais pas le profil de perfs par contre

Sinon, tu pars sur du nosql, genre une DB Redis, MongoDB ou Tokyo Cabinet/Tokyo Tyrant.

Oui ça lock tout le fichier en écriture, mais concrètement ça explose aux environs de combien de requêtes par jour / visites? Personne s'en sert en pratique pour son site web?
 
Les forums c'est un peu plus lourd niveaux requêtes qu'un site classique également.

Ça dépend de ton mix lectures/écritures, de la manière dont ta couche db accède à sqlite et de la complexité des requêtes (plus une écriture est longue et plus t'as de chances qu'un lock timeout)

Cf site de sqlite: http://www.sqlite.org/whentouse.html

il y a plus d'infos sur http://www.sqlite.org/cvstrac/wiki?p=WhenToUseSqlite

D'abord SQL Server 2008 histoire d'apprendre, puis je repasserai à Postgres

Je savais que c'était mal branlé, mais pas au point d'être systématiquement (beaucoup) plus lent.

Ok, donc déjà le cas que tu présentes c'est pas le cas classique d'utilisation de la jointure...
Là tu accoles deux tables qui ont la même PK en gros, genre t'as dénormalisé en cassant une table en deux, et tu les recolle via jointure.
C'est différent d'itérer sur des données et d'aller chercher d'autres infos pour chaque donnée dans une table à part, qui sans jointure ne se résout pas en 2 requêtes mais en N + 1 requêtes. Right?
 
Non parce qu'après on se retrouve avec des boulets de développeurs qui font N+1 requêtes parce qu'"on" leur a dit que les jointures étaient à bannir (vécu inside)...
 
 
Mais pour en revenir à ton cas de la jointure VS deux requêtes => tu compares dans quelle situation ? Avec le serveur SQL sur la même machine physique, ou distant, via le réseau ?
 
 

Ayé, on a un candidat à N+1 requêtes au lieu d'une jointure parce que les jointures "c'est le mal"

Non ici c'est deux requêtes sur une FK, pas une PK (enfin tu me diras, c'est pareil). C'est en MySQL et le serveur est sur la même machine. Je souligne que c'est un cas particulier, je repartirai d'une base propre sur un autre projet qui se fera sur un autre SGBD et situé sur une machine différente du serveur web.
 
Et c'est un cas précis, j'ai quand même des requêtes avec jointures un peu partout, je suis pas fou à ce point là

FlorentP a raison de souligner qu'il faut préciser qu'il faut être prudent, que les histoires de jointures à remplacer par x requêtes, c'est dans un cadre d'optimisation, dans des cas particuliers. Et comme il le souligne, Thomase en est la preuve !
 
Au départ, on écrit des "vrais" requêtes, avec des jointures. Et après, on optimise, après étude des goulets d'étranglements de l'application, ce qui peut amener dans certains cas à écrire deux requêtes simple plutôt qu'une requête un peu moins simple.
 
Mais dire, comme ça, de but en blanc, qu'il vaut mieux écrire x requêtes simples plutôt qu'une requête un peu plus complexe, sans préciser le contexte, c'est pas bien.

Ben pour moi, la jointure est inutile au moment ou on obtient le meme resultat pour chaque ligne de la deuxieme table, par exemple cette page (les reponse), je trouve inutile de faire une jointure entre la table cat,sujet,reponse , cependant il est utile de faire une jointure entre la table membre et reponse (pour avoir les pseudo, avatar, signature).
 
Mais est ce que c'est plus rapide de faire ça sans jointure ? ou bien c'est pareil ?  
 

Il faut aussi penser, dans le cas du listing des topics avec les drapeaux associés qui est décrit au-dessus, que la requête pour ramener la liste des topics peut être réutilisée par n'importe qui via le cache SQL directement, alors que ce n'est pas le cas si la requête est une jointure puisqu'elle sera destinée à une personne unique du fait de l'ID membre qui y traine. Ca peut aussi être intéressant, mais ça reste du cas par cas, car il y a trop de paramètres rentrant en ligne de compte pour être catégorique.

 
A la base on parlait d'un cas concret avec des tests effectués dans une configuration précise, avec une conclusion de circonstance.
 
Sinon oui, généralement il fait beau en été, et plutot moche en hiver, c'est vrai.

Tu ne sais pas réécrire une requête par jointure sur 2 tables en 2 requêtes?