¿Cuántas columnas es demasiadas columnas? [cerrado]

Question

Me he dado cuenta de que mucha gente aquí citar tablas con 20+ (he visto tanto como 55) columnas de una tabla. Ahora bien, no pretendo ser un experto en diseño de base de datos, pero siempre he oído que esta es una práctica horrible. Cuando veo esto, lo general sugieren dividir en dos tablas con una relación uno a uno: uno que contiene los datos de uso más frecuente, el otro con los datos menos frecuente. Aunque, al mismo tiempo, está el posible problema de rendimiento (menos JOINs y tal). Así que mi pregunta es la siguiente:

Cuando se trata de bases de datos muy gran escala, ¿existe en realidad una ventaja de tener una gran cantidad de columnas, a pesar de que esto generalmente conduce a valores de muchos NULL?

Lo que 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

Answer 1

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

En tanto que la tabla es normalizado , no hay una regla de oro en cuanto a tamaño, aparte de las capacidades de base de datos y la necesidad de optimizar.

Answer 2

Estoy de acuerdo con Oded. He visto mesas con 500 columnas en ellos, y todas las columnas de ellos estaban en el lugar correcto. Basta con contemplar el número de hechos uno podría almacenar alrededor de un objeto cotidiano, y pronto veremos por qué.

Si resulta inconveniente para seleccionar todas las columnas, o para especificar las columnas para seleccionar cuando usted está interesado sólo en una pequeña proporción de ellos, es posible que valga la pena para definir una vista.

Answer 3

¿Cuántas columnas son demasiadas columnas?

Cuando sienta que ya no tiene sentido o es derecho de agregar otra columna.

generalmente depende de la aplicación.

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 ponen muy frustrante.

Yo trabajaba en una mesa que tenía 138 columnas .. fue horriblemente escrito y podría haber sido normalizado. Aunque esta base de datos parecen del sido la creación de que alguien se pregunte por qué hay convenciones en el diseño de base de datos y decidir poner a prueba todos a la vez.

Tener muy amplia aplanado tablas es bastante común cuando usted entra en el almacenamiento de datos y elaboración de informes servidores. Son sólo un montón más rápido y media que no tiene que almacenar su entirley base de datos en la memoria RAM para el rendimiento.

Answer 5

De acuerdo con mi experiencia, es mejor tener menos se une como aquellos que tienden a ocurrir con demasiada frecuencia, especialmente en las grandes bases de datos. Mientras sus tablas de bases de datos están diseñados para almacenar una sola entidad (estudiante, profesor, etc.) esto debe estar bien. Para que esto se representa como un objeto en el que el código más tarde. Por lo tanto, si se divide la entidad a varias tablas que tendrá que utilizar varios une con el fin de llenar su objeto más tarde. Además, si utiliza ORM para generar su capa de acceso a datos (como LINQ en .Net) es generará clases separadas para cada tabla (por supuesto, con una relación entre ellos, pero todavía) y esto será más difícil de usar.

Otra cosa es que se puede especificar qué columnas para volver en su consulta y esto reducirá los datos que se pasan a su aplicación, pero si es necesario, incluso una sola columna de otra tabla que tendrá que hacer la unión. Y en la mayoría de los casos cuando usted tiene tantas columnas, entonces la probabilidad de tener gran cantidad de datos almacenados en la base de datos es alta. Así que esto perjudicaría a unirse más, que los nulos.

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

Answer 6

Tener demasiadas columnas resultados en un montón nulos (mal) y un objeto difícil de manejar la tabla se asigna a. Esto perjudica la legibilidad en el IDE y dificulta el mantenimiento (el aumento de los costes de desarrollo). Si necesita lee rápido en algunos casos, por ejemplo, utilizar tablas desnormalizados exclusivo para reportar o consultas (buscar el patrón "CQRS"). Sí "persona" tiene un millón de atributos, pero se puede romper estas tablas monothilic (precede diseño de normalización) para que coincida con las entidades más pequeñas ( "dirección", "teléfono", "manía") en lugar de añadir nuevas columnas para cada nuevo caso de uso. Tener objetos de tamaño más pequeño (y tablas) aporta muchas ventajas; que permiten cosas como las pruebas unitarias, programación orientada a objetos y prácticas sólidas.

Además, por cuanto concierne al agrupamiento numerosas columnas para evitar uniones, creo que la ganancia de rendimiento de evitar une se pierde por el mantenimiento de índices, asumiendo una carga de trabajo típica de lecturas y escrituras. La adición de índices en campos para bien de rendimiento de lectura podría ser indicativo de la necesidad de mover los campos en su propia mesa.

Answer 7

Lo que es más de un impacto en el rendimiento: un montón de columnas con una gran cantidad de valores nulos, o un menor número de columnas con una gran cantidad de combinaciones?

Es puramente depende de los datos que almacena, índices que realice y así sucesivamente. No se puede asegurar que uno que funciona mejor que otro sin saber qué estás almacenando. En general, las reglas de normalización se "fuerza" que separar los datos a diferentes mesas y fkeys usuario si tiene una mesa grande, pero no estoy de acuerdo de que siempre se comporta mejor que una mesa grande. Puede terminar con 6-7 nivel se une a docenas de preguntas que a veces provocará errores porque hay muchas más posibilidades para crear un error en las consultas de mayor tamaño que en los simples.

Si después de algunos requisitos de lo que está haciendo lo mejor que puede ayudar con el diseño de la base de datos correctamente.

Answer 8

También depende en gran medida del caso de uso para su mesa. Si desea optimizarlo para leer a continuación, podría ser una buena idea para mantener todo junto en una tabla.

En el mundo NO-SQL (Cassandra / hbase por ejemplo) no hay restricciones sobre el número de columnas y de hecho es considerado una buena práctica tener muchas columnas. Esto también proviene de la forma en que se almacena (sin espacios). Vale la pena investigar.

Answer 9

What business need requires more than 60 columns in any data set, let alone a TSQL Table? If there is such a business need, then a Pivot is in order, and the columns should be rows. For example, in the Mining industry, there may be 600 different measurements taken in an assay. The name of each measurement could be a column name. But why create a table with 600 columns and rows of measurements? A geologist would measure the mine each day, perhaps, and fill in the log of 600 columns on one row. That sounds to me like the geologist will lose his mind, and he won't find a sheet of paper long enough. Perhaps a roll would work, but then he would have to unroll the roll and roll it back up again.

Answer 10

It's better to use a single table by where you can avoid using joins while querying it depends on whether the columns are of same entity or different entity.

For example, assume you are doing a database design for work flow where some fields will be edited by junior workers, and some fields by senior workers. In this case it is better to have all the columns in a single table.