MySQL: ¿varias tablas o una tabla con muchas columnas?

Question

Esto es más una cuestión de diseño. Tengo una clave principal que dice la identificación del usuario, y tengo toneladas de información asociada con ese usuario. Estoy preocupado si tengo varias tablas divididas en categorías según la información o si tengo una sola tabla con muchas columnas.

La forma en que solía hacerlo era tener varias tablas, por ejemplo una tabla para datos de uso de aplicaciones, una tabla para información de perfil, una tabla para tokens back-end y etc. para mantener las cosas organizadas. Recientemente, alguien me dijo que es mejor no hacerlo y tener una mesa con muchas columnas está bien. El caso es que todas esas columnas tienen la misma clave principal.

Soy bastante nuevo en el diseño de bases de datos, por lo tanto, ¿qué enfoque es mejor y cuáles son los pros y contras? ¿Cuál es la forma convencional de hacerlo?

Answer 1

Cualquier información de tiempo es individual (cada usuario tiene un nombre y una contraseña), entonces es mejor tener una tabla, ya que reduce la cantidad de uniones que la base de datos tendrá que hacer para recuperar los resultados. Creo que algunas bases de datos tienen un límite en el número de columnas por tabla, pero no me preocuparía en casos normales, y siempre puedes dividirlo más adelante si es necesario.

Si los datos son uno a muchos (cada usuario tiene miles de filas de información de uso), debe dividirse en tablas separadas para reducir los datos duplicados (los datos duplicados desperdician espacio de almacenamiento, espacio en caché y base de datos más difícil de mantener).

Es posible encontrar el artículo de Wikipedia sobre database normalization interesante, ya que analiza las razones de esto en profundidad:

normalización de base de datos es el proceso de organización de los campos y las tablas de una base de datos relacional para minimizar la redundancia y la dependencia . La normalización generalmente implica dividir tablas grandes en tablas más pequeñas (y menos redundantes) y definir relaciones entre ellas. El objetivo es aislar los datos para que las adiciones, eliminaciones y modificaciones de un campo se puedan realizar en una sola tabla y luego se propaguen a través del resto de la base de datos a través de las relaciones definidas.

Denormalization también es algo a tener en cuenta, porque hay casos en los que la repetición de los datos es mejor (ya que reduce la cantidad de trabajo la base de datos tiene que hacer al leer los datos). Recomiendo que tus datos estén lo más normalizados posible para empezar, y solo denormalizar si tienes conocimiento de problemas de rendimiento en consultas específicas.

Answer 2

La forma convencional de hacer esto sería usar diferentes tablas como en un esquema de estrella o un esquema de copo de nieve. Sin embargo, basaría esta estrategia para ser doble. Creo en la teoría de que los datos solo deberían existir en un lugar, allí el esquema que mencioné funcionaría bien. Sin embargo, también creo que para los motores de informes y las suites de BI, un enfoque columnar sería enormemente beneficioso, ya que es más compatible con las necesidades de informes. Los enfoques columnares como aquellos con infobright.org tienen enormes ganancias de rendimiento y compresión que hacen que usar ambos enfoques sea increíblemente útil. Muchas empresas están empezando a darse cuenta de que tener una sola arquitectura de base de datos en la organización no es compatible con la gama completa de sus necesidades. Muchas empresas están implementando tanto el concepto de tener más de una arquitectura de base de datos.

Answer 3

hágase estas preguntas si coloca todo en una tabla, ¿tendrá varias filas para ese usuario? Si tiene que actualizar un usuario, ¿desea mantener un registro de auditoría? ¿Puede el usuario tener más de una instancia de un elemento de datos? (como el número de teléfono, por ejemplo) ¿tendrá un caso en el que desee agregar un elemento o conjunto de elementos más adelante? si responde afirmativamente, lo más probable es que desee tener tablas secundarias con relaciones de clave externa.

Pros de tablas padre/hijo es integridad de datos, rendimiento a través de índices (sí, puede hacerlo en una tabla plana también) y OMI más fácil de mantener si necesita agregar un campo más adelante, especialmente si será un requisito campo.

Contras diseño es más difícil, las consultas se convierten en algo más complejo

Sin embargo, hay muchos casos en que una mesa plana grande será apropiada por lo que tiene que mirar a su situación para decidir.

Answer 4

Una gran mesa es a menudo una mala elección. Las tablas relacionadas son con las que se diseñó la base de datos relacional para trabajar. Si indexa correctamente y sabe cómo escribir consultas de rendimiento, van a funcionar bien.

Cuando las tablas obtienen demasiadas columnas, puede tener problemas con el tamaño real de la página en la que la base de datos está almacenando la información. O bien el registro puede llegar a ser demasiado grande para la página, en el que puede terminar no pudiendo crear o actualizar un registro específico que hace que los usuarios no estén contentos o puede (en SQL Server por lo menos) tener algún desbordamiento para un determinado tipos de datos (con un conjunto de reglas que debe buscar si lo hace), pero si muchos registros desbordan el tamaño de la página, puede crear tremendos problemas de rendimiento. Ahora, cómo maneja MYSQL las páginas y si tiene un problema cuando el tamaño de la página potencial es demasiado grande es algo que debería buscar en la documentación de esa base de datos.

Answer 5

Ya he terminado haciendo algún tipo de diseño de base de datos. para mí, depende de la dificultad del sistema con la administración de la base de datos; sí, es cierto tener datos únicos en un solo lugar, pero es realmente difícil hacer consultas con una base de datos demasiado normalizada con muchos registros. Simplemente combine los dos esquemas; use una mesa enorme si siente que va a tener registros masivos que son difíciles de mantener como Facebook, Gmail, etc. y use una tabla diferente para un conjunto de registro para el sistema simple ... bueno esta es solo mi opinión ... espero que pueda ayudar ... solo hazlo ... puedes hacerlo ... :)

Answer 6

Tengo Un buen ejemplo. la base de datos excesivamente normalizada con el siguiente conjunto de relaciones:

people -> rel_p2staff -> staff 

y

people -> rel_p2prosp -> prospects 

Donde la gente tiene nombres y personas detalles, el personal tiene sólo los detalles del registro personal, las perspectivas tiene sólo detalles perspectivas, y el rel las tablas son tablas de relaciones con claves externas de personas vinculadas al personal y prospectos.

Este tipo de diseño continúa en toda la base de datos.

Ahora, para consultar este conjunto de relaciones, se trata de una combinación de múltiples tablas cada vez, a veces 8 y más combinaciones de tablas. Ha funcionado bien hasta mediados de este año, cuando comenzó a ser muy lento ahora que superamos los 40000 registros de personas.

La indexación y todas las frutas de bajo colgado se habían agotado el año pasado, todas las consultas se optimizaron a la perfección. Este es el final del camino para el diseño y la gestión normalizados en particular. Ahora se ha aprobado la reconstrucción de toda la aplicación que depende de ella, así como la reestructuración de la base de datos, en un plazo de 6 meses. $$$$ Ouch.

La solución será tener una relación directa para people -> staff y people -> prospect

Answer 7

Creo que tener una sola tabla es más eficaz, pero debe asegurarse de que la tabla está organizada de manera que muestra la relación, tendencia así como la diferencia en variables de la misma fila. por ejemplo, si la tabla muestra la edad y las calificaciones de los estudiantes, debe organizar la tabla de manera que se agradezca que el máximo anotador esté bien diferenciado con el anotador más bajo y que la diferencia en la edad de los estudiantes sea pareja.