Version imprimable
Bonjour
Je développe (en amateur) une base de données avec plus de 10000 à 20000 lignes et trois nouvelles colonnes par jours.
En partageant mon expérience avec un ami il m'a dit que MySQL était limité à 260 (je crois me souvenir) colonnes. Or ce nombre est dépassé depuis bien longtemps !
Tout ce que j'ai trouvé sur la taille est : http://mysql.developpez.com/faq/?pag...EURS_MAX_table
Il pourrait aussi y avoir une ligne pour répondre à ma question ;)
Bonjour,
Tu es sûr qu'il n'y a pas un problème de conception ?
J'ai conçu simplement le système avec trois nouvelle prise de données par jour.
Si la taille est limitée, alors, il y a un problème. Sinon, je ne vois pas en quoi ce serait un problème ;)
Si tu ajoutes 3 données par jour, ce devrait faire 3 lignes et non pas 3 colonnes, sinon, je pense qu'effectivement, il y a pb de conception.
Je rajoute un nombre indéfini de lignes et trois colonnes.
Donne un exemple, car je ne comprends pas ce que tu fais.
Je prends des prises de données chaque jour sur un ensemble de points qui augmente régulièrement.
Je mets donc un point par ligne et 3 colonnes par jour. Le nombre de lignes augmente bien plus que le nombre de colonnes.
Désolé, je dois être bouché, mais je ne comprends toujours pas.
Une colonne est un ensemble de mesures à un moment donné et une ligne est un point où je fais des mesures.
Le nombre de points où je prends des mesures augmente => le nombre de ligne augmente régulièrement.
Le nombre de mesure augmente => le nombre de colonne augmente.
Mais le nombre de ligne augmente plus vite que le nombre de mesure.
Un exemple simple très simple de façon à te faire comprendre jeca:
S'il est responsable de la prise de température de villes. Aujourd'hui, il ne prendra que ce que son contrat lui indique: par exemple Paris, anger, Arras. Demain, son commerciale lui dit: nous avons aussi Marseilles, Lyon, Valence... comme son commerciale démarche au jour le jour et bien sa cardinalité n'est pas fixe.
jour 1
Paris anger Arras
8 10 2
jour 2
Paris anger Arras Marseilles Lyon Valence
8 10 2 null null null
8.5 7 8 14 12 12
jour 3
Paris anger Arras Marseilles Lyon Valence xx xx xx
8 10 2 null null null null null null
8.5 7 8 14 12 12 null null nul
xx xx xx xx xx xx xx xx xx
ainsi tu vois bien que toutes les cardinalités augmentent au jour le jour, donc aucuns problèmes de conception :D
enfin pour répondre à ta question troumad, la réponse officiel est celle ci
http://http://dev.mysql.com/doc/refm...unt-limit.html
4096 colonnes max mais en réalité, la table ne doit pas excéder 65,535bytes soit 85 colonnes de char(255)
Si tel est le cas, on se trouve dans le même schéma qu'une facturation avec une table d'entête et une table de détail. Il y a donc pour moi un pb de conception.
Cela donnerait :
Ce qui fait que pour une journée xx, on peut ajouter autant de villes qu'on veut, et pour chacune d'elle xx relevés, sans avoir à toucher la structure d'une table.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
oui faire deux tables est idéale dans ce cas, mais il servait juste à te montrer que c'etait envisageable. Peut être qu'il s'intéresse seulement au coté performance et limit du sujet.
Je trouve que c'est plus simple à gérer avec une seule table !
Bonjour,
Tes explications sont très abstraites pour moi.
Cela étant, voilà comment je traduis :
- les points de mesures sont des emplacements dénommés ;
- les types de mesures sont identifiés et dénommés ;
- pour chaque point, à une date-heure précise, un nombre variable de mesures de types différents est effectuées.
Si tel est le cas, nous nous trouvons dans un schéma d'application de facturation, et voilà donc celui que j'utiliserais :
table 'point_mesure'
id_point (autoincrément)
nom_point
table 'type_mesure'
id_type (autoincrément)
nom_type
table 'mesure'
id_mesure (autoincrément)
point_id (lié à 'id_point' de la table 'point_mesure')
date_heure_mesure
table 'mesure_detail'
mesure_id (lié à 'id_mesure' de la table 'mesure')
type_id (lié à 'id_type' de la table 'type_mesure')
valeur_mesure
Avec cette structure, tu peux à n'importe quel moment :
- créer un nouveau point de mesure,
- créer un nouveau type de mesure,
et pour chaque mesure, ajouter autant de type de mesure que tu le souhaites. Cela sans avoir à multiplier le nombre de colonnes d'une table.
Tu vas me dire que le nombre de lignes va devenir énorme. Extrait du manuel mysql :Citation:
L'intervalle de validité pour les entiers signés est de -2147483648 à 2147483647. L'intervalle de validité pour les entiers non-signés est 0 à 4294967295.
Je ne connais pas la finalité de ton application, donc, le schéma que je t'ai soumis n'est pas obligatoirement adapté à 100 %. Sans information plus précise (par exemple, quelques lignes de 'mouvements', tels que tu les reçoit), il est difficile de dire mieux. Quoiqu'il en soit, le fait d'ajouter à la volée des colonnes à une table n'est en aucun cas une solution.Citation:
Envoyé par troumad
Si tu marchandes un peu, je te le fais avec une table en moins. :lol:
Et puis, si tu as besoin de stats, par exemple, tu t'apercevras très vite que c'est beaucoup plus simple à exploiter avec des tables multiples.
J'avoue que je ne suis pas un expert en DB ! Je préfère largement les BD (Astérix ou autres :) ).
Donc, je me schématise mieux les liens avec une seule table. Mais le système avec plusieurs table peut avoir quelques avantages dont la rapidité. Mais avec des entiers comme type dans chaque ligne, je ne suis pas prêt de faire exploser ma table !
Bonjour (me revoilà !)
J'avais laisser tomber le sujet quelques temps... Depuis, mon système tourne avec une seule table et il tourbe encore...
Mais, j'ai essayé de réfléchir à un système avec plusieurs tables, j'en suis à la mise en place de ces tables. Et bien, avec le système précédent, c'est presque automatique, cette fois, ça me demande plus de 40 min pour remplir mes tables.
Chaque jour je récupère une table avec les données du jour : http://s8.travian.fr/map.sql
Je rajoutais les colonnes du jours à fin la d'un précédente table :J'ai essayé autre chose, des petites tables :Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Une pour les alliances qui permet de faire le nom entre le numéro de l'alliance (aid) et son nom (alliance)
Une autre pour le nom des joueur : faire le lien entre leur numéro (uid), leur nom (player) et leur tribut (tid).
Une autre pour repérer le parcours dans le temps des joueurs dans leurs alliances où je repère les changements d'alliances. J'ai comme champ, l'uid, la date, l'aid. À la date donnée; le joueur uid passe dans l'alliance aid.
Une autre ville_nom ou je retiens pour chaque ville ses identifiants (id ou vid), ses coordonnées x et y ainsi que son nom.
Une dernière où je mémorise l'historique des villes avec comme champ l'id de la ville, la date, l'uid de son propriètaire et la population.
Les informations que je souhaite conserver sont :
Quel jour le joueur est dans quelle alliance (ça peut changer)
=> Je dois repérer les nouveaux joueurs
Quotidiennement pour chaque ville : population et propriétaire
=> Je dois chercher une à une les villes et repérer les nouvelles
=> Je modifie le nom s'il a changé (mais, je ne garde pas de trace).
+
=> Je dois repérer chaque jour si une nouvelle alliance se crée ou mettre à jour le nom de l'alliance.
J'en reviens à une question de vitesse... Que vaut-il mieux faire :
Tester si un champ avec une clef unique existe déjà ou insérer directement ce champ ?
Je me demande s'il est rentable de décomposer ceci en petit bouts !
Et bien, je peux dire que le traitement du système est passé de 40 min à 17s si je ne vérifie pas ça !Citation:
Envoyé par troumad
Sache que losque je fais un audit de BD, toutes les tables qui ont plus de 20 colonnes sont préalablement suspectes pour moi. Il faut que son auteur m'explique pourquoi. Il va sans dire qu'au dela c'est plus que déraisonnable !
Une base de données relationnelle, comme son nom l'indique est faites pour gérer des relation. pas pour faire du traitement de texte, ni des fichiers COBOL !
Enfin en principe votre modèle de données devrait être fixe. Chaque fois que vous altérez une table, vous perdez ça mise en cache... Bref, comme si vous utilisiez des fichiers COBOL et non un SGBDR !
Soit vous vous mettez au relationnel et vous verrez les performances arriver; soit vous continuez en fichier COBOL, mais alors faites le avec du vrai COBOL, c'est ce qu'il y a de plus performant encore pour les accès fichiers !
A +
Si on veut être rigoureux, tester avant ne sert à rien à partir du moment où il y a des utilisateurs simultanés. En effet, durant le laps de temps entre ton test et ton insertion, une autre session peut parfaitement rendre ton test caduc.Citation:
J'en reviens à une question de vitesse... Que vaut-il mieux faire :
Tester si un champ avec une clef unique existe déjà ou insérer directement ce champ ?
Sinon, de manière générale, ce qui prend du temps est la communication entre PHP et MySQL, beaucoup plus que le travail à l'intérieur de MySQL lui-même. Il faut donc réduire le nombre de requêtes, quitte à les rendre plus lourdes. Une seule grosse requête est (presque) toujours plus performant que plusieurs petites. En conséquence, exécuter une requête à l'intérieur d'une boucle est généralement une très mauvaise idée...