sql server - primary - ¿Por qué usar “clave primaria no nula” en TSQL?
primary key sql server ejemplo (7)
Con mucha frecuencia veo "clave principal no nula" en los scripts que crean tablas en TSQL en blogs, artículos, libros, foros, aquí en SO, etc.
Por ejemplo, BING da 630,000 resultados ((solo en inglés) si se busca contra "no nulo" CERCA de "clave primaria" "servidor SQL":
http://www.bing.com/search?q=%22not+null%22+NEAR+%22primary+key%22+%22sql+server%22&go=&form=QBRE&filt=lf
Siempre percibí "NOT NULL" como parte inseparable de la definición de PRIMARY KEY, al menos en SQL Server.
Intenté crear una tabla con CLAVES primarias con y sin "NOT NULL" en SQL Server, pero no pude captar la posible diferencia.
¿Por qué todos usan "NOT NULL" para crear una clave principal incluso en ilustraciones rápidas (cortas)?
Actualizar:
¿Cómo puede NULL identificar algo o ser único (así como prevenir múltiples NULL si se permite uno)? Es un valor no especificado, faltante, no aplicable.
Mi pregunta también implicaba subpreguntas:
Si uno define "NOT NULL" para PK, ¿por qué entonces no se especifica UNIQUE?
Y cuál es la definición de PK. ¿ES RESTRICCIÓN ÚNICA + NO NULL o ÍNDICE ÚNICO (entonces por qué NO NULL)?
Por favor, dame el enlace a msdn documentos en él.
Update2: @Damien_The_Unbeliever
¿Por qué no es sinónimo sin "NOT NULL"?
CREATE TABLE T3
(
PK int -- NOT NULL commented out
, nonPK int -- to double-check my sanity
, constraint PK_vgv8 PRIMARY KEY (PK) on [PRIMARY]
)
todavía no permite dar NULL:
Microsoft SQL Server Management Studio
No se actualizó ninguna fila.
Los datos en la fila 2 no fueron confirmados. Origen del error: .Net SqlClient Data Provider. Mensaje de error: No se puede insertar el valor NULL en la columna ''PK'', tabla ''TestData.dbo.T3''; La columna no permite nulos. INSERTAR falla.
La instrucción se ha terminado.
Corrija los errores y vuelva a intentarlo o presione ESC para cancelar los cambios.
Ok ayuda
Update3:
Esto, la definición de conceptos y términos, puede aparecer como una molestia poco práctica.
No es, una declaración errónea (en la opinión de otro (s) durante la comunicación / discusión) sobre una noción básica es suficiente para ser considerado un imbécil y crear barreras en la interacción y comunicación profesional.
¡Olvidé decirle, NO NULL está programado por SSMS para PK!
El seguimiento:
CREATE TABLE T1 (
T1ID int not null primary key
)
Es realmente una taquigrafía para lo siguiente:
CREATE TABLE T1 (
T1ID int not null,
constraint <system generated name> PRIMARY KEY (T1ID) on [PRIMARY]
)
La definición de la columna es realmente bastante separada de la definición de la restricción. Es solo que la taquigrafía oculta el hecho de que son dos definiciones separadas. (Por supuesto, si usa el formulario de mano larga, puede hacer cosas como definir una clave principal en varias columnas).
Editar , en respuesta a la actualización. No, todavía no puede tener una columna anulable en la clave principal. Pero dado que es normal especificar la nulabilidad de cada columna en una declaración de creación de la tabla, es extraño omitirla (aunque esté implícito / sea requerido por la restricción PRIMARY KEY).
CREATE TABLE T1 (
T1ID int,
constraint <system generated name> PRIMARY KEY (T1ID) on [PRIMARY]
)
crea exactamente la misma tabla que el ejemplo de código anterior. Especificar explícitamente la capacidad "no nula" de una columna es, entonces, más un reconocimiento explícito del resultado, en lugar de un requisito.
Y finalmente, encontrará que ocurre con frecuencia en el código de ejemplo porque las personas han desarrollado su base de datos y luego han utilizado las herramientas SQL integradas para generar un script a partir de su base de datos: las herramientas de scripting siempre ponen todo explícitamente.
Lo curioso de MYSQL es que el comportamiento es muy bueno cuando se pasa un valor NULL (o 0) a un campo de primary key auto_increment .
Di que tienes
create table Users(
userId int primary key auto_increment
) ;
insert into users( userId ) values ( null ) ; -- insert OK
select * from Users ; -- Shows 1
Entonces, si pasa 0 o NULL a un campo auto_increment , simplemente selecciona el siguiente valor disponible.
Si quita la propiedad auto_increment , una inserción en un campo de CLAVE PRINCIPAL con NULL falla, porque una CLAVE PRIMARIA no puede ser nula, es el error. Por lo tanto, NOT NULL en PRIMARY KEY NOT NULL está implícito en MySQL al menos.
No conozco ningún DBMS que permita el uso de una columna anulable en una restricción PRIMARY KEY. El estándar SQL especifica que las columnas en una restricción PRIMARY KEY no pueden ser anulables.
En el modelo relacional, las claves candidatas consisten en valores únicos, no nulos. Es una peculiaridad de SQL que las columnas anulables se pueden usar opcionalmente en restricciones ÚNICAS. Esa característica es probablemente responsable de muchos problemas de calidad de datos. Le recomiendo que evite el uso de columnas anulables en restricciones ÚNICAS. Si es necesario, cree una nueva tabla para los valores no anulables y ponga la restricción ÚNICA en eso.
No se requiere de manera sintáctica, ya que este será el valor predeterminado de todos modos si no se especifica para las columnas de Clave principal, independientemente de la configuración predeterminada para las otras columnas.
SET ANSI_NULL_DFLT_ON ON /*Set default for columns to allow NULL if not specified*/
CREATE TABLE #t
(
i INT PRIMARY KEY,
j INT
)
SELECT name,is_nullable
FROM tempdb.sys.columns
WHERE object_id=object_id(''tempdb..#t'')
INSERT INTO #t VALUES (1,NULL) /*Succeeds as j allows NULL*/
INSERT INTO #t VALUES (NULL, 1)/*Won''t succeed as column doesn''t allow nulls*/
DROP TABLE #t
Parece que voy en otra dirección para explicar por qué no se aceptan nulos y la clave principal también se acepta en un campo cuando la clave principal no se considera nula.
Digamos que tenemos la tabla table1, lo que significa que mantendrá su valor para almacenar datos bidimensionales. Si creo una tabla con un solo campo, es aceptable, pero ¿cuál es su uso en tiempo real en el mundo real de objetos? Será una tabla tridimensional que solo almacena datos de un campo que conduce a No hay información, creo. Y mantener ese campo para aceptar valores nulos no tiene sentido.
Ahora, supongamos que hemos definido una tabla con 2 campos, lo que significa que podemos obtener buena información de cada fila cuando se llena con los datos apropiados.
Hacer que esos 2 campos acepten el valor nulo no tiene ningún sentido esperar si queremos empujar basura o esperar que el conteo (*) resulte en una fila adicional.
Por lo tanto, mi opinión es que poner no nulo es obligatorio al menos para 2 archivos si deseamos utilizar tablas normalizadas con buenos conceptos fundamentales de RDBMS. Antes de pensar si la tabla necesita una clave primaria como una restricción, siempre definimos el archivo no nulo. Y además, si es necesario, use la clave principal y tenga en cuenta que puede soltarla en cualquier momento pero no ''no nulo''
Y si estamos seguros de que no descartaremos la clave principal, usamos solo la clave principal, de lo contrario no son nulas ni la clave principal.
Todo depende del uso y, como he dicho, las definiciones de tablas básicas y la regla de Codd deben alcanzarse para lograr una buena base de datos.
Toda clave principal significa que es el identificador de la tabla y, por lo tanto, único por definición. Único no significa que no sea nulo, por lo que si tiene el requisito de que la clave principal no puede ser nula, tiene que especificarlo explícitamente. Si permites null solo estás diciendo que está bien tener un valor nulo en la columna, pero solo puedes tener uno, ya que tiene que ser único.
Editado para mayor claridad
De acuerdo con la Especificación SQL, una clave primaria no puede contener NULL. Esto significa que decorar una columna con "CLAVE PRIMARIA NO NULA" o simplemente "CLAVE PRINCIPAL" debería hacer lo mismo. Pero está confiando en el motor SQL en cuestión siguiendo correctamente el estándar SQL. Como ejemplo, debido a un error anterior, SQL Lite no implementa correctamente el estándar y permite valores nulos en claves primarias no enteras (consulte sqlite.org/lang_createtable.html ). Eso significaría que para (al menos) SQLLite las dos declaraciones hacen dos cosas diferentes.
Como "NOT NULL PRIMARY KEY" indica claramente la intención y continúa con valores no nulos, incluso si se elimina la clave principal, esa debe ser la sintaxis preferida.