En utilisant des déclencheurs ou des transactions MySQL?

Question

Je veux vous demander votre avis à l'aide de déclencheurs MySQL ou de transactions dans un site Web.

En fait, j'ai une table de payment d'histoire avec - UserId | OperationId | Comment | Credits | Sign (debit or credit). Ainsi, chaque opération de paiement est inséré dans ce tableau.

Cependant, il sera temps calculer chaque fois que le montant total de crédit de l'utilisateur à chaque fois qu'il fait une action. Donc, je pensais est peut-être une bonne idée de garder le montant total de crédit pour chaque utilisateur dans une table de profile utilisateur.

Voici le problème. Comment puis-je être sûr que le montant total de crédit forment la table profile restera synchronisée avec les opérations de table d'historique de payment?

Je pensais que l'aide de 2 méthodes:

• déclencheurs de MySQL ou
• transactions codées dans le code source

Ce qui est plus fiable? Et si j'ai grande base de données (plus de 100.000 utilisateurs)?

Avez-vous des suggestions à faire?

Le moteur BD MySQL est InnoDB.

Answer 1

Sans aucun doute, j'exclurait les déclencheurs et strictement rester avec les transactions.

Les déclencheurs sont, par nature, des procédures stockées. Leurs actions sont pratiquement difficiles à faire reculer le . Même si toutes les tables sous-jacentes sont InnoDB, vous ferez l'expérience d'un volume proportionnel des verrous de lignes partagées et intermittences ennuyeux de verrous ligne exclusifs. Tel serait le cas si les déclencheurs manipulaient des tables avec et INSERTs étant stagnaient à UPDATEs effectuer lourds MVCC à l'intérieur de chaque appel à un déclencheur .

Combinez cela avec le fait que ne sont pas mises en œuvre dans une procédure stockée de MySQL langue. Business Intelligence est OK pour avoir contenu dans une base de données à condition que la procédure stockée langue peut gérer un environnement transactionnel . En tant que DBA MySQL, je dois dire honnêtement que ce n'est pas le cas avec MySQL. Oracle (PL / SQL), PostgreSQL (PL / pgSQL) et SQL Server (T-SQL) ont ce bord au-dessus MySQL.

En ce qui concerne les transactions, MySQL InnoDB a comme principal moteur de stockage conforme ACID (moteur de stockage deafult dans MySQL 5.5). Il a une excellente récupération de l'accident et les protocoles de obéisse conformité ACID.

je choisirais transacitons sur les déclencheurs à chaque fois.

Answer 2

Je suis d'accord avec l'évaluation de Rolando. Votre logique métier doit résider dans votre application et devrait apporter des modifications à la base de données transactionnellement.

Scaling à 100.000 utilisateurs, bien sûr, dépend de votre application et le trafic de la base de données qu'il génère. Avec MySQL sous une charge d'écriture transactionnelle lourde, vous pourriez être bientôt confronté à la charge de sharding et / ou la réplication de votre ensemble de données afin de maintenir une réponse d'application acceptable.

Cependant, il existe des alternatives à sharding MySQL. L'un d'eux est Clustrix (mon employeur) qui est une instance unique de haute performance parallèle évolutive système de base de données SQL. Il est un système de base de données en cluster qui se présente comme un seul serveur MySQL. Mise à l'échelle de la base de données décrit dans ce fil de façon transparente à 100.000 utilisateurs sur une seule instance de Clustrix ne nécessiterait pas sharding et aucune logique d'application supplémentaire.

Answer 3

Bonne réponse de Rolando.

En outre - Triggers ne doit pas être utilisé pour la logique, car deux déclencheurs se articulent entre plus tard, les choses vont se confondre rapidement. Un ensemble d'instructions agréable dans une procédure côté procédure ou d'un client enregistré peut obtenir à travers la logique métier plus clairement qu'un tas de logique cachée dans la base de données. Il y a aussi des restrictions sur les déclencheurs par rapport à la table, ils se déclenchent à partir - de sorte que vous pouvez vous retrouver diviser votre logique en deux endroits différents ..

De plus - vous pourriez trouver des façons d'optimiser à quel point ces calculs se produisent dans votre serveur logique métier, alors qu'un déclencheur est va déclencher à chaque fois. Vous vous surprendrez à éteindre le déclencheur, la mise à jour de la table, puis de réactiver la gâchette -. Ce qui signifie également que vous devez mettre la logique de déclenchement dans ce code

De plus - vous ne devez pas avoir toute la logique dans la partie logique métier du code - vous pouvez appliquer l'intégrité de la table en utilisant des procédures stockées. Cela peut commencer une transaction, faire vos mises à jour multiples et ont des choses roulent bien en arrière si quelque chose tombe en panne. Que quelqu'un regardant la façon dont la base de données peut voir la logique pour insérer une commande, par exemple. Cela est moins important dans le monde d'aujourd'hui puisque les services Web peuvent être l'interface d'accès unique à la DB; mais dans le cas où plusieurs executables ont accès à la base de données, cela peut être énorme.

De plus - tu vas avoir des transactions de toute façon - tu ne vas pas exécuter vos déclencheurs sans un ... droit? Il est donc bon de savoir comment démarrer une transaction; faire des choses; et puis terminer une transaction. Si vous voyez ce modèle dans votre code, un autre morceau de code qui utilise ce sera la lumière sur la charge cognitive. Un déclencheur, si vous vous rappelez qu'il est là, vous forcer à penser différemment pour les transactions qui sont touchées par le déclencheur, surtout si d'autres tables sont tirées en qui peuvent aussi avoir des déclencheurs.

En fait, entre un cron job régulier (ou travail d'agent de base de données) et de bonnes procédures stockées, vous pouvez accomplir 99% de ce que vous voulez. Le 1%; repenser le projet.