Vous utilisez des déclencheurs ou des transactions MySQL?

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

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

Cependant, il faudra beaucoup de temps pour calculer le montant total du crédit de l'utilisateur à chaque fois qu'il fait une action. J'ai donc pensé que c'était peut-être une bonne idée de conserver le montant total du crédit pour chaque utilisateur dans une profiletable d' utilisateurs .

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

J'ai pensé en utilisant 2 méthodes:

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

Quel est le plus fiable? Et si j'ai une grande base de données (plus de 100 000 utilisateurs)?

Avez-vous des suggestions pour ce faire?

Le moteur BD MySQL est InnoDB.

Sans aucun doute, j'exclureais les déclencheurs et resterais strictement avec les transactions.

Les déclencheurs sont, par nature, des procédures stockées. Leurs actions sont pratiquement difficiles à annuler . Même si toutes les tables sous-jacentes sont InnoDB, vous rencontrerez un volume proportionnel de verrous de ligne partagés et une intermittence gênante de verrous de ligne exclusifs. Ce serait le cas si les déclencheurs manipulaient des tables avec des INSERT et des UPDATE stagnant pour effectuer un MVCC robuste à l'intérieur de chaque appel à un déclencheur .

Combinez cela avec le fait que les protocoles de validation de données appropriés ne sont pas implémentés dans le langage de procédure stockée de MySQL . La Business Intelligence peut contenir une base de données à condition que le langage de procédure stockée puisse 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 cet avantage sur MySQL.

Concernant les transactions, MySQL a InnoDB comme son principal moteur de stockage compatible ACID (moteur de stockage Deafult dans MySQL 5.5). Il a une excellente récupération après incident et obéit aux protocoles de conformité ACID.

Je choisirais les transacitons plutôt que les déclencheurs à chaque fois.

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

Évoluer jusqu'à 100 000 utilisateurs dépend bien sûr de votre application et du trafic de base de données qu'elle génère. Avec MySQL sous une charge d'écriture transactionnelle élevée, vous pourriez être bientôt confronté aux charges de partage et / ou de réplication de votre ensemble de données afin de maintenir une réponse d'application acceptable.

Cependant, il existe des alternatives au partage de MySQL. L'un d'eux est Clustrix (mon employeur), qui est un système de base de données SQL mono-instance hautes performances évolutif en parallèle. C'est un système de base de données en cluster qui se présente comme un seul serveur MySQL. La mise à l'échelle transparente de la base de données décrite dans ce fil de discussion vers 100 000 utilisateurs sur une seule instance de Clustrix ne nécessiterait aucun partage ni aucune logique d'application supplémentaire.

Bonne réponse de Rolando.

De plus - les déclencheurs ne doivent pas être utilisés pour la logique, car quelques déclencheurs interreliés plus tard, les choses deviendront rapidement confuses. Un bel ensemble d'instructions dans une procédure stockée ou une procédure côté client peut traverser la logique métier plus clairement qu'un tas de logique cachée dans la base de données. Il existe également des limitations sur les déclencheurs en ce qui concerne la table à partir de laquelle ils sont déclenchés - vous pouvez donc vous retrouver à diviser votre logique en deux endroits différents.

De plus, vous pouvez trouver des moyens d'optimiser à quel moment ces calculs se produisent dans votre serveur de logique métier, alors qu'un déclencheur va se déclencher à chaque fois. Vous vous retrouverez à désactiver le déclencheur, à mettre à jour la table, puis à réactiver le déclencheur - ce qui signifie également que vous devez mettre la logique du déclencheur dans ce code.

De plus - vous n'avez pas besoin de disposer de toute la logique dans la partie logique métier du code - vous souhaiterez peut-être appliquer l'intégrité de la table à l'aide de procédures stockées. Cela peut démarrer une transaction, effectuer vos multiples mises à jour et faire en sorte que les choses se déroulent correctement en cas d'échec. De cette façon, quelqu'un qui regarde la base de données peut voir la logique pour insérer une commande, par exemple. Ceci est moins important dans le monde d'aujourd'hui car les services Web peuvent être l'interface d'accès unique à la base de données; mais dans le cas où plusieurs exécutables ont accès à la base de données, cela peut être énorme.

De plus - vous allez quand même avoir des transactions - vous n'allez pas exécuter vos déclencheurs sans un ... non? Il est donc bon de savoir comment démarrer une transaction; faire des trucs; puis terminer une transaction. Si vous voyez ce modèle dans votre code, un morceau de code supplémentaire qui l'utilisera sera léger sur la charge cognitive. Un déclencheur, si vous vous souvenez qu'il existe, vous obligera à penser différemment pour les transactions qui sont affectées par le déclencheur, en particulier si d'autres tables sont extraites qui peuvent également avoir des déclencheurs.

Fondamentalement, entre un travail périodique planifié (ou un 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.