{MySQL} Nombre maximum de tables ?

Fermé
latache - 14 sept. 2009 à 14:39
 latache - 14 sept. 2009 à 17:15
Bonjour,

Puis-je faire une table par client, en admettant qu'un jour j'en ai plus de 65535 ?
A voir également:

18 réponses

CaPiT Messages postés 609 Date d'inscription lundi 7 janvier 2008 Statut Membre Dernière intervention 21 avril 2010 51
14 sept. 2009 à 14:45
Bonjour, ça alourdit énormément ta base de données.

Et quel intérêt y a t'il à faire autant de table?
0
ben je ne vois pas d'autre solutions...

J'ai X clients qui doivent posseder une table de 300 enregistrements chacuns.
Cette table d'enregistrements est une table contenant un index et un chiffre pour chacuns des indexs.

Si je cree qu'une seule table pour ces enregistrements, je dois ajouter une colonne avec l'index de chaque clients. Dans ce cas je suis limité en nombre de colones.

Ou alors il faudrai que ces enregistrements soient dans la table client sous une cellule avec les 100 enregistrements separés de virgules, ce qui me parait difficile à traiter.
0
* 300, pas 100
0
J'ai fait un schema pour mieux m'expliquer :

<a href="https://imageshack.com/" target="_blank"><img src="http://img15.imageshack.us/img15/4384/tablegw.th.png" border="0" alt="Free Image Hosting at www.ImageShack.us" /></a><br /><br /><a href="http://img604.imageshack.us/content.php?page=blogpost&files=img15/4384/tablegw.png" title="QuickPost"><img src="https://imageshack.com/img/butansn.png" alt="QuickPost" border="0"></a> Quickpost this image to Myspace, Digg, Facebook, and others!

http://img15.imageshack.us/img15/4384/tablegw.th.png
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
euh

http://img15.imageshack.us/img15/4384/tablegw.png
0
CaPiT Messages postés 609 Date d'inscription lundi 7 janvier 2008 Statut Membre Dernière intervention 21 avril 2010 51
14 sept. 2009 à 15:22
J'ai toujours un peu de mal à comprendre entièrement le principe.

Tes 300 enregistrements/clients c'est quoi par exemple?
0
C'est une liste de cases pour un jeu. Chaques joueurs a ses cases perso.
0
Chacunes des cases contient un chiffre, on peut dire une somme d'argent par exemple.
0
J'avoue que je n'avais jamais été exposé à ce genre de situation algorithmique, peut etre que je m'y prends mal mais je ne vois pas d'autres solutions en fait...
0
CaPiT Messages postés 609 Date d'inscription lundi 7 janvier 2008 Statut Membre Dernière intervention 21 avril 2010 51
14 sept. 2009 à 15:59
Une solution pourrait peut-être être la suivante.

Tu créer 2 tables :
- clients
- cases


Relation 1.1-1.N en fait.

La table client contiendrait toutes les infos clients.
La table cases contiendrait toutes les autres infos :
N° Cases| N°Client | Valeur
1           | 1           | Val1
2           | 1           | ...
...
299       | 1           | ...
300       | 2           | ...
301       | 2           | ...
...
599       | 3           | ..
600       | 3           | ..


Mais ça me plait pas énormément.
Tes 300 cases n'ont aucun rapport selon les clients?
Elles ont des valeurs différentes oui mais ont-elles des noms différents.
En fait c'est pas très concret donc je galère un peu ^^
0
Je vois ce que tu veux dire mais alors pour rechercher la 268eme case du 100 000eme client je dois d'abbord avoir une table case avec 100000 * 300 lignes, soit une table de 30 millions de lignes déja !
Et ensuite faire 100000 * 300 - (300-268) pour trouver l'index correspondant.
Ca me parait beaucoup plus bizare que de creer 100000 tables ?

En tous cas merci de ton aide, j'espere pouvoir resoudre ce probleme. Selon toi c'est mieux de gerer une table de 30 million de lignes que 100000 tables ?
0
de 300 lignes ?
0
Je sais, je prevois gros, je n'aurai peut etre pas 100 000 clients mais je compte faire beaucoup d'IA donc ça se pourrait que j'atteigne de telles valeurs.
0
CaPiT Messages postés 609 Date d'inscription lundi 7 janvier 2008 Statut Membre Dernière intervention 21 avril 2010 51
14 sept. 2009 à 16:25
En fait ce qui me dérange c'est la création d'une table lorsque tu as un nouveau client.

Pour moi, le fait qu'il y ai un nouveau client ne doit pas impliquer un changement de la structure de la base de données (en l'occurrence ici la construction d'une nouvelle table), mais plutôt un ajout de données (des INSERT dans tes tables cases et client).

Après je ne sais pas trop ce que représente tes cases, donc je ne peux pas plus t'aiguiller.
0
Oui moi aussi ça me paraissait plus logique, mais ça implique un coeficient multiplicateur de ligne comme tu m'a proposé. Et je ne sais pas à combien se limite le nombre de lignes non plus.

Pour t'en dire plus, imginons un jeu simple. Chaque joueur possède 300 cases qui changes de valeurs assez regulierement.
Lorsqu'un autre joueur choisi une case d'un autre : il peut changer la valeur, la copier ou encore la remettre à zero. Je ne peux pas faire autrement et je suis obligé de sauvegarder ces valeurs.

Je ne peux pas mieux t'expliquer. Le concept du jeu n'en est qu'à ces balbutiement, je dois faire ça avant d'envisager la conception du gameplay.

Ca me parait pourtant etre une situation classique, je suis etonné que personne puisse me repondre. Comment font les autres webmasters pour gerer beaucoup de données sur beaucoup de clients ?
A part en mettent directement les 300 valeurs dans une cellule, separé par des virgules mais à ce moment là SQL ne m'aide pas vraiment. Mes requetes se feraient en php sur des tableaux de valeurs, ça m'ennuie un peu.
0
C'est dingue, heureusement que mes joueurs n'ont que ça ! Et si j'avais 300 carrés de 300 cases par clients je ferais comment ?

pour 100000 joueurs : 30 millions de tables ?

Ou une table de 9 milliard d'enregistrements ?

Et si le nombre de carrés par joueurs n'etait pas constant ? Comment gerer ça sur une seule table ? Bref je n'en suis pas là mais ça me parait surréaliste. Je me demande comment font les autres !
0
CaPiT Messages postés 609 Date d'inscription lundi 7 janvier 2008 Statut Membre Dernière intervention 21 avril 2010 51
14 sept. 2009 à 16:56
Il m'est arrivé de devoir gérer plus de 1000 articles avec pas loin d'une centaine d'attributs par produits (prix, couleur, marque, taille....).
Tu as donc une table attribut_produit ou uniquement les 100 attributs sont stockés. Il y a l'id, le nom de l'attribut et le type de la valeur que prendra l'attribut (varchar, int, text, booléen...)

Une table produit, ou les 1000 produits sont référencés (juste l'id et le nom du produit).

Puis des tables de stockage intermédiaires qui relis tout ça du style :
- produits_attribut_varchar
- produits_attribut_int
- produits_attribut_text

C'est un système plutôt complexe (que je t'ai grandement simplifié) et qui permet de stocker énormément de données.
0
Le pire c'est que moi aussi j'ai déjà fait des bases avec beaucoup de données. Avec des tables liens entre les deux. Je ne suis pas complètement débutant mais je m'etais deja inquiété sur la façon de gerer beaucoup de données differentes sans aucun lien entre elles et là je tombe en plein dedans.

A priori le mieux serait ça :

client | valeur
21546 1451,546514,4564,1564,456541... (x300)
16554 54,4564,412,45684,456,456,1444...(x300)

ensuite en php je fait un explode()

Parce que là je sèche...
0