Insertar registros en diferentes tablas con un solo INSERT

[josecarbono]

Buenos dias foro, pues eso.. podria insertar registros en multiples tablas al mismo tiempo?
La idea es la siguiente: Tengo una tabla q almacena algunos registros obligatorios y otra q almacena otros registros opcionales.

Los obligatorios siempre van a ser vistos pero los opcionales seran vistos solo si se contrata esa opcion.

El detalle es q quiero hacer un INSERT multiple, osea en dos tablas al mismo tiempo, insertar los registros obligatorios y los no obligatorios en caso de q existan..

Espero haberme hecho entender bien!! Gracias..

[mozka]

la unica manera que se me ocurre, es que en la primera tabla existieran los campos que ocupas en la segunda tabla y ponerle un trigger a la primera.

pero a como entiendo este no es el caso, asi que mi respuesta es que no se puede

[Mithrandir]

En SQL Server puedes usar las UDF. Insertas sobre la UDF y esta define sobre que tabla se inserta (y como se inserta).

Un trigger también pudiera hacer la funcion.

¿Pero por que no usas un SP?

[Myakire]

¿por qué en un solo Insert?, ¿para asegurarse que se inserten todos o ninguno? ¿por qué no usas transacciones?

[josecarbono]

uy amigo, disculpame pero.... no se q son transacciones.. Me podrias explicar q son? Gracias..

[Mithrandir]

Este es un extracto de lo que puedes econtrar en la ayuda de sql, en pocas palabras son una herramienta para asegurar que todas las instrucciones de ejecuten juntas:

A transaction is a sequence of operations performed as a single logical unit of work. A logical unit of work must exhibit four properties, called the ACID (Atomicity, Consistency, Isolation, and Durability) properties, to qualify as a transaction:

Atomicity

A transaction must be an atomic unit of work; either all of its data modifications are performed, or none of them is performed.

Consistency

When completed, a transaction must leave all data in a consistent state. In a relational database, all rules must be applied to the transaction's modifications to maintain all data integrity. All internal data structures, such as B-tree indexes or doubly-linked lists, must be correct at the end of the transaction.

Isolation

Modifications made by concurrent transactions must be isolated from the modifications made by any other concurrent transactions. A transaction either sees data in the state it was in before another concurrent transaction modified it, or it sees the data after the second transaction has completed, but it does not see an intermediate state. This is referred to as serializability because it results in the ability to reload the starting data and replay a series of transactions to end up with the data in the same state it was in after the original transactions were performed.

Durability

After a transaction has completed, its effects are permanently in place in the system. The modifications persist even in the event of a system failure.

La manera general de uso es algo como:

Código:

BEGIN TRANSACTION
INSERT INTO tabla VALUES ('algo')
IF @@error <> 0 ROLLBACK --deshaces todo
INSERT INTO otra_tabla ('mas')
IF @@error <> 0 ROLLBACK --deshaces todo, incluso el insert anterior
COMMIT TRANSACTION --si no fallo nada entonces dices que todo se grabe

[jrp01]

De esa manera mantienes la integridad referencial de los datos. o se hace todo o nada