Recuerda que en la informática cualquier problema casi siempre tiene diversas resoluciones, de igual modo nosotros mostramos lo mejor y más óptimo.
Solución:
Creo que la pregunta es un poco confusa.
Si quiere decir “¿pueden los extranjeros key ‘referirse’ a un primario key en la misma tabla?”, la respuesta es un firme sí, como 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 una columna (o un conjunto de columnas) ser un elemento principal key así como un extranjero key 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 un primario key en la tabla de empleados. Una tabla solo puede tener un primario key. Espero que esto aclare tu duda. d_id es/puede ser un primario key solo en mesa de departamento.
¿Seguro Por qué no? Digamos que tienes un Person mesa, con id, name, agey parent_iddónde parent_id es un extranjero key a la misma mesa. No necesitarías normalizar el Person mesa a Parent y Child mesas, eso sería excesivo.
Person
| id | name | age | parent_id |
|----|-------|-----|-----------|
| 1 | Tom | 50 | null |
| 2 | Billy | 15 | 1 |
Algo como esto.
Supongo que para mantener la coherencia, tendría que haber al menos 1 null valor por parent_id, aunque. 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 en el principal keyincluso si especifica CASCADE ON UPDATE no propagará la edición correctamente. Aunque primario keys están (generalmente) fuera de los límites de la edición en producción, sin embargo, es una limitación que no debe ignorarse. Por lo tanto, cambio mi respuesta a: – probablemente deberías evitar esta práctica a menos que tenga un control bastante estricto sobre el sistema de producción (y pueda garantizar que nadie implementará un control que edite los PK). No lo he probado fuera de MySQL.
Este puede ser un buen ejemplo de explicación.
CREATE TABLE employees (
id INTEGER NOT NULL PRIMARY KEY,
managerId INTEGER REFERENCES employees(id),
name VARCHAR(30) NOT NULL
);
INSERT INTO employees(id, managerId, name) VALUES(1, NULL, 'John');
INSERT INTO employees(id, managerId, name) VALUES(2, 1, 'Mike');
— Explicación: — En este ejemplo. — John es el manager de Mike. Mike no maneja a nadie. — Mike es el único empleado que no dirige a nadie.
Si te ha resultado provechoso nuestro post, te agradeceríamos que lo compartas con más juniors de esta forma contrubuyes a difundir este contenido.