language agnostic - ¿Cómo se determina hasta qué punto se normaliza una base de datos?
language-agnostic database-design (14)
Al crear una estructura de base de datos, ¿cuáles son las buenas pautas a seguir o las buenas maneras de determinar qué tan lejos debe normalizarse una base de datos? ¿Debería crear una base de datos no normalizada y dividirla a medida que avanza el proyecto? ¿Debería crearlo completamente normalizado y combinar tablas según sea necesario para el rendimiento?
@GrizzlyGuru Un hombre sabio me dijo una vez "normalizar hasta que duela, desnormalizar hasta que funcione".
Todavía no me ha fallado :)
Estoy en desacuerdo sobre comenzar con esto en forma no normalizada, sin embargo, en mi experiencia, ha sido más fácil adaptar su aplicación para tratar con una base de datos menos normalizada que una más normalizada. También podría llevar a situaciones en las que su "funcionamiento" sea lo suficientemente bueno ", por lo que nunca se normalizará (¡hasta que sea demasiado tarde!)
A menudo, si se normaliza en la medida en que su otro software lo permita, habrá terminado.
Por ejemplo, al usar la tecnología de mapeo relacional de objetos, tendrá un rico conjunto de semánticas para varias relaciones de muchos a uno y muchos a muchos. Debajo del capó que proporcionará tablas de unión con efectivamente 2 teclas principales. Aunque es relativamente raro, la verdadera normalización a menudo le proporciona relaciones con 3 o más claves primarias. En casos como este, prefiero seguir con O / R y rodar mi propio código para evitar las diversas anomalías de DB.
Creo que comenzar con una base de datos no normalizada y avanzar hacia la normalización a medida que progresa es generalmente lo más fácil para comenzar. A la pregunta de hasta dónde normalizar, mi filosofía es normalizar hasta que empiece a doler. Eso puede parecer un poco frívolo, pero en general es una buena forma de medir qué tan lejos tomarlo.
Jeff tiene una muy buena visión general de su filosofía en su blog: Tal vez la normalización no es normal . Lo principal es: no exagere la normalización. Pero creo que un punto aún más importante es que probablemente no importe demasiado. A menos que esté ejecutando el próximo Google, probablemente no notará mucha diferencia hasta que su aplicación crezca.
La base de datos normizacional que siento es una forma de arte.
No desea sobre normalizar su base de datos porque tendrá demasiadas tablas y hará que sus consultas de incluso objetos simples tarden más de lo que deberían.
Una buena regla práctica que sigo es normalizar la misma información que se repite una y otra vez.
Por ejemplo, si está creando una aplicación de administración de contactos, tendría sentido tener una dirección (calle, ciudad, estado, código postal, etc.) como su propia tabla.
Sin embargo, si solo tiene 2 tipos de contactos, comerciales o personales, ¿necesita una tabla de tipo de contacto si sabe que solo tendrá 2? Para mí no.
Comenzaría por averiguar los tipos de datos que necesita. Use un programa de modelado para ayudar como Visio. No desea comenzar con una base de datos no normalizada porque eventualmente se normalizará. Comience colocando objetos en las agrupaciones lógicas, ya que los datos repetidos los llevan a una nueva tabla. Me mantendría al día con ese proceso hasta que sienta que tiene la base de datos diseñada.
Deje que las pruebas le digan si necesita combinar tablas. Una consulta bien escrita puede abarcar cualquier sobre la normalización.
Estoy de acuerdo en que generalmente es mejor comenzar con una base de datos normalizada y luego desnormalizar para resolver problemas muy específicos, pero probablemente comenzaría en la forma normal de Boyce-Codd en lugar de la 3ra forma normal.
Tener una base de datos normalizada le dará la mayor flexibilidad y el mantenimiento más fácil. Siempre empiezo con una base de datos normalizada y luego no normalizo solo cuando hay un problema de la vida real que debe abordarse.
Veo esto de manera similar al rendimiento del código, es decir, escribir un código flexible y fácil de mantener y hacer concesiones para el rendimiento cuando sabes que hay un problema de rendimiento.
La verdad es que "depende". Depende de muchos factores, entre ellos:
- Código (codificado a mano o impulsado por herramientas (como paquetes ETL))
- Aplicación principal (Procesamiento de transacciones, Almacenamiento de datos, Informes)
- Tipo de base de datos (MySQL, DB / 2, Oracle, Netezza, etc.)
- Arquitectura de base de datos (Tablular, Columnar)
- Calidad DBA (proactiva, reactiva, inactiva)
- Calidad de datos esperada (¿Desea aplicar la calidad de los datos a nivel de la aplicación o de la base de datos?)
Solo trata de usar el sentido común.
También algunos dicen, y tengo que estar de acuerdo con ellos, que si te encuentras juntando 6 tablas (el número mágico) en la mayoría de tus consultas, sin incluir las relacionadas con los informes, entonces podrías considerar desnormalizar un poco.
Estoy de acuerdo en que debes normalizar tanto como sea posible y solo denormalizar si es absolutamente necesario para el rendimiento. Y con vistas materializadas o esquemas de caché esto a menudo no es necesario.
Lo que hay que tener en cuenta es que al normalizar su modelo, le está dando a la base de datos más información sobre cómo restringir sus datos para que pueda eliminar el riesgo de anomalías de actualización que pueden ocurrir en modelos incompletamente normalizados.
Si se desnormaliza, entonces necesita vivir con el hecho de que puede obtener anomolías de actualización o tiene que implementar la validación de restricciones usted mismo en el código de su aplicación. Esto le quita muchas de las ventajas de usar un DBMS que le permite definir estas restricciones de manera declarativa.
Asumiendo la misma calidad de código, la desnormalización puede no proporcionarle un mejor rendimiento.
Otra cosa para mencionar es que el hardware es barato en estos días, por lo que ofrecer mayor potencia de procesamiento ante el problema suele ser más rentable que aceptar los costos potenciales de la limpieza de datos dañados.
El cartel original nunca describió en qué situación se usará la base de datos. Si va a ser cualquier tipo de proyecto de almacenamiento de datos en el que en algún momento necesitará datos de procesamiento de cubos (OLAP) para algún front-end, sería más prudente comenzar con un esquema en estrella (tablas de hechos + dimensión) en lugar de investigar normalización. Los libros de Kimball serán de gran ayuda en este caso.
No se olvide. La madre de todos los debates de normalización de bases de datos sobre Coding Horror (resumidos en el blog High Scalability).
Desea comenzar a diseñar una base de datos normalizada hasta la 3ra forma normal. A medida que desarrolla la capa de lógica de negocios, puede decidir que tiene que desnormalizar un poco pero nunca, nunca vaya por debajo de la tercera forma. Siempre, mantenga 1ra y 2da forma conforme. Desea desnormalizar por simplicidad de código, no por rendimiento. Use índices y procedimientos almacenados para eso :)
La razón para no "normalizar sobre la marcha" es que tendría que modificar el código que ya ha escrito más cada vez que modifique el diseño de la base de datos.
Hay un par de buenos artículos:
La normalización significa eliminar datos redundantes. En otras palabras, una base de datos no normalizada o desnormalizada es una base de datos donde la misma información se repetirá en múltiples lugares diferentes. Esto significa que debe escribir una declaración de actualización más compleja para asegurarse de actualizar los mismos datos en todas partes; de lo contrario, obtendrá datos incoherentes, lo que a su vez significa que el resultado de las consultas es irrealizable.
Este es un problema bastante grande, entonces diría que la desnormalización duele, y no al revés.
En algunos casos, puede deliberadamente decidir desnormalizar partes específicas de una base de datos, si juzga que el beneficio supera el trabajo adicional en la actualización de datos y el riesgo de corrupción de datos. Por ejemplo, con datawarehouses, donde los datos se agregan por motivos de rendimiento y los datos, si no se actualizan después de la entrada inicial, lo que reduce el riesgo de incoherencias.
Pero, en general, esté cansado de desnormalizar el rendimiento. Por ejemplo, el beneficio de rendimiento de una unión desnormalizada normalmente se puede lograr utilizando la vista materializada (también llamada vista indexada ), que será tan rápida como consultar una tabla desnormalizada, pero aún protege la coherencia de los datos.