Recientemente me he dado cuenta que se puede crear todo de una vez y queda elegante. veamos un ejemplo
CREATE TABLE dbo.OrdenDetalle
(
conOrden INT NOT NULL
CONSTRAINT OrdenEncabezado_OrdenDetalle_FK FOREIGN KEY
REFERENCES dbo.OrdenEncabezado(conOrden),
conOrdenDetalle INT NOT NULL IDENTITY (1,1),
desLinea VARCHAR(254) NOT NULL,
numPrecio MONEY NOT NULL,
usrIngreso VARCHAR(20) NOT NULL
CONSTRAINT DF_OrdenDetalle_usrIngreso DEFAULT (user_name()),
fecIngreso DATETIME NOT NULL
CONSTRAINT DF_OrdenDetalle_fecingreso DEFAULT (getdate()),
CONSTRAINT PK_OrdenDetalle
PRIMARY KEY CLUSTERED (conOrden, conOrdenDetalle)
WITH (IGNORE_DUP_KEY = OFF)
);
Describamos el script.Primeramente tenemos la declaración de la creación de la tabla OrdenDetalle y entre paréntesis la descripción completa de la misma. Declaramos el primer campo, conOrden, que es una llave foránea proveniente de la tabla OrdenEncabezado. Todo esto lo añadimos en la especificación de la columna por medio de un constraint para darle nombre a la FK. Cada especificación completa de columna se separa de la siguiente con una coma.
Seguidamente añadimos conOrdenDetalle que es un número consecutivo Identity, que comienza en uno y se incrementa automáticamente de uno en uno. Añadimos dos columnas más: desLinea (varchar) y numPrecio (money), la descripción de la línea y el precio de la misma respectivamente.
Seguidamente dos columna de seguimiento como son el usuario que ingresó la línea (usrIngreso) y la fecha de ingreso (fecIngreso), ambas con valores por defecto usando constraints con nombres descriptivos.
Finalmente creamos una constraint más, correspondiente a la llave primaria de la tabla, usando las columnas conOrden y conOrdenDetalle dejando explícitamente que esta llave no se puede duplicar (innecesario en realidad ya que la segunda parte de la llave es un identity).
A mi, en lo personal, me parece una forma más compacta y elegante, que manejarlo por separado.