¿El orden lógico de las columnas en una tabla tiene algún impacto en su orden físico en la capa de almacenamiento? Sí.
Si importa o no es un tema diferente que no puedo responder (todavía).
De manera similar a la descrita en el artículo frecuentemente vinculado de Paul Randal sobre la anatomía de un registro , veamos una tabla simple de dos columnas con DBCC IND:
SET STATISTICS IO OFF;
SET STATISTICS TIME OFF;
USE master;
GO
IF DATABASEPROPERTY (N'RowStructure', 'Version') > 0 DROP DATABASE RowStructure;
GO
CREATE DATABASE RowStructure;
GO
USE RowStructure;
GO
CREATE TABLE FixedLengthOrder
(
c1 INT IDENTITY(1,1) PRIMARY KEY CLUSTERED
, c2 CHAR(10) DEFAULT REPLICATE('A', 10) NOT NULL
, c3 CHAR(10) DEFAULT REPLICATE('B', 10) NOT NULL
);
GO
INSERT FixedLengthOrder DEFAULT VALUES;
GO
DBCC IND ('RowStructure', 'FixedLengthOrder', 1);
GO
El resultado anterior muestra que debemos mirar la página 89:
DBCC TRACEON (3604);
GO
DBCC PAGE ('RowStructure', 1, 89, 3);
GO
En la salida de DBCC PAGE vemos c1 relleno con el carácter 'A' antes de 'B' de c2:
Memory Dump @0x000000000D25A060
0000000000000000: 10001c00 01000000 41414141 41414141 †........AAAAAAAA
0000000000000010: 41414242 42424242 42424242 030000††††AABBBBBBBBBB...
Y solo porque, abra el busto RowStructure.mdf
con un editor hexadecimal y confirme que la cadena 'A' precede a la cadena 'B':
Ahora repita la prueba pero invierta el orden de las cadenas, colocando los caracteres 'B' en c1 y los caracteres 'A' en c2:
CREATE TABLE FixedLengthOrder
(
c1 INT IDENTITY(1,1) PRIMARY KEY CLUSTERED
, c2 CHAR(10) DEFAULT REPLICATE('B', 10) NOT NULL
, c3 CHAR(10) DEFAULT REPLICATE('A', 10) NOT NULL
);
GO
Esta vez nuestra salida DBCC PAGE es diferente y la cadena 'B' aparece primero:
Memory Dump @0x000000000FC2A060
0000000000000000: 10001c00 01000000 42424242 42424242 †........BBBBBBBB
0000000000000010: 42424141 41414141 41414141 030000††††BBAAAAAAAAAA...
Nuevamente, solo por risitas, verifiquemos el volcado hexadecimal del archivo de datos:
Como explica Anatomy of a Record , las columnas de longitud fija y variable de un registro se almacenan en bloques distintos. Lógicamente, el intercalado de tipos de columnas fijas y variables no tiene relación con el registro físico. Sin embargo, dentro de cada bloque, el orden de sus columnas se asigna al orden de bytes en el archivo de datos.
CREATE TABLE FixedAndVariableColumns
(
c1 INT IDENTITY(1,1) PRIMARY KEY CLUSTERED
, c2 CHAR(10) DEFAULT REPLICATE('A', 10) NOT NULL
, c3 VARCHAR(10) DEFAULT REPLICATE('B', 10) NOT NULL
, c4 CHAR(10) DEFAULT REPLICATE('C', 10) NOT NULL
, c5 VARCHAR(10) DEFAULT REPLICATE('D', 10) NOT NULL
, c6 CHAR(10) DEFAULT REPLICATE('E', 10) NOT NULL
);
GO
Memory Dump @0x000000000E07C060
0000000000000000: 30002600 01000000 41414141 41414141 †0.&.....AAAAAAAA
0000000000000010: 41414343 43434343 43434343 45454545 †AACCCCCCCCCCEEEE
0000000000000020: 45454545 45450600 00020039 00430042 †EEEEEE.....9.C.B
0000000000000030: 42424242 42424242 42444444 44444444 †BBBBBBBBBDDDDDDD
0000000000000040: 444444†††††††††††††††††††††††††††††††DDD
Ver también:
El orden de las columnas no importa ... en general, pero ... ¡DEPENDE!
CREATE TABLE
declaración (excepto que las columnas de clave CI aparecen primero en la sección). Aunque el orden de las columnas puede cambiar siALTER COLUMN
cambia los tipos de datos / longitudes de columna. El único caso menor en el que importa que se me ocurra es que las columnas al final de la sección de longitud variable con una cadena vacía o NULL no ocupan espacio en absoluto en la matriz de desplazamiento de columnas (demostrado por Kalen Delaney en el libro interno de 2008)