phpmydamin - sql definir la taille max d'une table

[starmindfr]

Bonjour

Petite question j'ai par exemple une table sql "tchat" avec le contenu du tchat du jeu, mais pour éviter de prendre trop de place en base (notamment si quelqu’un flood a mort le tchat) je voudrait trouver un moyen de limiter cette table par exemple a 1 Mo

Mais je ne trouve rien la dessus dans les docs... il y a un moyen simple de gérer la taille d'une table ?

merki

[MadMass]

A mon avis c'est une mauvaise idée, mieux vaut intégrer des règles de suppression (du genre les messages plus vieux de x secondes ou au bout de x messages).
Parce qu'il existe un système similaire pour les tables heap (les tables en mémoire) dont la taille maximale est limitée par une variable dans my.cnf, et par expérience, lorsque mysql n'a plus de place, il supprime rien, il se contente de ne plus ajouter. Donc un flood pourrirait tout le système :p
DONC je pense que faire ça à la mano, c'est plus sûr.
(Soit dit en passant si c'est du chat, les tables heap sont tout à fait appropriées, car on s'en fout de tout perdre en cas de crash du sql, et ça permet d'économiser les accès disques sur un module qui est fréquemment appelé). Faut juste limiter le nombre d'entrées sous peine de remplir de la RAM pour rien, et je crois qu'on peut pas stocker des varchar de plus de 500 caractères.

[niahoo]

Je plussoie, table en RAM c'est bien et si tu n'as pas cette possibilité selon ton hébergement, faire un script qui nettoie toutes les minutes. Même en RAM la suppression sera nécessaire si le fonctionnement est simplement de bloquer les nouvelles entrées quand la limite est atteinte.

Si tu veux garder une trace, tu peux simplement, en plus de ta base de données, écrire tous les messages dans un simple fichier de log. Le mieux est de le faire par lot, au moment du nettoyage par exemple.

[starmindfr]

humm j'ai commencer a regarder je ne trouve pas d'option dans ce sens (ram) sous phpmyadmin. En effet je pourrait faire tourner un script sql lié a un cron mais ca va rester sur quelques minutes, c'est deja pas mal mais pas ideal.

J'aurais bien aimer faire une limit sur l'index en auto increment de la table c'est un INT(11) mais visiblement si je met INT(1) pour forcer une limite de ligne ca ne fonctionne pas.

[MadMass]

Dans phpmyadmin faut aller dans opérations et choisir comme moteur de stockage de la table "MEMORY". Ca impose certaines restrictions, comme :
- Un nombre de caractères maximal sur les varchar aux alentours de 500 (de mémoire)
- Certains types de champs pas disponibles
- Impossibilité pour la table de dépasser la taille fixée pour les tables HEAP dans my.cnf (MAX_HEAP_TABLE_SIZE la variable)
- Perte de la table en cas de reboot/crash du serveur mysql
- Pas trop déconner avec les index parce que ça prend beaucoup de place, sur une grosse table ça peut vite se sentir :p

EDIT : ça sert à rien de vouloir limiter du côté de MySQL. C'est une source d'erreurs/bugs/surcharge/c'est dégueulasse et de toute façon MySQL préférera ne rien faire plutôt qu'effacer une donnée existante. Faut limiter dans le script lui-même, c'est à dire effacer des entrées à chaque insert ou avec une tâche cron en fonction des besoins

[t.bodeux]

Pourquoi utiliser une base de donnée pour un chat alors qu'on peut tout faire en temps réel sans encombre au point de vue stockage.

[MadMass]

Parce que peut-être que dans ce cas de figure c'est une solution inadaptée ? Des moyens y'en a plein, là on parle pas des différents moyens de faire un chat mais de la config de la db si on choisit de faire un chat + db.

[vol-au-vent]

Ton hébergeur acceptera l'utilisation de ta DB pour faire un chat ? Attention tu risques peut-être d'avoir des surprises !

[t.bodeux]

Il s'agit d'une simple question, le développement d'un jeu, au final, se résume à trouver l'outil le plus adapté à une tâche donnée. J'entend par là que parfois on planche sur des questions technique de l'outil avant d'avoir bien réfléchit à la nécessité de l'utilisation ce même outil.

[MadMass]

Par temps réel, tu fais allusion à quel type de techno ?