[SQL] couper une grosse table en plusieurs tables

[php_addict]

bonjour

je sais bien qu'il est inutile de couper une grosse table SQL en plusieurs autres plus petites tables pour accélérer la vitesse d'exécution des requêtes (les index sont là pour ca :good: )

mais je me demande quand même si il n'y a pas un autre intérêt et j'aimerais connaitre votre avis sur mes interrogations suivantes:

- avec plusieurs petites table, elles sont moins souvent interrogées que la grosse table, non ? y a t il un avantage à cela ?

- dans le cas de nombreux joueurs connectés, y a t il un intérêt a avoir plusieurs petites tables au lieu d'une grosse (je parles de table...humhum...)

- une grosse table a peut etre plus de chance de se fragmenter ? vaut t il mieux des petites tables fragmentées qu'une grosse table fragmentée ?

- est ce que vous utiliser plusieurs petites tables au lieu d'une seule et meme grosse table? si oui pourquoi?


voili voilou, c'est tout .. merci encore une fois de m'avoir lu

[pascal]

Que veux-tu dire par grosse table ?

Une table avec de nombreuses colonnes ? Autre chose ?

Si les tables sont en relation 1-1, c'est inutile.
Si c'est des relations 0-1 (pour des données optionnelles), pourquoi pas.

Coté performances, c'est pas quelques centaines d'enregistrement qui vont jouer; le choix du type de table, les index, la manière d'écrire les requêtes sont plus importants.

A+

Pascal

[php_addict]

Que veux-tu dire par grosse table ?

Une table avec de nombreuses colonnes ? Autre chose ?

5 champs (INT, SMALL INT, et TINY INT) mais presque un million d'entrées avec les index appropriés

Si les tables sont en relation 1-1, c'est inutile.
Si c'est des relations 0-1 (pour des données optionnelles), pourquoi pas.

qu'entends tu par relation 1-1 et 0-1 ?

[pascal]

relation 1-1 :
Chaque enregistrement de la table A posséde un et un seul enregistrement dans la table B.

relation 0-1:
Chaque enregistrement de la table A peut avoir zero ou un enregistrement dans la table B.

Quelle table ferait un million de lignes ? Pour stocker quelles données ?
Est-ce que c'est utile de conserver ce nombre de lignes ?
Avec ces indications ça sera plus concret.

A+

Pascal

[php_addict]

Quelle table ferait un million de lignes ? Pour stocker quelles données ?

ma map

[Sephi-Chan]

Une seule table suffira. Peu importe le nombre de lignes qu'elle contiendra.


Sephi-Chan

[pascal]

1000 * 1000 cases ?
C'est grand.

Tu peux ne pas enregistrer les cases les plus nombreuses, genre la mer ou le désert serait un terrain par défaut s'il n'y a rien en DB.

A priori la table serait en lecture principalement, donc pas trop de soucis.

A+

Pascal

[php_addict]

je ne compte pas afficher de grosses portions de map, mais comment feriez vous avec une map de 1000 * 1000 cases pour afficher un extrait de map de 300 par 300 par exemple?

[Argorate]

Salut,
perso, se que j'ai fait pour mes millions de cases de map, j'ai retirer le terrain qui revient le plus, dans mon cas : "ocean profond" qui recouvre environ 48% de la map, de 5.6 millions de cases je suis passé a 2.9 en BDD.

j'affiche la map (et il est loin d'y avoir que les terrains a afficher) en 0.00085997581481934 seconde en moyenne pour afficher 11*11 cases, donc pas besoin de couper en plusieurs taille.
Tu ne doit avoir en théorie que X, Y, TYPE_TERRAIN dans ta table. (des chiffres qui sont indexé et donc c'est très rapide...)

Par contre pour afficher 300*300... :[

je vois pas a quoi sa te servirais en fait?

[DragonMaster]

1 million de lignes pour un SGBD c'est pas très énorme. Ne t'inquiète pas pour le performance avant un moment.