tables MySQL et stratégies suppression

Question

Je travaille sur un réseau social, comme un sous-ensemble de Facebook. Je pense que cela signifie que l'application sera plus lourd que lecture en écriture lourde (à savoir plus CHOISIT que INSERTS, MISES À JOUR, ou de supprimer)

Je prévois d'utiliser MySQL pour la base de données, en utilisant MyISAM. Chaque table de la base de données contiendra les trois champs suivants:

• CREATED - un champ de date contenant le temps l'enregistrement a été créé
• UPDATED - un champ de date contenant le temps l'enregistrement a été modifié
• ROWSTATUS -. Un champ CHAR (1) contenant un seul drapeau de caractères pour afficher si l'enregistrement est actif, inactif ou supprimé (en utilisant 'A' valeurs, I et D, respectivement)

Grâce à une classe wrapper PHP, nous nous assurons que toutes les requêtes SELECT sont les RowStatus et mettre à jour les requêtes mettent à jour la colonne mise à jour et les requêtes INSERT mettre à jour la colonne CRÉÉ.

Je prévois de ne pas supprimer en fait des enregistrements, optant plutôt pour la mise à jour qui enregistre le terrain RowStatus à D pour montrer qu'il est supprimé (par exemple une suppression douce).

Nous avons une procédure SQL qui supprime physiquement les données supprimées au bout de 10 jours.

Cependant, je traversais cet article , qui fait valoir qu'il n'y a pas besoin de supprimer physiquement en raison des frais généraux de verrouillage. Au contraire, l'auteur a suggéré d'utiliser ce schéma:

SELECT e.eventid,e.title
    FROM events e
   WHERE NOT EXISTS
    (SELECT * FROM event_deletes ed WHERE ed.eventid = e.eventid);

Je me demande comment mon système compare avec ce mécanisme proposé, et qui est le meilleur? Je ne pouvais pas arriver à une réponse définitive sur mon propre.

Answer 1

Comme @ dit Pentium10, il n'y a rien d'intrinsèquement mauvais avec votre plan. Il est en fait une approche assez standard.

Le problème est juste que si vous utilisez MyISAM vos UPDATEs causeront toute la table de verrouillage pendant l'exécution de la requête. Cela introduit un goulot d'étranglement parce que vous ne pouvez mettre à jour ou supprimer un seul enregistrement à la fois.

Sauf si vous avez une raison d'utiliser MyISAM, je vous recommande de commutation InnoDB comme moteur de base de données. InnoDB utilise un verrouillage de ligne, de sorte que vos requêtes UPDATE ne bloque pas d'autres mises à jour. Il a aussi une autre belle caractéristiques telles que le soutien pour les transactions et les contraintes d'intégrité référentielle.

Answer 2

Le seul problème que je vois ici, par rapport à cet article, que vous ne verrouille pour manipulez l'appel SUPPR.

Vous devriez savoir que déclarations UPDATE et DELETE a toujours besoin d'émettre un verrou exclusif sur une table MyISAM.

Voilà pourquoi l'article recommande d'utiliser un INSERT au lieu d'un RowStatus UPDATE. Vous devriez aller l'article. Créer une table dédiée pour stocker les ids supprimés, et utiliser le recommandé se joindre aux sélectionne pour récupérer non enregistrements supprimés. De cette façon, sur l'action de suppression de l'utilisateur final, il vous suffira d'insérer dans la table, et vous ne causera pas de verrouillage UPDATE sur la table. Si vous ajoutez les clés appropriées aux deux tables, la jointure sera fait uniquement sur les indices, SI il sera rapide sur SELECT.

Vous pouvez également introduire les frais généraux si vous stockez le temps de la mise à jour. Vous devriez abandonner cette idée, tout comme ne sert à rien, et vous ne pourrez pas utiliser de dire quand un dossier a été mis à jour.