SQL Server - Inconvenientes de rendimiento/tamaño de columnas nulas

Question

Estoy trabajando en un diseño de tabla que podría involucrar muchos valores NULL en aproximadamente 10 campos, tal vez el 75% del tiempo los campos no se utilizarían.

Acabo de generar algunos datos falsos (un millón de registros) y no pude sentir ningún impacto en SQL Server 2005. La diferencia de tamaño estaba en la KB. Rendimiento: no hay diferencia medible después de agregar un índice a las 3 columnas que no admiten nulos.

Sé que SQL Server 2008 tiene la característica de columnas dispersas (que supongo que se utilizará en la siguiente tabla UserData de SharePoint). Sin embargo, quiero que mi código funcione en 2005. Pero existen muchos valores NULL en el diseño de la tabla actual UserData de SharePoint. Entonces, si es lo suficientemente bueno para Microsoft ...

¿Algún artículo bueno, enlaces, libros blancos sobre los inconvenientes o puntos débiles alrededor de muchos valores NULOS en la tabla de SQL Server? ¿Alguien tiene alguna experiencia en lo que sucede a medida que escala a 10 mil o 100 mil registros?

Answer 1

Nunca he tenido un problema con el rendimiento en múltiples columnas nulas, incluso en bases de datos en el tamaño de cientos de gigs. Me imagino que puede terminar con problemas si está ejecutando índices en estos campos y luego usa nulo en la consulta, pero no lo he visto personalmente como un problema. Por otra parte, no he creado tablas de bases de datos donde todos los campos, excepto 3, fueran anulables.

Por otro lado, veo un problema de arquitectura cuando la mayoría de los datos son nulos. el motivo general es o bien a) una base de datos incorrectamente normalizada ob) un intento de permitir a los usuarios organizar los datos en la tabla final en lugar de crear tablas separadas para "compilar" datos antes de comprometerse con la base de datos.

Depende de usted determinar la mejor arquitectura de su base de datos.

Answer 2

No haga una tabla con un 75% de columnas sin usar. Hazlo con las columnas que vas a usar todo el tiempo y busca usar algo como EAV para las otras columnas, o ponlas en una tabla diferente.

Answer 3

Los problemas que he tenido en el pasado se refieren a las implicaciones de programación de tener valores NULL. Por ejemplo, problemas con los clientes o problemas con no consultas devolviendo datos cuando no se esperaba porque había un valor nulo allí.

Answer 4

Bueno, NULL es siempre un poco raro en las bases de datos. No creo que tenga demasiado impacto en el rendimiento en su caso, pero, por supuesto, tendrá que lidiar con todos los valores NULL por separado.

Siempre que sea posible, me esfuerzo por utilizar un valor predeterminado en su lugar, por lo que si tiene, por ejemplo, algún valor de ID de tipo INT, podría usar 0 o -1 como indicador de "no hay valor presente". De esta forma, puede evitar tener que hacer comprobaciones de valor (campo < 0) y verificar NULL por separado (el campo IS NULL o IS NOT NULL).

Marc

Answer 5

Solo hay una manera de estar seguro. Continúe e inserte 100 millones de registros y luego mida el rendimiento de extremo a extremo.

Answer 6

Lo que hago en esta situación, que es muy común, es la de dividir los datos en dos tablas:

• requieren datos
• de datos opcional

Por ejemplo, I' Actualmente estoy escribiendo un sitio web de la comunidad y una de las tablas obviamente será una tabla de usuarios. Estoy grabando una gran cantidad de información sobre los usuarios y por eso he dividir los datos colecciono en dos tablas:

• Usuarios
• DetallesUsuario

Los Usuarios tabla contiene información básica que necesitará todo el tiempo, como nombre de usuario, nombre e información de la sesión.

UserDetails tabla contiene información adicional que no necesito tan a menudo como la Página de perfil, Dirección de correo electrónico, Contraseña, Dirección del sitio web, Fecha de nacimiento y más.

Esto se conoce como vertical partitioning.

Answer 7

La mayor probabilidad de NULL en la columna, cuanto más cerca del final del registro la columna debe estar en la tabla (a la columna lat en la tabla).
Los NULLS al final de la fila no tienen espacio asignado, están determinados por NULL BITMAP vinculado a cada registro (es 2 bytes, cada bit de los cuales informa sobre (no) NULL-ness de uno de los valores de columna en registro).

Ahora, los valores NULL no se leen de la columna, se leen desde mapas de bits NULOS. Cuando se detecta NULL la lectura valor real se salta

La característica escasa debe utilizarse con precaución, ya que invoca sobrecarga en el tiempo y en el espacio para los valores no nulos para el rendimiento, es posible que para participar filtered indexing on non-null part of a column