¿Cuántas columnas hay demasiadas columnas?

Question

He notado que muchas personas aquí citan tablas con más de 20 columnas (he visto hasta 55) en una misma tabla. Ahora no pretendo ser un experto en diseño de bases de datos, pero siempre escuché que esta es una práctica horrible. Cuando veo esto, generalmente sugiero dividirlo en dos tablas con una relación de uno a uno: una que contenga los datos utilizados con mayor frecuencia, la otra con los datos menos utilizados. Aunque al mismo tiempo, existe el posible problema de rendimiento (menos JOINs y tal). Así que mi pregunta es la siguiente:

Cuando se trata de bases de datos a gran escala, ¿existe realmente la ventaja de tener una gran cantidad de columnas, a pesar de que esto generalmente conduce a muchos valores NULOS?

¿Qué es más de un golpe de rendimiento: muchas columnas con muchos NULL o menos columnas con muchos JOIN?

Answer 1

El diseño de la tabla depende de la entidad que necesita almacenar. Si todos los datos pertenecen juntos, entonces 50 columnas (o incluso 100) podrían ser lo correcto.

Siempre que la tabla sea normalized, no existe una regla general con respecto al tamaño, aparte de las capacidades de la base de datos y la necesidad de optimizar.

Answer 2

Acepto con Oded. He visto tablas con 500 columnas en ellas, y todas las columnas en ellas estaban en el lugar correcto. Simplemente considere la cantidad de datos que podría desear almacenar sobre un objeto cotidiano, y pronto verá por qué.

Si no es conveniente seleccionar todas esas columnas, o especificar qué columnas seleccionar cuando solo está interesado en una pequeña proporción de ellas, puede ser útil definir una vista.

Answer 3

¿Qué es más de un impacto en el rendimiento: un montón de columnas con una gran cantidad de valores nulos, o menos columnas con una gran cantidad de combinaciones?

Es puramente depende de los datos que almacena, los índices que realice, etc. Nadie puede asegurarle que uno funciona mejor que otro sin saber qué está almacenando. En general, las reglas de normalización "obligarán" a separar los datos a diferentes tablas y FKeys del usuario si tiene una tabla grande, pero no estoy de acuerdo en que SIEMPRE rinda mejor que una gran tabla. Puedes terminar con 6-7 combinaciones de nivel en docenas de consultas que a veces causarán errores porque hay muchas más posibilidades de crear un error en consultas más grandes que en las simples.

Si publica algunos requisitos de lo que está haciendo quizás podamos ayudarlo a diseñar la base de datos correctamente.

Answer 4

odbc tiene un límite de caracteres de 8000 .... por lo que es un límite físico más allá del cual las cosas se vuelven altamente frustrantes.

Trabajé en una mesa que tenía 138 columnas ... estaba horriblemente escrita y podría haber sido normalizada. Aunque esta base de datos parece haber sido creada por alguien que se pregunta por qué hay convenciones en el diseño de bases de datos y decide probarlas todas a la vez.

Tener tablas aplanadas muy anchas es bastante común cuando ingresa al almacenamiento de datos y servidores de informes. Son mucho más rápidos y significan que no tiene que almacenar su base de datos en RAM para el rendimiento.

Answer 5

¿Cuántas columnas hay demasiadas columnas?

Cuando sientas que ya no tiene sentido o no es correcto agregar otra columna.

Generalmente depende de la aplicación.

Answer 6

De acuerdo con mi experiencia, es mejor tener menos combinaciones, ya que tienden a ocurrir con demasiada frecuencia, especialmente en grandes bases de datos. Siempre que las tablas de su base de datos estén diseñadas para almacenar entidades individuales (estudiantes, docentes, etc.), esto debería estar bien. Para que esto se represente como un objeto en tu código más tarde. Por lo tanto, si divide la entidad en varias tablas, deberá usar varias uniones para completar su objeto más adelante. Además, si usa ORM para generar su capa de acceso a datos (como Linq en .Net) generará clases separadas para cada tabla (por supuesto, con una relación entre ellas pero igual) y esto será más difícil de usar.

Otra cosa es que puede especificar qué columnas devolver en su consulta y esto reducirá los datos que se pasan a su aplicación, pero si necesita incluso una sola columna de otra tabla, tendrá que hacer la unión. Y en la mayoría de los casos, como tiene tantas columnas, entonces la probabilidad de tener una gran cantidad de datos almacenados en el db es alta. Entonces esta unión dañaría más, que los NULLs.

Cada proyecto en el que he trabajado es diferente, por lo que debe encontrar el saldo para cada historia.

Answer 7

También depende en gran medida del uso de su mesa. Si desea optimizarlo para leer, puede ser una buena idea mantenerlo todo junto en una sola tabla.

En el mundo de NO-SQL (cassandra/hbase, por ejemplo) no hay restricciones en el número de columnas y en realidad se considera una buena práctica tener muchas columnas. Esto también proviene de la forma en que está almacenado (sin espacios). Vale la pena mientras investiga.

Answer 8

Es mejor usar una sola tabla para evitar el uso de combinaciones mientras se consulta, depende de si las columnas son de la misma entidad o entidad diferente.

Por ejemplo, suponga que está haciendo un diseño de base de datos para flujo de trabajo donde algunos campos serán editados por trabajadores subalternos, y algunos campos por trabajadores sénior. En este caso, es mejor tener todas las columnas en una sola tabla.

Answer 9

Tener demasiadas columnas da como resultado muchos nulos (malvados) y un objeto difícil de manejar al que se asigna la tabla. Esto perjudica la legibilidad en el IDE y dificulta el mantenimiento (aumentando los costos de desarrollo). Si necesita lecturas rápidas en algunos casos, use tablas desnormalizadas, p. utilizado únicamente para informes o consultas (busque el patrón "CQRS"). Sí "Persona" tiene un millón de atributos, pero puede desglosar estas tablas monotilicas (el diseño precede la normalización) para unir entidades más pequeñas ("dirección", "teléfono", "afición") en lugar de agregar nuevas columnas para cada caso de uso nuevo. Tener objetos de menor tamaño (y tablas) ofrece tantas ventajas; permiten cosas como pruebas unitarias, OOP y prácticas SÓLIDAS.

Además, en lo que respecta al agrupamiento de numerosas columnas para evitar uniones, creo que la ganancia de rendimiento al evitar uniones se pierde a través del mantenimiento del índice, asumiendo una carga de trabajo típica tanto de lecturas como de escrituras. Agregar índices en los campos por el rendimiento de lectura podría ser indicativo de la necesidad de mover esos campos a su propia tabla.