est-il possible de faire une ligne dans MySQL inactive? Donc, cette ligne n'est plus utilisée dans les résultats des requêtes? Mon client souhaite que les membres supprimés existent dans la base de données, mais je ne veux pas modifier toutes les questions pour vérifier si le membre est supprimé ou non.
ou y a-t-il un moyen facile de déplacer toutes les données de la ligne en une autre table "inactive"?
4 Réponses :
Ce que vous décrivez est généralement appelé un Soft Supprimer .
Les rangées en mouvement entre différentes tables sont rarement une bonne idée dans des bases de données relationnelles. En général, vous ne devriez pas déplacer des enregistrements sur simplement parce que certains attributs à leur sujet ont changé (et "inactivité" est juste un attribut dans ce cas).
J'ajouterais un champ inactif dans la table, réglez-le sur 0 si la ligne est active et à 1 si inactif. Cependant, vous devriez filtrer des lignes inactives de toutes vos questions en ajoutant où inactive = 0 dans votre où clauses. Une alternative à ce sujet serait d'utiliser une vue, comme @brian suggéré dans l'autre réponse , que je recommande.
"Mais je ne veux pas éditer toutes les [sic] de la requête pour vérifier si le membre est supprimé ou non"
Comment ça m'a manqué? :) ... (Mise à jour de ma réponse)
Comment avez-vous mis à jour votre réponse afin qu'il ne doit plus éditer toutes les questions? Dans la révision 3, vous avez toujours mentionné «vous devez filtrer les lignes inactives de toutes vos questions ...».
Une option de ne pas modifier les requêtes serait de travailler avec une vue qui a la clause où dans sa définition.
@Konerak: Oui, je suis d'accord avec la méthode de vue. En fait, je suivi la réponse de Brian ... Quant à la mise à jour de la réponse, ma première version a simplement suggéré d'ajouter un champ inactif . Je n'ai totalement pas remarqué que l'OP était au courant de cela. (Cela s'est passé avant la période de grâce de 5 minutes, il n'apparaît donc pas dans l'historique de la révision de la réponse).
L'utilisation d'une vue nécessiterait toujours la modification de toutes les requêtes, n'est-ce pas? Mais oui, une vue serait la voie à suivre, je dirais :)
@Svish: Je pense utiliser une vue de la manière dont @brian suggéré éviterait que l'OP devait changer toutes les questions. C'est-à-dire en train de renommer la table, créant ainsi une vue avec le nom de la table et fournissant une valeur par défaut au champ "Inactif".
@Daniel: Aah, intelligent. N'a pas pensé à ça :)
Vous pouvez aussi vous suggérer de les copier dans une nouvelle table avec la même structure sur Supprimer
Particulièrement facile si vous utilisez un déclencheur "sur Supprimer"
Vous pouvez renommer la table actuelle, créer la colonne "supprimée", puis créer une vue avec le même nom que la table actuelle, sélectionnant tout le cas échéant = 0. De cette façon, vous n'avez pas à changer toutes vos questions. La vue sera mise à jour à condition que vous fournissez une valeur par défaut pour la colonne DELETE.
_
+1 pour la vue. Pourriez-vous mettre un lien vers la syntaxe de la vue Créer une vue ou un échantillon de la manière de le faire pour que l'OP sait où aller d'ici?
Mais lorsque je souhaite mettre à jour certaines données dans la table des membres, je ne peux pas utiliser le tableau Afficher pour mettre à jour ces données, non? Je dois donc modifier toutes les requêtes de mise à jour pour mettre à jour le my_New_Table (pour cet exemple)?
Les vues définies comme ceci devraient être mises à jour ... Essayez! C'est-à-dire insérer dans my_Table (col1, col2, col3) (1,2,3); et mettre à jour My_Table Set Col1 = 1 où Col2 = 5; Devrait-on travailler lorsque my_table est défini comme une vue comme ça.
un sur Suppr Trigger est ce que vous besoin.
EXEMPLE D'UTILISATION: P>
CREATE TRIGGER Users_archiver AFTER delete ON users FOR EACH ROW BEGIN insert into users_archive values(old.id,old.username,old.first_name, old.last_name,old.password); END$$ delimiter ;