Discussion :

[vinze60]

Bonjour à tous,

J'ai actuellement une base de données qui commence à devenir assez importante en nombre de lignes

Je sais que de nos jours l'informatique permets d'atteindre facielement de très bonnes performance mais si je vous pose la question c'est surtout dans un but d'optimsation. Voici mon cas :

J'ai 4 ou 5 tables dont une qui commence a compter plusieurs dizaine de milliers de ligne (pour 4 colonnes)

A l'avenir, ma table depassera aisement la 100aine de milliers d'enregistements et probablement quelques 100aines encore en plus.

Mes requetes PHP interrogent cette grande table en la questionnant sur un numero de ligne. Par exemple "donne moi les informations sur la ligne n° 345 501"

J'imagine dans ma petite tête, plus on va interroger la BDD sur une ligne lointaine, plus elle va mettre du temps a parcourir la table. Ai-je raison ?

Deuxièmement, j'avais pensé, et vous allez m'aider pour ça, a une technique pour gagner en performance lors des mes requetes (qui sont nombreuses et fréquentes)

Puis-je imagine scinder ma GRANDE table, en plusieurs petites tables ? Du genre, au lieu d'avoir une table avec 500 000 lignes, en avoir 10 de 50 000 ? Une condition dans ma page PHP permetterai ainsi de selectioner la table souhaitez.

Est-ce que cette methode pourrait augmenter la vitesse de mes requetes ?

Merci par avance pour vos avis constructifs

[Snipah]

Bonjour,

Je pense que cette question aurait plus sa place dans le forum consacré au SGBD concerné, que vous n'avez pas précisé.

Si vous avez un index sur ce que vous appelez "numéro de ligne" et que vous accédez toujours à la table de cette façon, vous n'aurez sans doute jamais de souci de performance, quelques centaines de milliers de ligne n'est pas énorme.

Si vous constatez déjà des problèmes, la structure des tables, les index et les requêtes concernées nous permettront sans doute de vous en dire plus.

[Ghurdyl]

Parler de numéro de ligne dans une table en base de données est une assez mauvaise pratique.

A moins de trier la table on ne sait jamais vraiment à quelle ligne se trouve un record.

Mis à part ça, si ta table possède un champ (numérique c'est mieux) représentant ce que tu appelles le "numéro de ligne" il te suffit de créer un indexe dessus.

Si ton "numero de ligne" est défini comme clé primaire (identifiant unique) il est probable que ton SGBD l'aie déjà indexée.
Si non il faut te référer à la documentation de ton SGBD pour créer un index.

Une fois ta table indexée tu peut atteindre le million de record sans problème, même plus.

[vinze60]

Merci pour vos réponses !

Je n'ai actuellement pas de probleme de lenteur pour l'execution de mes requetes. Mais vu mes previsions quant aux quantités d'enregistrement, je preferais poser la question pour chercher la architecture à adopter.

Effectivement j'ai pas été tres clair, quand je parlais du numero de lignes je parlais d'index numerotés, (1, 2, 3, ... , 500 000).

Mes requetes sont du style Select champs1 FROM table WHERE id = 154 222 ;

Selon vos avis on peut donc considerer que l'enregistrement 15 ou 150 000 sera lu quasiement aussi rapidement ?

Autres question, y'a t'il une limite théorique dans le nombre d'enregistrements pour une table (a part la taille maximum des BBD fixé par les hebergeurs) ?

[al1_24]

y'a t'il une limite théorique dans le nombre d'enregistrements pour une table (a part la taille maximum des BBD fixé par les hebergeurs) ?

La limite théorique du type de données utilisé pour l'identifiant de ligne, associée à la limite théorique imposée par le SGBD

[Snipah]

Effectivement j'ai pas été tres clair, quand je parlais du numero de lignes je parlais d'index numerotés, (1, 2, 3, ... , 500 000).

Mes requetes sont du style Select champs1 FROM table WHERE id = 154 222 ;

Selon vos avis on peut donc considerer que l'enregistrement 15 ou 150 000 sera lu quasiement aussi rapidement ?

Oui, avec ce genre de requête vous n'aurez aucun problème de perf.

[vinze60]

Merci beaucoup pour vos réponses,

J'en profite pour appronfondir un peu le sujet.

J'ai placé un chronometre sur mes pages de requetes PHP. Le resultat n'était pas vraiment celui que j'attendais et j'aimerais votre avis.

Le temps d'execution vari entre 0,5 seconde et 3 secondes pour une requete qui fait appel à 5 tables et qui me retourne une centaine de resultat. Mes tables sont jointes par un index auto-incrementé numérique.

Je trouve que le temps d'execution est trop long, ai-je raison de penser ça ? est-ce que les performances du server sont à remettre en cause ?

Mon travail n'est qu'à l'état de projet pour le moment, je suis donc sur un server mutualisé qui ne me reviens pas cher. Une fois que mon projet sera finalisé je compte prendre les dispositions necessaires pour trouver un hebergeur capable de me fournir la performance adequeate.

Pensez vous que si j'opte pour le service "sql privé" d'OVH, cela me fera gagner du temps d'execution au niveau SQL ?

D'autre part que dois-je viser comme performance ? Ils proposent differentes offres (RAM a 128, 512, etc...) Je me doute bien que la memoire plus importante sera la plus efficace mais à partir de quel niveau serai-je censé voir une réele amelioration ?

[CinePhil]

Vérifie en postant les requêtes directement sur le serveur que c'est bien leur exécution qui prend du temps et pas autre chose parce ton chornomètre il dépend aussi de ton code pour générer les pages.

Vérifie aussi si tes requêtes ne sont pas plus complexes que nécessaires. Tu peux poster ici une de ces requêtes dont tu trouves l'exécution trop longue pour qu'on regarde si on peut l'optimiser.

Sinon, tu peux lire l'article de SQLPro sur l'optimisation d'un SGBD qui te donnera entre autres des infos sur la taille de la mémoire à envisager en fonction de la taille de la BDD.