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.
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.
Quand on te dit qu'un projet est terminé à 90%, prépare toi pour les 90% suivant
Ninety-Ninety Rule
"Une guerre de religions, c'est quand deux peuples s'entretuent pour savoir qui a le meilleur ami imaginaire"
Vu sur IRC
Ninety-Ninety Rule
"Une guerre de religions, c'est quand deux peuples s'entretuent pour savoir qui a le meilleur ami imaginaire"
Vu sur IRC