MySQL: varias tablas o una tabla con muchas columnas?

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

Cuando las tablas obtienen demasiadas columnas, puede encontrarse con problemas con el tamaño real de la página en la que la base de datos almacena la información. El registro puede llegar a ser demasiado grande para la página, en la que usted puede no ser capaz de crear o actualizar un registro específico que hace que los usuarios no estén contentos o puede que (al menos en SQL Server) se le permita algún desbordamiento para tipos de datos particulares (con un conjunto de reglas que debe buscar si está haciendo esto), pero si muchos registros desbordarán el tamaño de la página, puede crear tremendos problemas de rendimiento. Ahora, cómo MYSQL maneja las páginas y si tiene un problema cuando el tamaño potencial de la página se vuelve demasiado grande es algo que tendría que buscar en la documentación de esa base de datos.

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

Pros de padre / hijo tablas es la integridad de los datos, el rendimiento a través de índices (sí, puede hacerlo en una tabla plana también) e IMO más fácil de mantener si necesita agregar un campo más tarde, especialmente si será un campo obligatorio.

Cons El diseño es más difícil, las consultas se vuelven un poco más complejas

Pero, hay muchos casos en los que una mesa plana grande será apropiada, por lo que debe mirar su situación para decidir.

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 people tiene nombres y detalles de personas, staff solo tiene los detalles del registro de staff, prospects solo tiene detalles de prospects, y las tablas rel son tablas de relación con claves foráneas de people que se vinculan con staff y prospects.

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

Ahora para consultar este conjunto de relaciones es una combinación multi-tabla cada vez, a veces se unen 8 y más mesas. Ha estado funcionando bien hasta mediados de este año, cuando comenzó a ser muy lento ahora que pasamos 40000 registros de personas.

La indexación y todas las frutas bajas se habían agotado el año pasado, todas las consultas están optimizadas a la perfección. Este es el final del camino para el diseño normalizado particular y la gestión ahora aprobó una 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 es tener una relación directa para people -> staff y people -> prospect

Se encontró con esto, y como alguien que solía usar MySQL mucho, y luego cambió a Postgres recientemente, una de las grandes ventajas es que puede agregar objetos JSON a un campo en Postgres.

Así que si se encuentra en esta situación, no tiene que decidir necesariamente entre una tabla grande con muchas columnas y dividirla, pero puede combinar columnas en objetos JSON para reducirla, por ejemplo, en lugar de que la dirección sea 5 columnas, puede ser solo una. También puede consultar en ese objeto también.

Ya he terminado de hacer algún tipo de diseño de base de datos. para mí, depende de la dificultad del sistema con la gestión de bases de datos; sí, es cierto tener datos únicos en un solo lugar, pero es realmente difícil hacer consultas con una base de datos excesivamente normalizada con muchos registros. Solo tienes que combinar los dos esquemas; utilizar una tabla enorme si usted siente que usted va a tener un enorme registros que son difíciles de mantener al igual que facebook,gmail, etc. y utilizar una tabla diferente para un conjunto de registro para simple sistema... bueno, esta es solo mi opinión .. espero que pueda ayudar.. Tan sólo hazlo..puedes hacerlo... :)

La forma convencional de hacer esto sería usar tablas diferentes como en un esquema de estrella o esquema de copo de nieve. Howeevr, basaría esta estrategia en dos. Creo en la teoría de que los datos solo deben existir en un lugar, allí para el esquema que he mencionado funcionaría bien. Sin embargo, también creo que para los motores de informes y suites de BI, un enfoque columnar sería enormemente beneficioso porque es más compatible con las necesidades de informes. Enfoques columnares como aquellos con infobright.org tienen enormes ganancias de rendimiento y compresión que hace que el uso de 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 toda la gama de sus necesidades. Muchas empresas están implementando tanto el concepto de tener más de una arquitectura de base de datos.

Creo que tener una sola tabla es más efectivo,pero debe asegurarse 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 cambiar la tabla de una manera que agradezca que el puntaje más alto esté bien diferenciado con el puntaje más bajo y la diferencia en la edad de los estudiantes sea uniforme.