¿Cuántas columnas son demasiadas para una tabla de SQL Server 2005?

Question

Tengo una solicitud para permitir que una tabla dinámica tenga 1000 columnas (seleccionadas al azar por mis usuarios finales). Esto me parece una mala idea. Es una tabla personalizable por lo que tendrá una mezcla de varchar(200) y float columnas (el float se adapta mejor a las aplicaciones de tipo doble de C++). Esta base de datos es principalmente un índice para una aplicación heredada y sirve como un repositorio de informes. No es el sistema de registro. La aplicación tiene miles de puntos de datos muy pocos de los cuales podrían ser normalizados.

¿Alguna idea de cuáles son las implicaciones de rendimiento de esto? ¿O un tamaño de mesa ideal para particionar esto también?

Como no sé qué campos de los 20k de opciones que los usuarios finales seleccionarán, la normalización de las tablas no es factible. Puedo separar estos datos en varias tablas que tendría que administrar dinámicamente (los campos se pueden agregar o colgar. Las filas se eliminan y el sistema de registro se vuelve a analizar para llenar la tabla.) Mi preferencia es retroceder y normaliza todos los 20k bits de datos. Pero no veo que eso suceda.

Answer 1

Esto huele a un mal diseño para mí.

Cosas a considerar:

¿La mayoría de esas columnas que contienen valores NULL?

¿Se nombrarán muchos Property001, Property002, Property003, etc ...?

Si es así, le recomiendo que reconsidere la normalización de sus datos.

Answer 2

Como regla: cuanto más ancha es la tabla, más lento es el rendimiento. Muchas mesas delgadas son preferibles a un desastre gordo de una mesa.

Si su tabla es tan amplia, es casi seguro que es un problema de diseño. No hay una regla real sobre cuántos es preferible, nunca me he encontrado con tablas con más de 20 columnas en el mundo real. Solo grupo por relación. Es un RDBMS después de todo.

Answer 3

Parece un montón. Primero me aseguraría de que los datos estén normalizados. Eso podría ser parte de tu problema. ¿Qué tipo de propósito servirán estos datos? ¿Es para informes? ¿Cambiaran los datos?

Creo que una mesa tan amplia sería una actuación de pesadilla y de mantenimiento.

Answer 4

Eso es demasiado. Tiene más de 50 columnas de ancho y está solicitando problemas de rendimiento, mantenimiento del código y resolución de problemas cuando surgen problemas.

Answer 5

de documentación SQL2005:

SQL Server 2005 puede tener hasta dos mil millones de tablas por base de datos y 1.024 columnas por tabla. (...) El número máximo de bytes por fila es 8,060. Esta restricción se relaja para las tablas con columnas varchar, nvarchar, varbinary o sql_variant que hacen que el ancho total de la tabla definida supere los 8.060 bytes. Las longitudes de cada una de estas columnas aún deben estar dentro del límite de 8,000 bytes, pero sus anchos combinados pueden exceder el límite de 8.060 bytes en una tabla.

¿Cuál es la funcionalidad de estas columnas? ¿Por qué no mejor dividirlos en tabla maestra, propiedades (tablas de búsqueda) y valores?

Answer 6

MS SQL Server tiene un límite de 1024 columnas por tabla, por lo que se ejecutará justo al borde de esto. Al usar columnas varchar (200), podrá ir más allá del límite de 8k bytes por fila, ya que SQL almacenará 8k en la página de datos y luego desbordará los datos fuera de la página.

SQL 2008 agregó Sparse Columns para escenarios como este, donde tendría muchas columnas con valores nulos.

Uso de columnas dispersas http://msdn.microsoft.com/en-us/library/cc280604.aspx

Answer 7

Esto tendrá un gran rendimiento y problemas de datos. Probablemente necesita ser normalizado.

Mientras que el servidor SQl le permitirá crear una tabla que tenga más de 8060 bytes de fila interna, NO le permitirá almacenar más datos que los que contiene. Es posible que los datos se trunquen inesperadamente (y, lo que es peor, hasta varios meses más tarde podría suceder, momento en el que corregir esta monstruosidad es urgente y extremadamente difícil).

Preguntar esto también será un problema real. ¿Cómo sabría cuál de las 1000 columnas buscar los datos? ¿Debería cada consulta solicitar las 1000 columnas en la cláusula where?

Y la idea de que esto sea personalizable por el usuario da miedo. ¿Por qué el usuario necesitaría 1000 campos para personalizar? La mayoría de las aplicaciones que he visto que le dan al usuario la oportunidad de personalizar algunos campos establecen un límite pequeño (por lo general, menos de 10). Si hay tanto que necesitan personalizar, la aplicación no ha hecho un buen trabajo al definir lo que el cliente realmente necesita.

A veces como desarrollador solo tienes que ponerte de pie y decir no, esta es una mala idea. Éste es uno de esos momentos.

En cuanto a lo que debes hacer en su lugar (aparte de normalizar), creo que necesitaríamos más información para apuntar en la dirección correcta.

Y BTW, float es un tipo de datos inexacto y no debe usarse para los campos en los que se realizan cálculos a menos que desee resultados incorrectos.

Answer 8

Cuando sienta la necesidad de preguntar qué límites tiene el sistema, tiene un problema de diseño.

Si estuviera preguntando "¿Cuántos caracteres puedo caber en un varchar?" entonces no deberías estar usando varchar.

Si realmente quiere saber si 1000 columnas están bien, necesita desesperadamente reorganizar los datos. (normalización)

Answer 9

¿Pensó en ver la tabla final (1000 columnas) como resultado de una consulta cruzada? Su tabla original tendría solo unas pocas columnas pero muchos miles de registros.

¿Puede explicar su problema? ¡Creo que nadie realmente entiende por qué necesitas estas 1000 columnas!

Answer 10

Tengo que estar en desacuerdo con todos los que están aquí ..... Sé que parece una locura, pero usar tablas con cientos de columnas es lo mejor que he hecho.

Sí, muchas columnas suelen tener valores nulos; Sí, podría normalizarlo en unas pocas tablas y transponer; Sí es ineficiente

Sin embargo, es increíblemente rápido y fácil de analizar los datos de columna en un sinfín de formas diferentes

antieconómica y poco elegante - nunca se va a construir algo tan útil!