Disparadores

[Cota_Isla]

Buenas,
estoy un poco perdido en el tema de disparadores y no se si lo que quiero conseguir se hace a través de estos. Quiero que de una tabla solo se actualice determinados campos y otros siempre sean los mismos desde su inserción, ¿esto se conseguiría mediante disparadores o hay otra forma?

[gnzsoloyo]

Depende de qué campos estés hablando.
¿Se actualizan siempre los mismos, o cambian cuáles son los que se actualizan?
¿Cómo afectarían las inserciones, en lugar de las actualizaciones?
En principio, yo recomendaría hacerlo por SP, no por queries directas, y jamás hacerlo por TRIGGER.

[Cota_Isla]

Se actualizan siempre los mismos, ya que cuando se insertan los valores de los otros quiero que no se puedan modificar nunca..
Son para datos de recibos, es decir, por ejemplo el año y mes del recibo no quiero que nunca se modifiquen y los demás datos si..
No se si me explico.
No se que es SP, pero por tiggers parece q no es difícil y así consigo que cada fila tenga valores en los campos correctos, que según he leído para eso sirven!
Espero tu correcciones.

[gnzsoloyo]

No se que es SP, pero por tiggers parece q no es difícil y así consigo que cada fila tenga valores en los campos correctos, que según he leído para eso sirven!

No exactamente.
Los TRIGGERs se crearon para acciones automáticas sobre eventos de tabla, pero no necesariamente para hacer ese tipo de validaciones. Se crearon más bien para acciones que siempre deban realizarse sobre el mismo registro que entra, se actualiza, o se borra, pero no es su meta restringir acciones sobre esos registros. O al menos no es la idea.
Debes tener en cuenta que al definir una acción sobre un UPDATE, esa acción se disparará todas las veces que se realice un UPDATE sobre esa tabla, cosa que podría suceder en actualizaciones que no impliquen cambios sobre esas columnas, por lo qu esstarías validando eventos que no suceden.
Antes bien se podría encapsular las altas y las modificaciones en SP, de modo que las acciones no dependan de lo que se manda en la sentencia, sino que se evalúen internamente dentro de ese SP.
Es mucho más eficiente y seguro.
Y más habitual en sistemas complejos.

De todos modos siempre hay un concepto que debes tener en cuenta: Es incorrecto e inadecuado obligar a la base a ocuparse de validaciones que deberías hacer en la aplicación antes de mandar los datos a la base.
Donde mejor puedes restringir lo que quieres es precisamente en la aplicación. Claro que para eso tendrás que programar más intensamente...

[Cota_Isla]

Es que quiero q siempre se me realice ya que en el cuerpo del tigger cubrire las posibles posibilidades de una actualización del registro de esa tabla.
Con respecto a las validaciones, siempre las realizo en el software pero por ejemplo en el caso de q entre un intruso y modifique los datos de forma incoherente, es decir, un recibo pagado pero el campo dia de pago no lo tiene almacenado, no se si me vas entendiendo.
Que es SP???

[gnzsoloyo]

Con respecto a las validaciones, siempre las realizo en el software pero por ejemplo en el caso de q entre un intruso y modifique los datos de forma incoherente, es decir, un recibo pagado pero el campo dia de pago no lo tiene almacenado, no se si me vas entendiendo.

Yo te entiendo, pero si te hackeasen la base de datos, podrían perfectamente volar los triggers y hacer lo que quieran.
¿Lo has pensado?
Las vulnerabilidades no se solucionan usando triggers. Los triggers son el recurso extremo y se deben usar sólo si son estrictamente necesarios.
Si lo que se quiere hacer se pude lograr por otros medios, por ejemplo stored procedures (más invulnerables y requieren un solo tipo de permisos), es preferible hacerlo así.
Las bases de aplicaciones web más seguras que conozco no permiten acceso por queries Sólo por SP.
Por algo es...

TE repito: Es preferible en mi opinión y experiencia, hacer lo que pretendes por stored procedures.