Message populaire. Neoxy Posté 2 Avril 2010 Message populaire. Partager Posté 2 Avril 2010 Bonjour, Je développe actuellement un site en plusieurs langues, cependant, j'ai des doutes concernant l'optimisation de la structure de mes tables... En, effet, j'ai une table produit et une table description qui comprend des contenus traduits : Table Produit : id_produit.. Nom_produit, prix_produit... Table Description : id_produit, langue, contenu... Sachant que je lie la table produit à la table description lorsque je cherche une description dans une langue précise.. Le soucis avec la table description est que je dois créer une ligne pour chaque description : Example 1 - fr - "Description FR blablabla" 1 - en - "Description EN blablabla" 1 - es - "Description ES blablabla"... Le modele actuel me permet de bénéficier d'une table avec 3 colones, mais 1 000 000 d'enregistrement (du fait du nombre de langues)... Je voulais savoir s'il serais pas plus judicieux et optimisé de créer une ligne par description : Table Description : id_produit, contenuFR, contenuES, contenuIT.... (dans ce cas la, je pourrais aussi mettre les collones contenuFR, contenuES, contenuIT dans la produits...) Pour ce modèle la, j'ai une table avec plus de colones (parfois vides), mais beaucoup moins de lignes (environ 50 000)... Ma question générale est : Es ce qu'on dois privilégier les données sur une seule table en multipliant les colones, ou es ce que je dois privilégier, l'éclatement des données en travaillant sur plusieurs tables, afin d'effectuer de belles jointures lors de mes requetes... Je cherche à optimiser les performances Mysql, car il y a un paquet de données... Et j'ai remarqué que les jointures pouvaient prendre du temps à mysql pour retourner des résultats, surtout s'il y a beaucoup de données... Merci d'avances pour vos idée 1 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Dadou Posté 2 Avril 2010 Partager Posté 2 Avril 2010 Tu es bien mieux de créer une ligne par langue, car si demain tu veux rajouter d'autres langues tu n'auras pas à modifier la structure de tes tables et tes requêtes. Normalement, si tes tables sont correctement indexées tu n'auras quasiment pas de problème de performance. C'est à dire, sur ta table Description il faut que tu créé un index sur la colonne langue aussi Lien vers le commentaire Partager sur d’autres sites More sharing options...
Neoxy Posté 2 Avril 2010 Auteur Partager Posté 2 Avril 2010 Donc si je comprend bien, je modèle que j'utilise actuellement est plutôt correct, mais est-il optimisé et rapide ??? C'est vrai que si je met tout dans une seule table, je risque d'avoir des données Null, car tous les contenus ne seront pas traduits... J'ai déja posé des indexes sur les champs concernés par des contraintes (where) Mais le soucis, c'est que j'ai beaucoup de données, et mes requetes sont quand même lentes (plus d'1 seconde) car ma requete utilise 3 ou 4 jointures... Es ce que ce ne serait pas mieux d'effectuer une requete sur une table de 50 000 tuples avec peu de jointures, (avec quelques cases vides) Car effectuer une requete avec plein de jointures sur des tables comprenant des centaines de milliers d'enregistrement semble assez lourd... Après, si je dois modifier la structure de mes tables et des requêtes, c'est pas grave Je recherche la performance et l'optimisation Lien vers le commentaire Partager sur d’autres sites More sharing options...
Dadou Posté 2 Avril 2010 Partager Posté 2 Avril 2010 C'est tes jointures qui a mon avis mériteraient d'être optimisées, il faudrait voir la requête complète et les structures des tables Lien vers le commentaire Partager sur d’autres sites More sharing options...
jcaron Posté 2 Avril 2010 Partager Posté 2 Avril 2010 +1, c'est nettement mieux d'avoir une ligne par langue, avec un bon index sur (id,langue), et hop. Comme ça, quand tu as besoin de la description en langue X pour le produit Y, il ne va charger que ça, alors que sinon il faut qu'il charge toute la ligne pour en extraire le bon champ. Si les descriptions sont un peu longuettes, ça peut faire une différence non négligeable. Ceci dit, je mettrais aussi le titre dans cette table, sauf cas très particuliers, ça a tendance à devoir être traduit aussi :-) Et puis le prix reste le même (et dans la même devise) pour tout le monde? Dubitatif je suis :-) Jacques. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Neoxy Posté 2 Avril 2010 Auteur Partager Posté 2 Avril 2010 Hello à vous et merci pour vos réponses... Il me semblait que ce modele de donnée était le plus adapté ... Mais j'ai quand même eu un petit doute Pour les index, je pense que c'est ok puisque les champs langue et id_produits sont en clé primaire (donc à prioris, pas besoin de rajouter d'index...) J'ai veillé à ce que les indexs soient correctement placés dans les bons champs.... En fait, j'ai trouvé d'autres pistes concernant la lenteur des requetes, notamment l'utilisation de SQL_CALC_FOUND_ROWS qui a tendance à doubler le temps d'execution... J'ai aussi remarqué qu'une jointure Left Join ralentissait la requete quand on j'effectue un where sur un des champs concerné... Es ce que vous avez remarqué que left join étais gourmand en ressources lorsqu'on pose une contrainte sur l'un des champs ??? c Lien vers le commentaire Partager sur d’autres sites More sharing options...
jcaron Posté 2 Avril 2010 Partager Posté 2 Avril 2010 Ce serait plus facile avec un exemple concret... Jacques. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Neoxy Posté 4 Avril 2010 Auteur Partager Posté 4 Avril 2010 Hello, Finalement, j'ai résolu mon soucis j'ai réussis à optimiser mes requetes comme je le voulais Merci pour votre participation ! Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sarc Posté 4 Avril 2010 Partager Posté 4 Avril 2010 Neoxy, si je peux me permettre : Webmaster-Hub est un lieu d'échanges. Certains membres t'ont répondu et conseillé des choses ; en retour, il serait bon de ta part que tu expliques les difficultés que tu avais, et comment tu as fait pour optimiser tes requêtes, tes jointures, etc. Ça pourra sûrement intéresser pas mal de visiteurs qui cherchent à avoir un site plus rapide ! Merci d'avance ! Lien vers le commentaire Partager sur d’autres sites More sharing options...
Neoxy Posté 5 Avril 2010 Auteur Partager Posté 5 Avril 2010 Avec plaisir ! C'est vrai que tu as raison SARC, je vais éclaircir mon soucis... En fait, je cherchais à optimiser la vitesse de mes requêtes, qui prenaient parfois plus d'une seconde pour s'exécuter... Après de nombreux tests et lectures sur le net, j'ai remarqué que la clause Mysql : SQL_CALC_FOUND_ROWS doublait la vitesse d'exécution de ma requete ... Cette clause permet de calculer et de retourner le nombre de résultats total d'une requête (sans prendre en compte les limits...) en une seule requete : idéal pour un système de pagination... Cependant, j'ai remarqué que je gagnais du temps en exécutant une seconde requête du type : select count (id)... pour connaitre le nombre total de résultats... Voila, je pensais par ailleurs avoir un soucis avec les left join, mais en fait, ce n'est pas le cas ! J'espère que ma réponse pourra aider des développeurs qui se sont arrachés les cheveux comme moi Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant