Sí, lo sé, es más eficiente que todos los datos de una aplicación estén en la misma base de datos. Pero a veces uno no puede controlar esas cosas, y le toca hacerlo lo mejor que pueda con lo que tiene.
En este caso no solo tenemos una app que tira de dos bases de datos (SQL Server), sino que, encima, una tabla de una de las BBDD tiene una clave foránea que apunta a una tabla de la otra BBDD.
Dejemos claro desde el principio que esto no es ni deseable, ni eficiente, ni bueno para la humanidad. Y dicho esto pasemos a explicar cómo montar el script para hacerlo.
USE [MiBaseDeDatosEnMiServerLocal]GOEXEC sp_addlinkedserver@server =N'ServidorRemoto',@srvproduct=N'SQL Server';GOexec sp_addlinkedsrvlogin 'ServidorRemoto', 'FALSE', NULL, 'user', 'password';
Creo que son bastante autoexplicativas, pero de todos modos si queréis una explicación más detallada – contando qué es cada parámetro y qué parámetros se pueden poner – de las instrucciones, aquí tenéis la de sp_addlinkedserver, y aquí la de sp_addlinkedsrvlogin. Mantengo esto lo más breve posible porque si no no serían minitips.
¿Y para hacer una clave foránea que apunte a otra BBDD, en el mismo o en otro servidor? Pues se replica el comportamiento usando triggers. He leído sobre esta solución y no es deseable. Los triggers no funcionan siempre y hay que asegurarse que soporten múltiples inserciones y actualizaciones. Lo del borrado en cascada ni me he atrevido a mirarlo. Pero para tablas que no se vayan a usar – o muy poco -, puede resultar útil.
Use[miBBDD]Create Trigger usuario.Nombre_Trigger ON usuario.Tabla After Insert, UpdateAsBeginIf NOT Exists(select IdForaneofrom ServidorRemoto.BBDDRemota.userRemoto.TablaRemota where idForaneo in (Select idLocal from inserted))BEGIN--Tratamiento del error: Borrar el registro, lanzar una excepción, o lo que sea.ENDENDGOY tan fácil.Como siempre, espero que esta entrada pueda ser de utilidad para alguien. Y si no, pues también como siempre, aquí tenéis un gato para compensar:
