Autor | |
---|---|
Escrito por Herouth Maoz |
Nota del Editor | |
---|---|
Este art�culo apareci� originalmente en la lista de correo, como respuesta a la pregunta: "�Cual es la diferencia entre las restricciones PRIMARY KEY y UNIQUE?". |
Asunto: Re: [PREGUNTAS] PRIMARY KEY | UNIQUE Cual es la diferencia entre: PRIMARY KEY(campos,...) y UNIQUE (campos,...) - �Son sin�nimos? - Si PRIMARY KEY ya indica una clave (key) �nica, entonces �porqu� existe otra clase de clave llamada UNIQUE? |
Una clave primaria es el campo (o los campos) usado para identificar una fila. Por ejemplo, el n�mero de identificaci�n fiscal de una persona.
Una simple combinaci�n �nica de campos (UNIQUE) no tiene nada que ver con la identificaci�n de la columna. Es simplemente una restricci�n de integridad. Por ejemplo, yo tengo una colecci�n de enlaces. Cada colecci�n se identifica por medio de un n�mero �nico, que es la clave primaria. Esta clave se usa en relaciones.
Sin embargo, mi aplicaci�n exige que cada colecci�n tenga tambi�n un nombre �nico. �Porqu�? Para que un ser humano que quiera modificar una colecci�n tambi�n sea capaz de identificarla. Es mucho mas dif�cil saber, si se tienen dos colecciones llamadas "Ciencia de la Vida", que la que tiene el n�mero 24433 es la que usted necesita y no la que tiene el n�mero 29882.
De esta forma, el usuario selecciona las colecciones por sus nombres. Por lo tanto nos aseguramos que los nombres sean �nicos dentro de la base de datos. Sin embargo ninguna otra tabla en la base de datos se refiere a la tabla de colecciones por su nombre. Eso ser�a bastante ineficiente.
�A�n mas, a pesar de ser �nico, el nombre de la colecci�n no define realmente la colecci�n! Por ejemplo, si alguien decidiera cambiar el nombre de la colecci�n de "Ciencia de la Vida" por "Biolog�a", a�n seguir�a siendo la misma colecci�n, solo que con un nombre diferente. Mientras el nombre sea �nico no hay problema.
Resumiendo:
Clave primaria:
Usada para identificar la fila y para referirse a ella.
Es imposible (o muy dif�cil) de actualizar.
No debe aceptar valores NULL.
Campos "unique":
Se usan como alternativa para acceder una fila.
Pueden ser actualizados siempre y cuando mantengan su valor �nico.
Aceptan valores NULL.
En cuanto a la pregunta de �por qu� no se definen claves no-�nicas expl�citamente en la sintaxis est�ndar de SQL? Pues hay que entender que los �ndices dependen de la implementaci�n espec�fica. SQL no define la implementaci�n, simplemente las relaciones entre los datos y la base de datos. Postgres acepta �ndices no-�nicos, pero los �ndices usados como claves SQL son siempre �nicos.
De esta forma, puede efectuar b�squedas en una tabla por medio de cualquier combinaci�n de columnas, a pesar de que no tenga un �ndice en esas columnas. Los no �ndices son sino una ayuda que cada implementaci�n de un RDBMS le ofrece, para permitir que las b�squedas usadas frecuentemente sean hechas de una forma m�s eficiente. Algunos RDBMS pueden proporcionarle mecanismos adicionales, tales como el almacenamiento de una clave en la memoria principal. Esos mecanismos tendr�n una orden especial, por ejemplo
CREATE MEMSTORE ON <table> COLUMNS <cols> |
�De hecho cuando usted crea una clave primaria o una combinaci�n �nica de campos, la especificaci�n SQL no dice en ninguna parte que sea creado un �ndice o que la obtenci�n de los datos por medio de la clave sea m�s eficiente que una b�squeda secuencial!
As� que si usted quiere usar como clave secundaria una combinaci�n de campos que no es �nica, no tiene que especificar nada - �simplemente comience a obtener datos usando esa combinaci�n! Sin embargo, si quiere que la obtenci�n de los datos sea m�s eficiente, tendr� que optar por los medios que su RDBMS le proporciona - ya sea un �ndice, la orden MEMSTORE que invent� como ejemplo, o un RDBMS inteligente que cree �ndices, sin su conocimiento, bas�ndose en el hecho de que usted ha efectuado varias b�squedas con la misma combinaci�n espec�fica de claves... (Aprende con la experiencia).