Llaves primarias y foraneas

[halexander]

Hola a todos¡¡ tengo una duda existencial xD jiji

Me gustaria saber si puedo tener llaves primarias y foraneas de tipo char.

Segun aqui veo ps sip, pero como es su funcionamiento?? Siempre crei que solo podia ser int las llaves, ya que son autonumericas y se ira incrementando el numero sin duplicarlo. Gracias¡¡

Ejemplo:

Código MySQL:

CREATE TABLE TRABAJA_EN
    (DniEmpleado        CHAR(9)     NOT NULL,
     NumProy        INT         NOT NULL,
     Horas          DECIMAL(3,1)        NOT NULL,
    PRIMARY KEY(DniEmpleado, NumProy),
    FOREIGN KEY(DniEmpleado) REFERENCES EMPLEADO(Dni),
    FOREIGN KEY(NumProy) REFERENCES PROYECTO(NumProyecto) );
 

Tabla con la que conecta:

Código MySQL:

CREATE TABLE EMPLEADO
    (Nombre VARCHAR(50)     NOT NULL,
     Apellido1  VARCHAR(50),
     Apellido2  VARCHAR(50)     NOT NULL,
     Dni        CHAR(9)     NOT NULL,
     FechaNac   DATE,
     Direccion  VARCHAR(50),
     Sexo       CHAR,
     Sueldo     DECIMAL(10,2),
     SuperDni   CHAR(9),
     Dno        INT         NOT NULL,
    PRIMARY KEY(Dni),
    FOREIGN KEY(SuperDni) REFERENCES EMPLEADO(Dni) );
 

La otra tabla con la que conecta:

Código MySQL:

CREATE TABLE PROYECTO
(NombreProyecto VARCHAR(50)     NOT NULL,
     NumProyecto        INT         NOT NULL,
     UbicacionProyecto  VARCHAR(50),
     NumDptoProyecto    INT         NOT NULL,
    PRIMARY KEY(NumProyecto),
    UNIQUE(NombreProyecto),
    FOREIGN KEY(NumDptoProyecto) REFERENCES DEPARTAMENTO(NumeroDpto) );
 

[gnzsoloyo]

Una FOREIGN KEY (ver definición en Wikipedia para más datos) es un campo o conjunto de campos que referencia a la PK de otra tabla. Si la PK de la otra tabla está formada por un VARCHAR, CHAR, DATE, TIME, o lo que sea, al sistema no le importa. Sólo le importa que la PK y la FK estén conformadas por el mismo tipo de dato, del mismo rango y eventualmente misma collation y charset.
Por otro lado, te aclaro: Una PK no necesariamente es un INT AUTO_INCREMENT. Si alguien te dijo que eso, te dijo tonterías.
Una PK es un campo o conjunto de campos que identifican a un único registro en una tabla. Es un identificador. Que lo hagas con un INT, CHAR, DATE o VARACHAR es irrrelevante para el modelo. Lo que importa es que cada valor de una PK de un registro de la tabla jamás pueda repetirse. Nunca.
Es común creer que un ID autoincremental es una PK. Eso no sólo no es cierto, sino que además es una mala práctica, muy usual entre los programadores. Pero cuando estudias formalmente las bases de datos aprendes que en la mayoría de las ocasiones las mejores PK están creadas con diversos tipos de dato, y que muchas veces los mejores diseños ni siquiera usan PK numéricas.
Según lo que se estudia en BBDD, una tabla sólo debe llevar PK numéricas incrementales o no, si llegados a la Tercera Forma Normal (ver Normalización de Bases de Datos), no se ha encontrado una clave candidata para PK.
El problema es que como son "fáciles" de programar, y muy habituales para los programadores, se cree que eso es correcto. Lo que yo te puedo decir por experiencia, es que traen problemas de migración, de integración, de restauración de datos y bases, y muchas otras cosas que sólo se ven a largo plazo.
Es mejor buscar bien las CC y no crearle una PK autoincremental.

[halexander]

Iniciado por gnzsoloyo

Una FOREIGN KEY (ver definición en Wikipedia para más datos) es un campo o conjunto de campos que referencia a la PK de otra tabla. Si la PK de la otra tabla está formada por un VARCHAR, CHAR, DATE, TIME, o lo que sea, al sistema no le importa. Sólo le importa que la PK y la FK estén conformadas por el mismo tipo de dato, del mismo rango y eventualmente misma collation y charset.
Por otro lado, te aclaro: Una PK no necesariamente es un INT AUTO_INCREMENT. Si alguien te dijo que eso, te dijo tonterías.
Una PK es un campo o conjunto de campos que identifican a un único registro en una tabla. Es un identificador. Que lo hagas con un INT, CHAR, DATE o VARACHAR es irrrelevante para el modelo. Lo que importa es que cada valor de una PK de un registro de la tabla jamás pueda repetirse. Nunca.
Es común creer que un ID autoincremental es una PK. Eso no sólo no es cierto, sino que además es una mala práctica, muy usual entre los programadores. Pero cuando estudias formalmente las bases de datos aprendes que en la mayoría de las ocasiones las mejores PK están creadas con diversos tipos de dato, y que muchas veces los mejores diseños ni siquiera usan PK numéricas.
Según lo que se estudia en BBDD, una tabla sólo debe llevar PK numéricas incrementales o no, si llegados a la Tercera Forma Normal (ver Normalización de Bases de Datos), no se ha encontrado una clave candidata para PK.
El problema es que como son "fáciles" de programar, y muy habituales para los programadores, se cree que eso es correcto. Lo que yo te puedo decir por experiencia, es que traen problemas de migración, de integración, de restauración de datos y bases, y muchas otras cosas que sólo se ven a largo plazo.
Es mejor buscar bien las CC y no crearle una PK autoincremental.

Gracias amigo¡¡¡ me sirvió de mucho =) eres bueno¡¡