Nettoyage de base de donnée

[phenix]

Bonjour à tous,

C'est un fait, les joueurs, sa va, sa vient, et a partir d'un moment il faut supprimé les comptes inactif.

Malheureusement, un compte, sa a des répercutions sur plein d'autres tables de la base de donnée. C'est fastidieux à faire de supprimer les entrés dans chaque table surtout sur un jeu qui bouge beaucoup.

Est-ce que quelqu'un connaît un bon moyen de nettoyer la base de donnée ?

[Studio Gamboo]

Soit utiliser l'intégrité des données d'une base innoDB, soit faire un joli script php qui s'occupe de faire tout ça pour chaque compte

[phenix]

Soit utiliser l'intégrité des données d'une base innoDB

Je sais pas ce que c'est mais sa m'intéresse :heuuu:

soit faire un joli script php qui s'occupe de faire tout ça pour chaque compte 2

Ben justement je voudrais savoir s'il y a un moyen d'éviter sa.

[z3d]

Soit utiliser l'intégrité des données d'une base innoDB

Je sais pas ce que c'est mais sa m'intéresse :heuuu:

soit faire un joli script php qui s'occupe de faire tout ça pour chaque compte 2

Ben justement je voudrais savoir s'il y a un moyen d'éviter sa.

Utiliser des contraintes d'intégrités référentielles est la seule façon de se passer d'un tel script.
Pour ce faire, la base de données doit utiliser le moteur de stockage INNODB.

[Cartman34]

je pense déjà que créé trop de table est une erreur et se poser se genre de question...proche de l'inutile.
un script PHP fait très bien son affaire, en créant une méthode/fonction qui supprime les référence au joueur supprimé est très pratique et rapide(contrairement à certaines idées...le moteur MyISAM est assez puissant).

Cependant, utiliser "contraintes d'intégrités référentielles" d'InnoDB peut être une meilleure solution si elles sont bien utiliser.

[Kassak]

Trop de table une erreur?

Je ne pense pas, pour ma part, je préfère avoir une table qui sert a une chose, et pas qui peut servir a 2 ou 3 trucs différents.
Avec ça, je dois avoir 38 tables je pense, et je pense encore en avoir besoin d'autre, mais je ne pense pas que se soit un problème ensuite.

Pour ce qui est de supprimer les données d'un joueur, pourquoi se prendre la tête? Il suffit de récupérer dans chaque table l'entrée correspondant au joueur et tu supprimes, tu fais cela autant de fois qu'il y a de table, donc dans une fonction, ou une boucle, ou ce que tu veux, non?

[phenix]

je pense déjà que créé trop de table est une erreur

Absolument pas, une base de donnée bien construite et un jeu avec plein de fonction demande un nombre de table important. Moins il y a d'entrer dans une table plus c'est performant.

Pour ce qui est de supprimer les données d'un joueur, pourquoi se prendre la tête? Il suffit de récupérer dans chaque table l'entrée correspondant au joueur et tu supprimes, tu fais cela autant de fois qu'il y a de table, donc dans une fonction, ou une boucle, ou ce que tu veux, non?

Oui, mais je me posais simplement la question: "n'y a t'il pas une autre méthode plus simple ? Les informaticiens sont feignant, il on certainement déjà prévu un système pour faire sa.

[Ter Rowan]

je suis un peu sur la même vision de kassak :

le nombre de tables doit dépendre de la richesse du jeu
il peut y avoir beaucoup de tables sans en avoir trop.


Sinon pour revenir au probème une autre solution "artisanale" (mais je n'ai pas fouillé si c'était possible en mysql) que de créer autant de requêtes sql qu il y a de table serait de créer un script de ce type :

Code :

Boucle sur les noms de table ( TableEnCours)
  boucle sur les noms des champs de TableEnCours (ChampEnCours)
     si ChampEnCours = "id_Joueur"
            Delete * From TableEnCours Where id_Joueur = "12345"

en Oracle l'objet (la table) qui te permet de trouver ces noms de talbe c'est ALL_TABLES doit y avoir une méthode similaire sur mysql

par contre cela impose que tous les champs id_joueur dans tes tables s'appellent toujours id_joueur et qu'il n'y ait pas de dépendances successibes (ex joueur donne perso, perso donne carac)

si tu as plus d'inter dépendances que cela à mon sens que deux choix

l'outil qui gère l'intégrité
le script fait maison

[Roworll]

Le nettoyage à la man et la nettoyage InnoDB ont tous deux des avantages et des inconvénients.

Un nettoyage manuel c'est la certitude de n'affecter que certaines tables. C'est plus lourd, demande plus de contrôles mais en général fait correctement ce qui lui est demandé. Il faut cependant bien connaître son modèle de données et penser à mettre à jour la procédure d'épuration en cas de changement due celui-ci. Pour préserver l'intégrité du modèle de données, il peut être préférable de travailler avec des transactions pour ne pas se retrouver avec des demi-suppressions.

L'utilisation d'InnoDB et des intégrités référentielles est plus pratique au premier abord mais à l'utilisation peut se révèler problématique en cas de mauvaise maitrise du système ou modélisation de la base. Une relation oubliée, c'est autant de lignes qui vont rester à "polluer" une table. Inversement, une relation de trop et on se retrouve à nettoyer des tables non désirées. Imaginons une relation Joueur->Perso->Inventaire -> Objet, la suppression d'un joueur risque de faire quelques trous dans la table objet s'il est le seul à avoir certains équipements.

Le type de nettoyage proposé par Ter Rowan peut aussi être dangereux. Il faut être certain que cette méthode n'impactera pas des tables qui devraient être placées en dehors du processus d'épuration (Exemple, une colonne id_joueur dans un petit forum maison et paf, tous les messages disparaissent).

Enfin, pour revenir sur cette histoire de nombre de table, je pense qu'il est tout simplement fonction du modèle conceptuel de la base de données. Ensuite, on peut chercher à regrouper des entités pour une question d'optimisation mais pratiquement, les bases de données ont plutôt tendance à utiliser beaucoup de tables (MOM 2007 par exemple utilise plusieurs tables, Event_00, Event_01, ..., Event_60 regroupées au final dans une vue Event). Il m'est aussi arrivé de voir des concepteurs avoir des informations redondantes dans leur base de données pour des questions de performance. Les DataWareHouses sont aussi un exemple de monstre comportant des tonnes de données répartis dans des tripotées de tables.

[Kassak]

Moi j'aurais tendance à préférer la manière manuelle, certes surement plus lourde, mais je serais sur de ne rien oublier, pas même un petit champ par ci par la, et si le nom du champ du joueur ( par exemple id_joueur ) est le même pour X tables, je pense qu'en une requête on peut nettoyer ces tables, et ainsi dessuite.