¿Debo normalizar mi base de datos o no?

Question

Al diseñar un esquema para un DB (por ejemplo, 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, se obtienen datos redundantes y la posibilidad de incoherencia.

¿Es "optimizar el ú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 (mientras se soportan 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.

En caso de que este DB vaya a tener un efecto de inserción, ¿la decisión?

Answer 1

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]

Q: Así que si puedo optimizar el pasado, se puede recomendar una forma razonable para migrar datos después de que se cambia el esquema?Si, por ejemplo, , decido deshacerme de una tabla de búsqueda , ¿cómo puedo migrar los datos existentes de a este nuevo diseño?

A: Sure.

1. Haga una copia de seguridad.
2. Haga otra copia de seguridad en un dispositivo diferente.
3. Crea nuevas tablas con los comandos de tipo "seleccionar en newtable from oldtable ...". Tendrá que hacer algunas combinaciones para combinar tablas previamente distintas.
4. Suelta las tablas antiguas.
5. Cambie el nombre de las tablas nuevas.

PERO ... considerar un enfoque más sólido:

crear algunos puntos de vista sobre las tablas normalizadas totalmente en este momento. 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.

En realidad, hay más en la práctica, pero esto debería comenzar.

Answer 2

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 inserciones pesadas debería ser más normalizada que una base de datos con gran cantidad de informes. Sin embargo, YMMV por supuesto ...

Answer 3

¿Es "optimizar el ú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 que 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 normalmente se comportan bien en las DB totalmente normalizadas, por lo que si se trata de una inserción pesada, esto no debería ser un factor.

Answer 4

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 corresponda 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 relaciones 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, esto es altamente es 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 se desprende 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.

Answer 5

En una base de datos de inserción pesada, 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 probar las 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.

Answer 6

¿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.

Answer 7

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.

Por último, si necesita mejorar el rendimiento de los informes, considere la posibilidad de crear 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 tenga una pequeña cantidad de informes que realmente necesiten 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.

Answer 8

No sé qué quiere decir con la creación de una base de datos 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 lo optimice 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.

Answer 9

Un diseño normal es el lugar para comenzar; hazlo bien, primero, porque tal vez no necesites hacerlo rápido.

La preocupación por las uniones costosas a menudo se basan en la experiencia con diseños deficientes. 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 ...