Discussion :

[mazertys17]

Bonjour,

Je nage un peu dans l'océan Mysql et j'ai peur de prendre le large alors je viens vers vous dans l'espoir d'avoir quelques conseils d'expert pour ne pas quitter le rivage tout en arrivant à destination .

Avoir beaucoup...beaucoup de tables dans une base de donnée est-il problématique ?

Beaucoup j’entend en centaines pas tellement plus tout de même.

OU dans ce genre de cas, vaut il mieux créer plusieurs bases de données différentes et si oui est-ce gérable, automatisable, facilement notament sur un serveur en prod ?


Merci si vous pouvez m'éclairer un peu.

[al1_24]

La question n'est pas le nombre de tables à gérer amis la raison pour laquelle il y aurait tant de tables...
S'agit-il d'un modèle de données très complexe ou la multiplication de tables de même structure ?

[mazertys17]

Ce serait plutôt la multiplication de tables d'une même structure.

Exemple diviser une map par carré de 100*100.

Si la map fait 1000*1000 au lieu d'avoir une table de 1 000 000, on aurai 100 tables de 100*100.
Et si on cherche une donnée sur une coordonnée, on va dirrectement cherché dans la table...

Aprés coup, je me dis qu'au final le meilleur moyen est de passer par un index, et de faire en sorte que cet index corresponde à une coordonnée.
On connaît la largeur et la hauteur de la map ainsi on retrouve l'identifiant par rapport à ça.

[escartefigue]

Le découpage en tables ne doit pas être guidé par la volumétrie.
Les tables doivent être la conséquence de la modélisation conceptuelle puis de sa dérivation, avec quelques aménagements, en modèle logique.
Pour les problèmes de volumes importants, il existe des solutions physiques telles que le partitionnement.

[al1_24]

Puisqu'il s'agit de matrices 2*2, pourquoi pas simplement une structure de type (Ligne, Colonne, Valeur) ?
Avec cela, plus de problème de taille de la dimension et rien n’empêche au besoin d'ajouter une colonne supplémentaire pour le partitionnement que tu évoques.

[Artemus24]

Salut à tous.

Avoir beaucoup...beaucoup de tables dans une base de donnée est-il problématique ?

Ce n'est pas le nombre de tables qui est problématique, mais la façon dont vous les gérez.

Beaucoup j’entends en centaines pas tellement plus tout de même.

Cela me semble beaucoup. Pourquoi avez-vous autant de tables ?
Peut-on connaitre la nature de vos tables ?

OU dans ce genre de cas, vaut il mieux créer plusieurs bases de données différentes et si oui est-ce gérable, automatisable, facilement notamment sur un serveur en prod ?

On ne peut pas répondre à cette question sans connaitre la modélisation de votre base de données.

Ce serait plutôt la multiplication de tables d'une même structure.

Est-ce pour une question de volumétrie que vous avez procédé à un découpage en petites tables ?
Si c'est le cas, avez-vous découpé vos tables en partitions ?

Exemple diviser une map par carré de 100*100.
Si la map fait 1000*1000 au lieu d'avoir une table de 1 000 000, on aurai 100 tables de 100*100.
Et si on cherche une donnée sur une coordonnée, on va directement cherché dans la table...

C'est peut-être clair pour vous, mais de quoi parlez-vous ?

Si vos accès se font par des coordonnées, il n'y a aucun intérêt à effectuer un découpage.
Un index sur vos coordonnées serait la solution, en admettant que chaque coordonnée soit unique.

Aprés coup, je me dis qu'au final le meilleur moyen est de passer par un index, et de faire en sorte que cet index corresponde à une coordonnée.

L'index est une meilleure solution qu'un découpage volumétrique par table.
Pour vous aider, il nous faudrait un peu plus d'explication, sans chercher à simplifier ce que vous désirez faire.

@+