La utilización de activadores o transacciones de MySQL?

Question

Quiero pedirle su opinión en el uso de los disparadores o transacciones de MySQL en un sitio web.

En realidad tengo una mesa payment historia con - UserId | OperationId | Comment | Credits | Sign (debit or credit). Por lo que cada operación de pago se inserta en esta tabla.

Sin embargo, será el momento de consumir el cálculo cada vez que el monto del crédito total del usuario cada vez que hacer la acción. Así que pensé que tal vez es una buena idea para mantener la cantidad de crédito total para cada usuario en una tabla profile usuario.

Aquí está el problema. ¿Cómo puedo estar seguro de que la cantidad total de crédito forman la tabla profile permanecerá sincronizado con las operaciones de tabla de historial payment?

pensé utilizando 2 métodos:

• desencadenantes de MySQL o
• transacciones codificados en el código fuente

¿Qué es más fiable? ¿Y si tengo gran base de datos (más de 100.000 usuarios)?

¿Tiene alguna sugerencia para hacer esto?

El motor de BD MySQL es InnoDB.

Answer 1

Sin lugar a dudas, yo descartaría desencadenantes y mantenerse estrictamente con las transacciones.

desencadenantes son, por naturaleza, los procedimientos almacenados. Sus acciones son prácticamente difícil de volver rollo . Incluso si todas las tablas subyacentes son InnoDB, experimentará un volumen proporcional de bloqueos de registro compartidos y la intermitencia de la molestos exclusivos bloqueos de registro. Tal sería el caso si los disparadores estaban manipulando las tablas con inserciones y actualizaciones se estancó para realizar MVCC de alta resistencia dentro de cada llamada a un disparador .

Combine esto con el hecho de que no se implementan en el procedimiento almacenado de MySQL idioma . Business Intelligence está bien haber contenida en una base de datos siempre que el procedimiento almacenado El lenguaje puede manejar un entorno transaccional . Como MySQL DBA, tengo que decir sinceramente que este no es el caso con MySQL. Oracle (PL / SQL), PostgreSQL (PL / pgSQL), y SQL Server (T-SQL) tiene esta ventaja sobre MySQL.

En cuanto a las transacciones, MySQL tiene InnoDB como su (motor de almacenamiento deafult en MySQL 5.5) del motor de almacenamiento de ácido compatible principal. Tiene una excelente recuperación de bloqueo y obedece a los protocolos de cumplimiento ACID.

Yo elegiría transacitons más de disparadores cada vez.

Answer 2

Estoy de acuerdo con la evaluación de Rolando. Su lógica de negocio debe residir en su aplicación y debe realizar cambios en la base de datos transaccional.

Escalado a 100.000 usuarios, por supuesto, depende de la aplicación y la base de datos de tráfico que genera. Con MySQL bajo una carga pesada de escritura transaccional, es posible que pronto se enfrentan a las cargas de sharding y / o replicar el conjunto de datos con el fin de mantener una respuesta aceptable de la aplicación.

Sin embargo, existen alternativas a sharding MySQL. Uno de ellos es Clustrix (mi jefe), que es un sistema de base de datos SQL de instancia única de alto rendimiento en paralelo escalable. Es un sistema de base de datos en clúster que se presenta como un único servidor MySQL. Escala de la base de datos descrita en este hilo sin problemas a 100.000 usuarios en una única instancia de Clustrix requeriría no sharding y no lógica de la aplicación adicional.

Answer 3

Buena respuesta de Rolando.

Además - Los disparos no se debe utilizar para la lógica, porque un par de disparadores interrelacionar más tarde, las cosas van a ser confuso rápido. Un buen conjunto de instrucciones de un procedimiento lado procedimiento o cliente almacenada puede conseguir a través de la lógica de negocio con más claridad que un montón de lógica oculta en la base de datos. También hay limitaciones en el gatillo con respecto a la mesa se disparará de - por lo que puede encontrarse dividir la lógica en dos lugares diferentes ..

Además - es posible encontrar maneras de optimizar en qué momento estos cálculos se producen en el servidor de la lógica de negocio, mientras que un disparador va a desencadenar cada vez. Usted se encontrará apagar el gatillo, la actualización de la tabla, y luego volver a habilitar el gatillo -. Lo que también significa que hay que poner la lógica de disparo en que código

Además de - usted no tiene que tener toda la lógica en la parte lógica de negocio del código - es posible que desee hacer cumplir la integridad tabla mediante procedimientos almacenados. Esto puede iniciar una transacción, hacer sus múltiples cambios, y tienen cosas se voltean muy bien si algo falla. De esa manera alguien que busca en la base de datos puede ver la lógica para la inserción de una orden, por ejemplo. Esto es menos importante en el mundo de hoy ya que los servicios web pueden ser la interfaz de acceso único a la base de datos; pero en el caso de que varios ejecutables tienen acceso a la base de datos esto puede ser enorme.

Además - que van a tener las transacciones de todos modos - no vas a ejecutar sus desencadenantes sin uno ... ¿verdad? Por lo que es bueno saber cómo iniciar una transacción; hacer algunas cosas; y luego finalizar una transacción. Si ve este patrón en su código, una pieza más de código que utiliza será luz sobre la carga cognitiva. Un disparador, si se recuerda que es allí, le obligará a pensar de forma diferente para aquellas operaciones que se ven afectados por el gatillo, especialmente si otras tablas están tirados en la que también puede tener factores desencadenantes.

Básicamente, entre unos procedimientos de trabajo cron regular (o trabajo de agente de base de datos) y buena almacenados, se puede lograr el 99% de lo que quiere. El 1%; replantear el proyecto.