Si por disparador entendemos un "trigger", no. No sería con un disparador.
Sería con un procedimiento que tendría que ejecutarse una vez al mes... Asumiendo que los cargos se hacen "todos a la una" una vez al mes.
Con SQL Server recuerdo que se podían poner tareas a ejecutar cada mes.
Se pueden poner tareas sobre un sistema operativo... al menos en Linux estoy seguro -porque alguna vez las he creado yo- y en Windows Server me extrañaría que eso no exista.
Si no puedes hacerlo con un procedimiento en la base de datos, puedes poner una aplicación a ejecutar una vez al mes con un montoncito de comandos SQL. E igual, se puede poner en una tarea en el servidor, ya sea sobre la base de datos -si es que MySQL permite hacerlo- o sobre el sistema operativo. Y en el peor de los casos, mediante un click de algún usuario que nunca olvide que tiene que generar los cargos de los alumnos en la base de datos cada mes.
Por "tabla de recibos", no tengo claro a que te refieres. Yo te mencionaba una tabla para llevar una cuenta corriente. Esto es, por cada alumno una lista de cargos y abonos.
Los cargos son "las mensualidades que debe pagar" y los abonos son "los pagos recibidos".
Es la misma idea que utiliza una cuenta de ahorros en un banco.
Esta tabla, podría tener estos campos: TABLA_CARGOABONO (Id_Item, DNI, Fecha, Id_TipoOperacion, Monto)
Ese "Id_TipoOperacion" debería estar en otra tabla con estos campos: TABLA_TIPOOPERACION (Id_TipoOperacion, Descripcion, Operacion)
Donde "Operacion" podría contener un "+" o un "-".
Según el tipo de operación, al momento de calcular si el alumno debe o le deben, la sumatoria iría en función del campo "Operacion" del tipo de operación.
La tabla de tipos de operacion debe tener al menos dos registros:
1, Cargo, -
2, Abono, +
Ejemplo* de cálculo de saldos por alumno:
Código SQL:
Ver originalSELECT a.DNI, SUM( CASE b.Operacion WHEN '+' THEN 1 ELSE -1 END * a.Monto) AS Saldo
FROM TABLA_CARGOABONO a INNER JOIN TABLA_TIPOOPERACION b ON b.Id_TipoOperacion = a.Id_TipoOperacion
GROUP BY a.DNI;
En este ejemplo, si ese saldo es negativo para un alumno, ese alumno debe dinero a.. je, "al colegio"?
Esta vez te he puesto un ejemplo sin probarlo porque me estoy muriendo de sueño... pero estoy casi seguro de que funciona. Si falla será por error "ortográfico - MySQL".
-------------------------------------------------
Por cierto, algo que si deberías hacer es cambiar ese DNI que vas arrastrando por todos lados... Es un dato alfanumérico que ocupa más espacio y que provoca búsquedas más lentas. Lo suyo, sería tener una tabla con llave primara númerica en donde el DNI sea un campo más de la tabla. Con un índice único si queres evitar los duplicados, pero la llave primaria debería ser númerica puesto que esa es la que iras arrastrando a todas las tablas que hagan referencia a los alumnos.
Aunque claro, si no tenes muchos miles de registros y/o muchos usuarios consultando la base de datos al mismo tiempo, no me hagas mucho caso... Algún poco caso, pero no mucho caso... je je. Lo siento, cuando estoy casi dormido realmente me pongo gracioso y me río de mí. Conmigo, pero de mí.