IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration MySQL Discussion :

Conservation de données et champ d'activation


Sujet :

Administration MySQL

  1. #1
    Futur Membre du Club
    Homme Profil pro
    etudiant
    Inscrit en
    Août 2012
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : etudiant

    Informations forums :
    Inscription : Août 2012
    Messages : 9
    Points : 8
    Points
    8
    Par défaut Conservation de données et champ d'activation
    Bonsoir, j'ai entendu dire que effacer des données n'était pas bon et qu'il vallait mieux mettre des champs boolean actif/non actif lorsque l'on veut effacer une entité de la base de données on met le champ à non-actif et donc l'entité sera logiquement effacé mais pas physiquement...

    Ce que je me demandais c'est pourquoi ? Je ne trouve pas de doc la dessus :S

  2. #2
    Membre régulier
    Homme Profil pro
    Développeur LAMP
    Inscrit en
    Janvier 2010
    Messages
    48
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur LAMP
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Janvier 2010
    Messages : 48
    Points : 72
    Points
    72
    Par défaut
    Salut,

    Supprimer les données crée une fragmentation de ton fichier de données. Mais rien ne t'empêche d'effectuer un optimize qui "défragmente" tes données et permet de mettre à jour les stats par la même occasion.

    Je pense en contre partie, peut être quelqu'un pourra confirmer, que effectivement en supprimant une entrée tu créera une ligne vide dans ton fichier de données, mais tes index seront mis à jour et donc allégé.

    Attention à l'optimize sur tes tables innoDB car ton auto_increment peut être impacté si parmi les entrées supprimées sont contenu des entrées en fin de fichier. http://www.mysqlplus.fr/2011/07/17/o...uto-increment/

  3. #3
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Bonjour,

    Il faut bien différencier les domaines "technique" et "fonctionnel".

    D'un point de vue "technique", il est toujours préférable de supprimer physiquement : réduction physique du fichier de données et des index, même si ça transforme le fichier en gruyère, il vaut mieux sauter des plages de données sur le disque que d'avoir à les lire.

    En revanche, d'un point de vue fonctionnel, il est parfois intéressant (quand c'est pas obligatoire) de conserver la trace que "qui a supprimé, quand, comment, pourquoi, l'age du capitaine".
    Dans ce cas, on aura plusieurs solutions pour le faire :
    - création d'une table "éléments_supprimées", dans laquelle on recopie certaines informations (ou toutes) de la ligne supprimée, qui sera supprimée pour de bon dans la table mère.
    - ajout d'un certain nombre de champs (flag de suppression, ou date de fin d'application, motif de suppression, etc.) dans la table.

    La première solution est plus lente pour retrouver et reconstituer les données, mais permet d'optimiser la table mère, puisqu'on y supprime physiquement les lignes.
    La seconde est plus facile à relire, mais fait augmenter ad vitam eternam la taille de la base.

    Dans tous les cas, la journalisation des données est à analyser au cas par cas, et ne doit en principale pas d'appliquer à toutes les données de toutes les tables.

    Il est important de conserver par exemple un client inactif (au cas où il revienne, au cas où il redemande une facture, etc.) idem pour les factures.
    En revanche, un inventaire de stock du mois de janvier 2007, on s'en moque certainement : pas besoin de le conserver.

    J'espère que c'est plus clair comme ça.
    On ne jouit bien que de ce qu’on partage.

Discussions similaires

  1. [MySQL] Comment mettre à jour en conservant les données actuelles d'un champs
    Par MisterMacPhisto dans le forum PHP & Base de données
    Réponses: 14
    Dernier message: 17/04/2007, 16h49
  2. Réponses: 12
    Dernier message: 28/04/2006, 12h38
  3. Conserver des données d'une page à une autre...
    Par Angeldu74 dans le forum Général JavaScript
    Réponses: 2
    Dernier message: 24/08/2005, 15h15
  4. Réponses: 8
    Dernier message: 19/05/2005, 17h03
  5. developpement base de donnée: Les champs d'aggrégat
    Par Jahrnee dans le forum Bases de données
    Réponses: 2
    Dernier message: 08/03/2004, 20h39

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo