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.

[vinze60]

Merci pour la réponse et le lien que je vais étudier !

Dernière question, voici l'exemple de deux de mes tables :

Table 1: TCLIENT
colonne : ID, nom, prenom, id_vendeur

Table 2 : TVENDEUR
colonne : id_vendeur, nom, prenom, age, poste

Ensuite je fais une requete du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT tclient.*, vendeur.*
FROM client
JOIN tvendeur WHERE tclient.id_vendeur = tvendeur.id_vendeur
WHERE tclient.id_client = '124515231212'

Sachant que un vendur à maximum un client (c'est pour l'exemple) ne devrais-je pas, au lieu d'avoir deux tables, en avoir qu'une seule du type :

Table 1 : TINFO
colonne : id, nom_client, prenom_client, nom_vendeur, prenom_vendeur, age_vendeur, poste_vendeur ...

Cette table deviendrait plus importante en volume mais est ce que ça me permetterais de gagner du temps lors de ma requete au lieu d'avoir un JOIN ?

Merci,

[CinePhil]

Tout est dans la considération :

(c'est pour l'exemple)

Parce que ceci :

Sachant que un vendur à maximum un client

C'est quand même très étonnant ! Je pense que c'est une situation qui ne doit pas durer. A moins que le client soit une grande entreprise, ce qui ne semble pas le cas puisqu'il est défini par un nom et un prénom.

Sur le plan sémantique, un client et un vendeur sont bien deux notions séparées.
Il se trouve que dans ton exemple le client et le vendeur sont deux personnes mais le client pourrait être une entreprise.

Conserve un modèle normalisé au maximum et n'aie pas peur des jointures.

Au passage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WHERE tclient.id_client = '124515231212'

Si l'id_client est, comme il est préférable, de type entier, inutile d'encadrer la valeur cherchée par des apostrophes.

[vinze60]

Merci beaucoup pour ta réactivité cinephil

Dans mon cas il s'agit d'une regle obligatoire : un vendeur = un client, ce n'est même pas possible de faire autrement. Et Quand je donne l'exemple du client et du vendeur c'est pour simplifier la presentation du problème. Il ne s'agit pas du tout de client ni de vendeur mais de toute autres valeurs qui seraient bien long à expliquer.

Par contre l'orgine du problème reste la même, pour être le plus explicite possible j'ai le choix entre :

Mettre des données dans UNE ou mettre des données dans DEUX tables.

Si j'ai deux tables j'utilise JOIN sinon j'utilise un simple SELECT.

Le problème que je pose là c'est de savoir choisir entre une seule et grosse table ou deux petites. JE demande votre avis pour ce cas théorique sans penser à la pratique de mes valeurs

PS : et merci pour la remarque sur l'ID, j'ai pas encore tout les reflexes