Claves primarias ¿simples o compuestas?
Clave primaria compuesta.
Recordemos que una clave primaria identifica 1 solo registro en una tabla. Para un valor del campo clave existe solamente 1 registro. Los valores no se repiten ni pueden ser nulos.
Retomemos el ejemplo de la playa de estacionamiento que almacena cada día los datos de los vehículos que ingresan en la tabla llamada "vehiculos" con los siguientes campos:
- patente char(6) not null, - tipo char (4), - horallegada time not null, - horasalida time,
Necesitamos definir una clave primaria para una tabla con los datos descriptos arriba. No podemos usar la patente porque un mismo auto puede ingresar más de una vez en el día a la playa; tampoco podemos usar
la hora de entrada porque varios autos pueden ingresar a una misma hora. Tampoco sirven los otros campos.
Como ningún campo, por si solo cumple con la condición para ser clave, es decir, debe identificar un solo registro, el valor no puede repetirse, debemos usar 2 campos.
Definimos una clave compuesta cuando ningún campo por si solo cumple con la condición para ser clave.
Usamos 2 campos como clave, la patente junto con la hora de llegada, así identificamos unívocamente cada registro.
Para establecer más de un campo como clave primaria usamos la siguiente sintaxis:
Para establecer más de un campo como clave primaria usamos la siguiente sintaxis:
create table vehiculos( patente char(6) not null, tipo char(4), horallegada time not null horasalida time, primary key(patente,horallegada) );
Ahora desarrollando me encontré con el siguiente TABLA :
CREATE TABLE `ServiceBalanceQuota` ( `idServicePCRF` int(11) NOT NULL, `idBalance` int(11) NOT NULL default '0', `idQuota` int(11) NOT NULL, `idProduct` int(11) NOT NULL, PRIMARY KEY (`idServicePCRF`,`idQuota`,`idProduct`), KEY `IDX_Produ` (`idProduct`), KEY `IDX_Service` (`idServicePCRF`), KEY `IDX_Balance` (`idBalance`), KEY `IDX_Quota` (`idQuota`), CONSTRAINT `FK_Balance` FOREIGN KEY (`idBalance`) REFERENCES `Balance` (`idBalance`) ON DELETE NO ACTION ON UPDATE NO ACTION, CONSTRAINT `Fk_Product` FOREIGN KEY (`idProduct`) REFERENCES `Product` (`idProduct`) ON DELETE NO ACTION ON UPDATE NO ACTION, CONSTRAINT `FK_Quota` FOREIGN KEY (`idQuota`) REFERENCES `Quota` (`idQuota`) ON DELETE NO ACTION ON UPDATE NO ACTION, CONSTRAINT `FK_Service` FOREIGN KEY (`idServicePCRF`) REFERENCES `ServicePCRF` (`idServicePCRF`) ON DELETE NO ACTION ON UPDATE NO ACTION )
Podemos ver que tiene clave compuesta de , PRIMARY KEY (`idServicePCRF`,`idQuota`,`idProduct`) Ahora si se quiere insertar los siguientes registros con esta estructura ?
MultiSmart Bal_Plan_1 QPS_1_RS QPS_1_BON_V QPS_1_BON_A MultiSmart Bal_Plan_1 QPS_1_RS QPS_1_BON_V QPS_1_BON_A MultiSmart Bal_Plan_2 QPS_1_RS QPS_1_BON_V QPS_1_BON_A MultiSmart Bal_Addon_1 QPS_1_RS QPS_1_BON_V QPS_1_BON_A MultiSmart Bal_Addon_2 QPS_1_RS QPS_1_BON_V QPS_1_BON_A
Obviamente no se puede.Una Primary Key no puede tener valores repetidos ni valores nulos. Y eso, hay varias formas de conseguirlo.
Lo más conveniente siempre es que la columna que actúa como Primary Key (o una de las columnas, si es compuesta) sea autoincremental porque eso nos asegura que no tendrá valores repetidos ni nulos porque el mismo Firebird se encarga de asignarle valores a esa columna.
Pero ¿una columna o varias columnas?
Si planeas usar replicación entonces lo más conveniente es que la Primary Key esté compuesta por dos (o más) columnas. Si crees que nunca usarás replicación entonces puedes usar una sola columna autoincremental para ella.
La replicación es enviar los datos de una Base de Datos a otra Base de Datos. Por ejemplo tienes sucursales en Buenos Aires, Montevideo y Bogotá, cada una de ellas con su respectiva Base de Datos y quieres consolidar las ventas de esas tres sucursales para tenerlas en una sola Base de Datos. Entonces, debes poder distinguir en cual sucursal se realizó cada venta y los identificadores no te servirán porque pueden estar repetidos.
Conclusión:
- Si no usas ni planeas usar replicación entonces la Primary Key puede estar compuesta por una sola columna autoincremental
- Si usas o podrías llegar a usar replicación, entonces la Primary Key debería estar compuesta por dos columnas: una que identifique a la Sucursal y otra que sea autoincremental
