¿Puedo tener una clave externa que haga referencia a una columna en una vista en SQL Server?

En SQL Server 2008 y dado

TableA(A_ID, A_Data)
TableB(B_ID, B_Data)
ViewC(A_or_B_ID, A_or_B_Data)

¿Es posible definir de TableZ(A_or_B_ID, Z_Data)tal manera que la Z.A_or_B_IDcolumna esté restringida a los valores encontrados en ViewC? ¿Se puede hacer esto con una clave externa contra la vista?

No puede hacer referencia a una vista en una clave externa.

En las ediciones anteriores de SQL Server, las claves externas solo eran posibles a través de activadores. Puede imitar una clave externa personalizada creando un activador de inserción que verifica si el valor insertado también aparece en una de las tablas relevantes.

Si realmente lo necesita A_or_B_IDen TableZ, tiene dos opciones similares:

1) Agregue columnas A_IDy anulables B_IDa la tabla z, A_or_B_IDcree una columna calculada usando ISNULL en estas dos columnas y agregue una restricción CHECK de modo que solo una de A_IDo B_IDno sea nula

2) Agregue una columna TableName a la tabla z, restringida para contener A o B. ahora cree A_IDy B_IDcomo columnas calculadas, que solo son no nulas cuando se nombra su tabla apropiada (usando la expresión CASE). Hazlos persistir también

En ambos casos, ahora tiene columnas A_IDy B_IDque pueden tener claves foráneas apropiadas para las tablas base. La diferencia está en qué columnas se calculan. Además, no necesita TableName en la opción 2 anterior si los dominios de las 2 columnas de ID no se superponen, siempre que su expresión de caso pueda determinar en qué dominio A_or_B_ID cae

(Gracias por comentar por arreglar mi formato)

Lo sentimos, no puede FK a una vista en SQL Server.

Hay otra opción. Trate TableA y TableB como subclases de una nueva tabla llamada TablePrime. Ajuste los valores de ID de TableB para que no coincidan con los valores de ID de TableA. Haga que el ID en TablePrime sea el PK e inserte todos los ID de TableA y TableB (ajustados) en TablePrime. Haga que TableA y TableB tengan relaciones FK en su PK con el mismo ID en TablePrime.

Ahora tiene el patrón de supertipo / subtipo y puede hacer restricciones a TablePrime (cuando desee A o B ) o una de las tablas individuales (cuando solo desee A o solo B ).

Si necesita más detalles por favor pregunte. Hay variaciones que le permitirán asegurarse de que A y B sean mutuamente excluyentes, o tal vez la cosa con la que está trabajando pueda ser ambas al mismo tiempo. Es mejor formalizar eso en los FK si es posible.

Es más fácil agregar una restricción que haga referencia a una función definida por el usuario que realiza la verificación por usted, fCheckIfValueExists (columnValue) que devuelve verdadero si el valor existe y falso si no.

La ventaja es que puede recibir múltiples columnas, realizar cálculos con ellas, aceptar valores nulos y aceptar valores que no corresponden con precisión a una clave primaria o comparar con los resultados de las combinaciones.

La desventaja es que el optimizador no puede usar todos sus trucos de clave externa.

Lo sentimos, en el sentido estricto de la palabra, no, no puede establecer claves externas en las vistas. He aquí por qué:

InnoDB es el único motor de almacenamiento integrado para MySQL que presenta claves externas. Cualquier tabla InnoDB se registrará en information_schema.tables con engine = 'InnoDB'.

Las vistas, aunque están registradas en information_schema.tables, tienen un motor de almacenamiento NULL. No hay mecanismos en MySQL para tener claves externas en cualquier tabla que tenga un motor de almacenamiento indefinido.

¡Gracias!