tipos - llave primaria y foranea sql
¿Puede una clave externa referirse a una clave principal en la misma tabla? (4)
Simplemente creo que la respuesta es falsa porque la clave externa no tiene propiedad de uniqueness .
Pero algunas personas dijeron que puede ser en caso de que uno se una a la mesa. Soy nuevo en SQL . Si es verdad, por favor explique cómo y por qué?
Employee table
| e_id | e_name | e_sala | d_id |
|---- |------- |----- |--------|
| 1 | Tom | 50K | A |
| 2 | Billy | 15K | A |
| 3 | Bucky | 15K | B |
department table
| d_id | d_name |
|---- |------- |
| A | XXX |
| B | YYY |
Ahora d_id es una clave externa, entonces, ¿cómo puede ser la clave principal? Y explica algo sobre join . ¿Cuál es su uso?
Creo que la pregunta es un poco confusa.
Si quiere decir "¿puede la clave externa ''referirse'' a una clave primaria en la misma tabla?", La respuesta es un sí firme, ya que algunos respondieron. Por ejemplo, en una tabla de empleados, una fila para un empleado puede tener una columna para almacenar el número de empleado del gerente donde el gerente también es un empleado y, por lo tanto, tendrá una fila en la tabla como una fila de cualquier otro empleado.
Si quiere decir "¿puede la columna (o conjunto de columnas) ser una clave principal así como una clave externa en la misma tabla?", La respuesta, en mi opinión, es un no; parece sin sentido. Sin embargo, la siguiente definición tiene éxito en SQL Server.
create table t1(c1 int not null primary key foreign key references t1(c1))
Pero creo que no tiene sentido tener tal restricción a menos que alguien presente un ejemplo práctico.
AmanS, en su ejemplo d_id en ninguna circunstancia, puede ser una clave principal en la tabla Empleado. Una tabla puede tener solo una clave principal. Espero que esto aclare tu duda. d_id es / puede ser una clave primaria solo en la tabla de departamento.
Un buen ejemplo del uso de identificadores de otras filas en la misma tabla que las claves externas son las listas anidadas.
Eliminar una fila que tenga hijos (es decir, filas, que hacen referencia a la identificación de los padres), que también tienen hijos (es decir, haciendo referencia a los identificadores de los hijos) eliminará una cascada de filas.
Esto ahorrará mucho dolor (y mucho código de qué hacer con huérfanos, es decir, filas, que se refieren a identificadores no existentes).
¿Seguro Por qué no? Supongamos que tiene una tabla Person , con id , name , age y parent_id , donde parent_id es una clave externa a la misma tabla.No necesitarías normalizar la tabla Person para las tablas Parent y Child , eso sería overkill.
Person
| id | name | age | parent_id |
|----|-------|-----|-----------|
| 1 | Tom | 50 | null |
| 2 | Billy | 15 | 1 |
Algo como esto.
Supongo que para mantener la coherencia, debería haber al menos 1 valor nulo para parent_id . La única fila de "macho alfa".
EDITAR: Como muestran los comentarios, Sam encontró una buena razón para no hacer esto. Parece que en MySQL cuando intenta realizar ediciones a la clave principal, incluso si especifica CASCADE ON UPDATE , no propagará la edición correctamente. Aunque las claves primarias (por lo general) están fuera de los límites de edición en producción, es, no obstante, una limitación que no debe ignorarse. Por lo tanto, cambio mi respuesta a: probablemente debería evitar esta práctica a menos que tenga un control bastante estricto sobre el sistema de producción (y puede garantizar que nadie implementará un control que edite los PK). No lo he probado fuera de MySQL.