mysql - script - ¿Debo normalizar mi base de datos o no?
optimize mysql centos (9)
¿Es "optimizar al último" el enfoque correcto aquí? es decir, crear un DB normalizado según el libro y luego ver qué se puede desnormalizar para lograr la ganancia de velocidad óptima.
Yo diría, sí. He tenido que lidiar con bases de datos mal estructuradas demasiadas veces para aprobar las tablas "planas" sin pensarlo mucho.
En realidad, las inserciones generalmente se comportan bien en los DB totalmente normalizados, por lo que si se trata de inserción pesada, esto no debería ser un factor.
Al diseñar un esquema para un DB (p. Ej., MySQL) surge la pregunta de si normalizar completamente las tablas o no.
Por un lado, las uniones (y las restricciones de clave externa, etc.) son muy lentas y, por otro lado, obtienes datos redundantes y la posibilidad de incoherencia.
¿Es "optimizar al último" el enfoque correcto aquí? es decir, crear un DB normalizado según el libro y luego ver qué se puede desnormalizar para lograr la ganancia de velocidad óptima.
Mi temor, con respecto a este enfoque, es que estableceré un diseño de base de datos que podría no ser lo suficientemente rápido, pero en esa etapa sería muy doloroso refacturar el esquema (al tiempo que respaldaría los datos existentes). Esta es la razón por la cual estoy tentado de olvidarme temporalmente de todo lo que aprendí sobre las prácticas "adecuadas" de RDBMS, y probar el enfoque de "mesa plana" por una vez.
¿Debería el hecho de que este DB sea insertar-pesado afectar la decisión?
¿De dónde sacaste la idea de que "las uniones (y las restricciones de clave externa, etc.) son muy lentas"? Es una afirmación muy vaga, y generalmente IMO no hay problemas de rendimiento.
El enfoque de diseño general para este problema es primero normalizar completamente su base de datos a la 3ra forma normal, luego denormalizar según sea apropiado para el rendimiento y la facilidad de acceso. Este enfoque tiende a ser el más seguro ya que toma una decisión específica por diseño en lugar de no normalizar de forma predeterminada.
Lo ''apropiado'' es el truco que requiere experiencia. La normalización es un procedimiento bastante "memorístico" que se puede enseñar, saber dónde denormalizarse es menos preciso y dependerá del uso de la aplicación y las reglas comerciales, y por lo tanto diferirá de una aplicación a otra. Todas sus decisiones de desnormalización deberían ser defendibles para un compañero profesional.
Por ejemplo, si tengo una relación de una a muchas relaciones, A a BI dejaría esto normalizado en la mayoría de las circunstancias, pero si sé que la empresa solo tiene, digamos, dos apariciones de B para cada A, es muy poco probable que cambie, hay datos limitados en el registro B y normalmente estarán retirando los datos B con el registro A, lo más probable es que amplíe el registro A con dos ocurrencias de los campos B. Por supuesto, la mayoría de los DBA pasados inmediatamente lo señalarán como un posible problema de diseño, por lo que debe poder argumentar convincentemente su justificación para la desnormalización.
De esto debe deducirse que la desnormalización debería ser la excepción. En cualquier base de datos de producción, esperaría que la gran mayoría (95% más) esté en la 3ra forma normal, con solo un puñado de estructuras desnormalizadas.
El patrón de uso de su base de datos (insert-heavy vs. reporting-heavy) definitivamente afectará su normalización. Además, es posible que desee ver su indexación, etc., si observa una desaceleración significativa con tablas normalizadas. ¿Qué versión de MySQL estás usando?
En general, una base de datos con muchas inserciones debería estar más normalizada que una base de datos con gran cantidad de informes. Sin embargo, YMMV por supuesto ...
En una base de datos con muchas entradas, definitivamente comenzaría con tablas normalizadas. Si tiene problemas de rendimiento con las consultas, primero trataría de optimizar la consulta y agregar índices útiles.
Solo si esto no ayuda, debe intentar tablas desnormalizadas. Asegúrese de comparar ambas inserciones y consultas antes y después de la desnormalización, ya que es probable que disminuya la velocidad de sus inserciones.
La desnormalización rara vez se necesita en un sistema operativo. Un sistema para el que hice el modelo de datos tenía 560 tablas o menos (en ese momento era el sistema J2EE más grande construido en Australasia) y solo tenía 4 datos desnormalizados. Dos de los artículos fueron tablas de búsqueda denormalizadas diseñadas para facilitar las pantallas de búsqueda complejas (una era una vista materializada) y las otras dos se agregaron en respuesta a los requisitos de rendimiento específicos.
No optimice prematuramente una base de datos con datos desnormalizados. Esa es una receta para problemas continuos de integridad de datos. Además, siempre use desencadenadores de base de datos para administrar los datos desnormalizados; no confíe en la aplicación, hágalo.
Finalmente, si necesita mejorar el rendimiento de los informes, considere construir un centro de datos u otra estructura denormalizada para los informes. Los informes que combinan los requisitos de una vista en tiempo real de los agregados calculados a través de grandes volúmenes de datos son raros y tienden a ocurrir solo en un puñado de líneas de negocio. Los sistemas que pueden hacer esto tienden a ser bastante complicados de construir y, por lo tanto, son caros.
Es casi seguro que solo dispondrá de un pequeño número de informes que realmente necesitan datos actualizados y casi siempre serán informes operativos, como listas de tareas pendientes o informes de excepción que funcionan con pequeñas cantidades de datos. Cualquier otra cosa se puede enviar a la tienda de datos, por lo que una actualización nocturna probablemente sea suficiente.
No sé qué quiere decir con la creación de una base de datos por libro porque la mayoría de los libros que he leído sobre bases de datos incluyen un tema sobre optimización, que es lo mismo que desnormalizar el diseño de la base de datos.
Es un acto de equilibrio, así que no optimices prematuramente. La razón es que el diseño de base de datos desnormalizado tiende a ser difícil de trabajar. Necesitará algunas métricas, así que haga algunas pruebas de estrés en la base de datos para decidir si desea o no desnormalizarse.
Por lo tanto, se normaliza para la mantenibilidad pero se desnormaliza para la optimización.
Un diseño normal es el lugar para comenzar; hazlo bien, primero, porque tal vez no necesites hacerlo rápido.
La preocupación sobre las uniones costosas a menudo se basa en la experiencia con diseños pobres. A medida que el diseño se vuelve más normal, el número de tablas en el diseño generalmente aumenta, mientras que el número de columnas y filas en cada tabla disminuye, el número de uniones en el diseño aumenta a medida que disminuye el número de uniones, las indicaciones se vuelven más útiles, & c. En otras palabras: suceden cosas buenas.
Y la normalización es solo una forma de terminar con un diseño normal ...
Una respuesta filosófica: las bases de datos subóptimas (relacionales) están plagadas de anomalías de inserción, actualización y eliminación. Todo esto conduce a datos inconsistentes, lo que da como resultado una calidad de datos deficiente. Si no puede confiar en la exactitud de sus datos, ¿de qué sirve? Pregúntate a ti mismo: ¿Quieres que las respuestas correctas sean más lentas o quieres respuestas más rápidas más rápido?
Como una cuestión práctica: hazlo bien antes de llegar rápido. Los humanos somos muy malos para predecir dónde ocurrirán los cuellos de botella. Haga que la base de datos sea excelente, mida el rendimiento durante un período decente, luego decida si necesita hacerlo más rápido. Antes de desnormalizar y sacrificar la precisión, pruebe otras técnicas: ¿puede obtener un servidor, una conexión, un controlador de base de datos, etc. más rápidos? ¿Podrían los procedimientos almacenados acelerar las cosas? ¿Cómo son los índices y sus factores de relleno? Si esas y otras técnicas de rendimiento y ajuste no funcionan, solo entonces considere la desnormalización. Luego mida el rendimiento para verificar que obtuvo el aumento en la velocidad que "pagó". Asegúrese de realizar optimización, no pesimismo.
[editar]
P: Entonces, si optimizo el último, ¿me pueden recomendar una forma razonable de migrar los datos después de que se cambie el esquema? Si, por ejemplo, decido deshacerme de una tabla de búsqueda, ¿cómo puedo migrar los datos existentes a este nuevo diseño?
A: Claro.
- Hacer una copia de seguridad.
- Haga otra copia de seguridad en un dispositivo diferente.
- Cree nuevas tablas con los comandos de tipo "seleccionar en newtable from oldtable ...". Tendrá que hacer algunas combinaciones para combinar tablas previamente distintas.
- Suelta las tablas viejas.
- Renombra las nuevas tablas.
PERO ... considera un enfoque más robusto:
Cree algunas vistas en sus tablas completamente normalizadas ahora mismo. Esas vistas (tablas virtuales, "ventanas" en los datos ... pregúntame si quieres saber más sobre este tema) tendrían la misma consulta de definición que el paso tres anterior. Cuando escribe la aplicación o la lógica de la capa DB, use las vistas (al menos para acceso de lectura; las vistas actualizables son ... bueno, interesantes). Luego, si se desnormaliza más tarde, cree una nueva tabla como la anterior, suelte la vista, cambie el nombre de la nueva tabla base sea cual sea la vista. Su aplicación / DB-layer no sabrá la diferencia.
De hecho, hay más en esto en la práctica, pero esto debería ayudarte a empezar.