¿Las columnas vacías ocupan espacio en una tabla?

20

Tengo una tabla que contiene información muy básica. Solo un título y algunos campos de fecha. Hay un campo llamado comentarios que es varchar (4000). La mayoría de las veces lo dejamos en blanco, pero algunas veces ingresaremos una gran cantidad de datos aquí. ¿Es este un diseño realmente malo? ¿O es esto solo un poco ineficiente?

Supongo que sería mejor crear una tabla separada para esta columna.

nota: este es el servidor SQL 2008

ingrese la descripción de la imagen aquí

sql-server-2008 database-design

— aron
fuente

Gracias por sus comentarios a todos! Decidí hacerlo simple y mantener la columna en la tabla y no ponerla en otra tabla. Sin embargo, utilicé la función SPARSE en SQL 2008 para que el campo no use ningún espacio.

2

Por curiosidad, ¿qué es "la mayor parte del tiempo"? ¿Cuántas filas en total y qué porcentaje tiene un valor aquí? Me pregunto si está planeando hacer comparaciones de espacio / rendimiento usando SPARSEy no usando SPARSE...

— Aaron Bertrand

9

Para un rendimiento más predecible (y para evitar tener una gran variación de filas por página), me inclinaría a almacenar estos datos en una tabla relacionada, especialmente si solo se llena un pequeño porcentaje del tiempo, y especialmente si solo se recupera en Algunas de las consultas. Las filas donde está este valor NULLcontribuyen a la sobrecarga de espacio, pero esto es mínimo. Lo más importante será cómo una página puede caber solo en dos filas y la página siguiente puede caber en 500 filas; esto realmente puede afectar las estadísticas y es mejor dividir esto para que se almacene por separado y no afecte todas sus operaciones en La mesa central.

— Aaron Bertrand
fuente

12

Ocupa un espacio mínimo cuando no se usa

un bit en el mapa de bits NULL
dos bytes para la longitud (que será cero cuando NULL)

La sobrecarga es mínima y la optimización será prematura.

Hasta que sepa que tiene un problema, simplemente manténgalo en una tabla. Rompe KISS introduciendo combinaciones externas y agregando una sobrecarga al consultar los datos.

Ver /programming/3793022/how-to-come-to-limits-of-8060-bytes-per-row-and-8000-per-varchar-nvarchar-valu/3793265#3793265 para más

— gbn
fuente

10

Creo que una tabla separada sería mejor para mejorar la densidad de la página y reducir la fragmentación, especialmente si no siempre llena ese campo.

Una página de datos contiene alrededor de 8000 bytes.
Tiene algunas filas con digamos 100 bytes y algunas filas con más de 4000 bytes
Esas filas largas estarán en una página por sí mismas, y el resto de la página es espacio "desperdiciado" que ocupa su base de datos, pero probablemente nunca contendrá datos
Si agrega datos a ese campo largo para un registro en una página casi llena, es probable que sobrepase la página y dé como resultado un puntero a la página con el resto del registro

Todas estas páginas vacías y punteros conducen a un bajo rendimiento. Normaliza ese campo si puedes.

— JNK
fuente

4

Esta pregunta es muy similar: ¿las columnas vacías adicionales afectan significativamente el tamaño de la tabla sql?

Parece que la respuesta es sí, ocupa espacio, pero hay un algoritmo de compresión para columnas con muchos valores nulos.

En cuanto al diseño, creo que tener una tabla externa vinculada a esto sería un diseño más limpio. Tener una columna con valores nulos frecuentes hace que sea más difícil para los usuarios de la base de datos, ya que podrían usar accidentalmente un valor nulo si no tienen cuidado. Por lo tanto, el código que usa la base de datos debería contener una comprobación de errores y simplemente se vuelve feo a partir de ahí.

— Comunidad
fuente

2

Para ser explícito, el algoritmo de compresión solo se aplica a aquellas columnas explícitamente definidas como SPARSE, no solo "columnas con muchos valores nulos".

— Aaron Bertrand

2

Estarás bien: ya es una columna varchar, por lo que solo usa espacio cuando contiene datos. Si tenía muchas columnas de tamaño fijo anulables como int, podría tener problemas de uso de espacio.

En cuanto a ponerlo en otra mesa, no me molestaría. También puede mirar usando varchar (max) y las opciones de entrada / salida de fila. De nuevo, probablemente prematuro.

— Cade Roux
fuente

1

La optimización prematura a menudo puede ser un problema real, pero eso depende del costo de refactorización posterior. Si sabe hoy que solo el 1% de sus filas tendrá datos en esta columna, y espera que la tabla crezca con el tiempo, ¿cuál es el valor de mantener esos datos en la tabla actual solo para sufrir consecuencias a medida que escala? Estoy a favor de evitar la optimización prematura, pero hay un punto en el que considero el efecto a largo plazo de hacerlo.

— Aaron Bertrand

@Aaron Bertrand estuvo de acuerdo. Las personas hacen preguntas de rendimiento aquí y es fácil suponer que pueden tener una aplicación que es de millones de filas y que necesitan usar todas las armas en el kit de herramientas y tener todo eso en mente. Por otro lado, a veces el usuario parece estar al comienzo de una curva de aprendizaje y es difícil pedirle que se dedique a algo que probablemente debería ser menor en sus prioridades. Además, con varchar (max), puede presionar un interruptor para comenzar a almacenar fuera de la fila. Creo que la verdadera respuesta aquí es "Realmente no nos has dado suficiente información para dar una respuesta definitiva".

— Cade Roux