5

SQL Server 2005.¿Cómo consulto las claves externas que no coinciden con sus restricciones?

Estoy agregando restricciones de clave externa a la base de datos de una aplicación que supuestamente no las necesitaba. Naturalmente, los datos se han vuelto poco confiables y hay entradas huérfanas en el campo de clave externa.

Configuración:
Dos tablas, TableUser y TableOrder. TableUser tiene clave principal 'UserID', y TableOrder tiene clave externa 'UserID'.

¿Cómo puedo encontrar las filas donde TableOrder.UserID no tiene una entrada coincidente en TableUser.UserID?

Por ejemplo, TableOrder.UserID tiene un valor de 250, pero no hay ninguna clave TableUser.UserID juego para 250.

+0

Una vez que los haya encontrado, ¿qué quiere hacer con ellos? Por ej., Eliminarlos? – erickson

+0

ERRR, si hay una clave externa, ¿cómo puede no coincidir? ¿De verdad tiene códigos FK codificados en su SQL? –

+0

Se refiere a una tabla con campos que son tratados por la aplicación como clave externa, pero nunca fueron aplicados por la base de datos en sí. – BradC

Respuesta

8

He aquí una manera:

select * from TableOrder where UserID not in (select UserID from TableUser); 

Hay muchas formas diferentes de escribir este tipo de consulta.

4

El otro enfoque común es unirse a un izquierda exterior:

SELECT * FROM TableOrder o 
LEFT OUTER JOIN TableUser u ON o.UserID = u.UserID 
WHERE u.UserID is NULL 

Esta consulta también puede ser útil sin la cláusula where, para navegar a través y ver los valores correspondientes (si existen), y ver que los que no tienen coincidencia

0

No había restricciones de FK en las tablas para comenzar. Se usaron como FK y PK pero no codificados; se creía que eran gastos indirectos innecesarios. Entonces tenemos todas las columnas, pero no hay restricciones codificadas. Cuando fui a ponerlos para que se hicieran cumplir, descubrí que había muchas violaciones.

Su pregunta resalta el problema. No son gastos indirectos innecesarios, evitan que la gente de la base de datos general se asuste.

Ambas respuestas de Greg y Brad me ayudaron.

+0

Creo que es una idea falsa común. Mucha gente piensa que se debe hacer en el nivel medio para la lógica de negocios. Pero el FK es una parte fundamental de cualquier base de datos relacional. Si la base de datos no puede hacerlo bien, entonces hay otros problemas ... –

Cuestiones relacionadas