tutorial - MySQL: ¿múltiples tablas o una tabla con muchas columnas?
mysql workbench tutorial (8)
Cada vez que la información es uno a uno (cada usuario tiene un nombre y una contraseña), entonces es mejor tener una sola tabla, ya que reduce el número de combinaciones que la base de datos deberá 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 hace que la base de datos sea más difícil de mantener )
Puede encontrar el artículo de Wikipedia sobre la normalización de la base de datos interesante, ya que analiza los motivos de esto en profundidad:
La normalización de la base de datos es el proceso de organizar 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, ya que hay casos en los que la repetición de datos es mejor (ya que reduce la cantidad de trabajo que la base de datos debe hacer al leer 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.
Entonces, 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 como 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, ¿qué enfoque es mejor y cuáles son los pros y los contras? ¿Cuál es la forma convencional de hacerlo?
Creo que tener una sola tabla es más efectivo, pero debes asegurarte de que la tabla esté organizada de manera que muestre la relación, la tendencia y la diferencia en las variables de la misma fila. por ejemplo, si la tabla muestra la edad y las calificaciones de los estudiantes, debe ordenar la tabla de manera tal que las calificaciones más altas se diferencien del más bajo y la diferencia en la edad de los estudiantes sea pareja.
La forma convencional de hacerlo sería usar tablas diferentes 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.
Me encontré con esto, y como alguien que solía usar MySQL mucho, y luego se cambió a Postgres recientemente, una de las grandes ventajas es que puede agregar objetos JSON a un campo en Postgres.
Entonces, si se encuentra en esta situación, no tiene que elegir necesariamente entre una tabla grande con muchas columnas y dividirla, pero puede fusionar columnas en objetos JSON para reducirla, por ejemplo, en lugar de que la dirección sea de 5 columnas, puede simplemente ser uno. También puede consultar sobre ese objeto.
Tengo un buen ejemplo. Base de datos excesivamente normalizada con el siguiente conjunto de relaciones:
people -> rel_p2staff -> staff
y
people -> rel_p2prosp -> prospects
Donde las personas tienen nombres y detalles de personas, el personal solo tiene los datos del registro del personal, los prospectos solo tienen detalles de prospectos, y las tablas rel son tablas de relaciones con claves externas de personas vinculadas al personal y prospectos.
Este tipo de diseño continúa para toda la base de datos.
Ahora, para consultar este conjunto de relaciones, se trata de una combinación de múltiples tablas en todo momento, 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 que cuelgan poco se habían utilizado el año pasado, todas las consultas se optimizan 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 con las people -> staff y people -> prospect
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.
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 registros para un sistema simple ... bueno esta es solo mi opinión ... espero que pueda ayudar ... solo hazlo ... puedes hacerlo ... :)
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 sí, lo más probable es que quiera tener tablas secundarias con relaciones de clave externa.
Las ventajas de las tablas padre / hijo son la integridad de los datos, el rendimiento a través de índices (sí, también puede hacerlo en una tabla plana) y la OMI más fácil de mantener si necesita agregar un campo más adelante, especialmente si será un campo obligatorio.
El diseño de contras es más difícil, las consultas se vuelven un poco más complejas
Sin embargo, hay muchos casos en los que una mesa grande y plana será adecuada, por lo que debe tener en cuenta su situación para decidir.