Requete et Tags

5 réponses

Auteur	Message
tonguide \| Modérateur Inscrit le : 09/05/2005	# Le 09/07/2007 à 10:50 Bonjour, J'suis en train de voir pour faire un systeme de tags, mais j'ai quelques questions techniques pour optimiser le système. Donc c'est surtout niveau Table et Requete. On doit lier X articles avec X mots clés alors il y a plein de solution possible, mais aucune me plait réellement. Donc en théorie la meilleur que j'ai trouvé est la suivante : id du mot \| mot clé \| (le nombre d'article lié à ce mot pour les nuages de mots eventuellement) Suite à ça, on ferait donc une seconde table reliant le mot clé à l'article (ou autre). id d'un article \| id du mot Ce qui voudrait dire qu'un seul article pourrait générer 4 lignes. (donc 1000 articles = 4000 lignes) Et au niveau de la requete, on recupe l'"id du mot" via l'url, on fait une recherche dans la seconde table via "id du mot", on prend l'"id d'un article" en rapport puis on fait la liaison avec la table contenant l'article (via "id d'un article"). Voila, j'ai pas trouvé mieux, ça me semble lourd quand meme, donc si vous avez d'autres solutions, j'suis prenneur. Une dernière chose, une des utilités logiques que j'ai trouvé à ce système étant de soumettre aux visiteurs un ou plusieurs mots clés connexe à celui qu'il a recherché. (il cherche "pantalon" on lui soumet aussi "short", "pantacourt" pour agrandir les recherches possible). Et là pareil, pour récupérer ces mots connexes, ça me semble couteux. Jeremy
zimounet \| Quentin Membre Inscrit le : 22/03/2006	# Le 09/07/2007 à 16:11 moi je ferais qu'une table id - id_article - keyword oui ça te fera une grande table... mais en meme temps si tu gere bien tes index, et que tu bricole un bon system de cache.... la solution id - keyword - nb_article_lié avec une autre table pour gérer id_mot - id_article n'est peut etre pas si mal que ça... sauf que tu as un update a chaque fois qu'un tag est ajouté et que ce tag existe déjà (recherche si il existe déjà+ peut etre un update) donc selon moi mieux vaut faire le moins de requetes possible, et utiliser un bon cache et gérer tes champs indexer... et favoriser les select plutot que les updates!!! Ah, c'est balot madame Chombier!
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 09/07/2007 à 16:23 Bah je suis pas tout a fait d'accord sur le "et favoriser les select plutot que les updates" car des updates, il devrait y en avoir nettement moins que des Select logiquement. Un article est vu 1000 fois, donc 1000 Select légé alors que l'article tu l'ajoutes qu'une fois ... Je prefere ça à Un article avec 1000 Select "complexe" et pas d'update
zimounet \| Quentin Membre Inscrit le : 22/03/2006	# Le 10/07/2007 à 04:57 Ouais plus ou moins d'accord pour diverses raisons... j'ai la fleme de développer... Mais sinon pourquoi ne pas faire une table avec 1 Insert a chaque fois Et toutes les nuit tu regénère une autre table optimisé pour la lecture C'est a creuser aussi... Attend les avis des autres si tu veux, sinon je réfléchirais quand j'aurais les idées plus clairs. Mais tu n'as pas tord non plus c'est défendable. Ah, c'est balot madame Chombier!
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 10/07/2007 à 09:58 J'suis pas très fan des cron pour faire ça, mais c'est clair que ça peut-etre une bonne solution pour optimiser le tout. Par contre ça sera donc pas du direct (enfin on peut toujours s'arranger avec un mélange avec la table temporaire qui serait moins grosse). Enfin je cherche encore, si jamais il y a une solution idéal
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 10/07/2007 à 10:57 J'ai pas trop trouver de script ni de bout de code gérant ça, mais sur quelques forums spécialisés, ils conseillent de faire comme je l'ai annoncé en haut. Donc j'vais faire comme ça en attendant de trouver mieux

Auteur

Message

Inscrit le : 09/05/2005

# Le 09/07/2007 à 10:50

Bonjour,

J'suis en train de voir pour faire un systeme de tags, mais j'ai quelques questions techniques pour optimiser le système.

Donc c'est surtout niveau Table et Requete.

On doit lier X articles avec X mots clés alors il y a plein de solution possible, mais aucune me plait réellement.

Donc en théorie la meilleur que j'ai trouvé est la suivante :

id du mot | mot clé | (le nombre d'article lié à ce mot pour les nuages de mots eventuellement)

Suite à ça, on ferait donc une seconde table reliant le mot clé à l'article (ou autre).

id d'un article | id du mot

Ce qui voudrait dire qu'un seul article pourrait générer 4 lignes.
(donc 1000 articles = 4000 lignes)

Et au niveau de la requete, on recupe l'"id du mot" via l'url, on fait une recherche dans la seconde table via "id du mot", on prend l'"id d'un article" en rapport puis on fait la liaison avec la table contenant l'article (via "id d'un article").

Voila, j'ai pas trouvé mieux, ça me semble lourd quand meme, donc si vous avez d'autres solutions, j'suis prenneur.

Une dernière chose, une des utilités logiques que j'ai trouvé à ce système étant de soumettre aux visiteurs un ou plusieurs mots clés connexe à celui qu'il a recherché. (il cherche "pantalon" on lui soumet aussi "short", "pantacourt" pour agrandir les recherches possible).

Et là pareil, pour récupérer ces mots connexes, ça me semble couteux.

Jeremy

zimounet | Quentin
Membre

Inscrit le : 22/03/2006

# Le 09/07/2007 à 16:11

moi je ferais qu'une table
id - id_article - keyword

oui ça te fera une grande table...

mais en meme temps si tu gere bien tes index, et que tu bricole un bon system de cache....

la solution

id - keyword - nb_article_lié avec une autre table pour gérer id_mot - id_article

n'est peut etre pas si mal que ça... sauf que tu as un update a chaque fois qu'un tag est ajouté et que ce tag existe déjà (recherche si il existe déjà+ peut etre un update)

donc selon moi mieux vaut faire le moins de requetes possible, et utiliser un bon cache et gérer tes champs indexer... et favoriser les select plutot que les updates!!!

Ah, c'est balot madame Chombier!

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 09/07/2007 à 16:23

Bah je suis pas tout a fait d'accord sur le "et favoriser les select plutot que les updates" car des updates, il devrait y en avoir nettement moins que des Select logiquement.

Un article est vu 1000 fois, donc 1000 Select légé alors que l'article tu l'ajoutes qu'une fois ...

Je prefere ça à
Un article avec 1000 Select "complexe" et pas d'update

zimounet | Quentin
Membre

Inscrit le : 22/03/2006

# Le 10/07/2007 à 04:57

Ouais plus ou moins d'accord pour diverses raisons... j'ai la fleme de développer...

Mais sinon pourquoi ne pas faire une table avec 1 Insert a chaque fois

Et toutes les nuit tu regénère une autre table optimisé pour la lecture

C'est a creuser aussi...

Attend les avis des autres si tu veux, sinon je réfléchirais quand j'aurais les idées plus clairs.

Mais tu n'as pas tord non plus c'est défendable.

Ah, c'est balot madame Chombier!

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 10/07/2007 à 09:58

J'suis pas très fan des cron pour faire ça, mais c'est clair que ça peut-etre une bonne solution pour optimiser le tout. Par contre ça sera donc pas du direct (enfin on peut toujours s'arranger avec un mélange avec la table temporaire qui serait moins grosse).

Enfin je cherche encore, si jamais il y a une solution idéal

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 10/07/2007 à 10:57

J'ai pas trop trouver de script ni de bout de code gérant ça, mais sur quelques forums spécialisés, ils conseillent de faire comme je l'ai annoncé en haut. Donc j'vais faire comme ça en attendant de trouver mieux

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.