Discussion :

[agslk]

Bonjour,

J'aimerais savoir si le nombre de tables dans une bdd MySQL a un impact sur les performances globales ?
Pour mon site e-commerce prestashop, j'ai une base avec plus de 4000 tables dont 90% sont des petites (moins de 10k lignes).
Ces tables sont générées par un module pour la mise en place de filtres personnalisés pour chacune de mes catégories.
Si oui, en quoi cela est "néfaste" pour les performances ?

Merci d'avance pour votre aide

[escartefigue]

Le nombre de tables importe peu, mais 4000 tables pour une seule base de données j'ai du mal à imaginer ce qui peut justifier une telle pléthore de tables !
Avec autant de tables, vous avez très probablement de nombreuses redondances de données, sans garantie de cohérence, or la première qualité d'une BDD est de garantir la cohérence de l'information.
Je doute que ce soit possible avec un tel modèle.

Pour les perfs il faut éviter les tables avec un très grand nombre de colonnes (tables dites "obèses') qui génèrent des contentions et de la charge réseau inutile.
Il faut également pister les index inutiles surtout s'ils sont multi-colonnes et non uniques
Enfin choisir des clefs concises et stables, donc non sémantiques

A partir de là, le fait qu'une table contienne des millions ou milliards de lignes ne nuit pas aux perfs, si les accès sont sélectifs via des requêtes sargables utilisant des index filtrants

[Artemus24]

Salut à tous.

J'aimerais savoir si le nombre de tables dans une bdd MySQL a un impact sur les performances globales ?

Chez moi, quand on parle de performance, je comprends le temps nécessaire à l'exécution d'une requête, mais aussi la volumétrie.

Donc non, cela n'a aucun impacte sur le temps d'exécution, mais cela risque d'avoir un sérieux impacte sur la volumétrie.
Sont-ce des tables d'archivages ? Des partitions ? Ou simplement le fait d'éclater une table principale logique en plusieurs sous-tables physiques ?

Pour mon site e-commerce prestashop, j'ai une base avec plus de 4000 tables dont 90% sont des petites (moins de 10k lignes).

4000 tables, c'est une hérésie en terme de base de données.

Ces tables sont générées par un module pour la mise en place de filtres personnalisés pour chacune de mes catégories.

Je ne connais pas prestashop. Il est difficile de dire si cela est adapté à ce que vous voulez faire.

Si oui, en quoi cela est "néfaste" pour les performances ?

Je voie essentiellement deux points :

1) les jointures sur une quinzaine de table n'est pas ce que j'appelle une bonne conception de votre base de données.
Plus il y a d'accès et plus long sera la récupération des données.
En fait, il faut voir d'une part la volumétrie et d'autre comment les jointures sont faites.

2) la multitude de tables suppose que vous avez un découpage par thème.
Cela sous entend que vous avez autant de sous-applications qu'il y a de thèmes.
Bonjour la maintenance !

Il vaut mieux avoir peu de tables, même très grosses en volumétrie et sans avoir trop de colonnes.
Une sélection filtrante serait le mieux pour avoir de bon temps d'exécution. D'où la gestion des index.

Mais la question cruciale est le SGBDR que vous utilisez !
MySql n'est pas ce qu'il y a de mieux si vous atteignez une certaine volumétrie.
Les temps de réponses risquent de s'allonger exponentiellement.

Acheter un package tout fait est la solution de facilitée.
Du sûr mesure serait mieux mais cela risque de coûter plus cher.

Au départ, vu que la volumétrie est faible, tout semble parfaitement fonctionner.
Mais à partir d'un certain seuil, vous allez vite comprendre que le choix MySql n'est pas très judicieux.
Encore que cela dépend aussi ce que vous faites dans votre applications.

@+

[SQLpro]

De tourtes façon, le modèle de données de prestashop est une vaste merde. Il contient déjà des tables obèses... J'ai dénoncé cela dans l'ouvrage que nous avons publié moi collègue Christian Soutou et moi sur la modélisation et que vous trouverez ici... De la à ajouter une mauvaise pratique de plus.. Cela ne m'étonne pas du tout....



A +