¿Cómo puedo argumentar convincentemente contra la duplicación de las columnas de la base de datos?

Su base de datos operacional debe estar altamente normalizada, para reducir anomalías .

Su base de datos analítica (almacén) debe estar altamente desnormalizada, para facilitar el análisis.

Si no tiene una base de datos analítica separada, debe hacer algunas vistas [materializadas] altamente desnormalizadas.

Si le dice a sus analistas / gerentes de negocios senior que hagan muchas uniones para un análisis simple, bien, podría ser despedido.

Diseño ágil de almacenamiento de datos es un buen libro

Consulte las sugerencias de mi almacén de datos rápido y sucio aquí

Entiendo, por qué alguien quiere evitar escribir una combinación para cada seleccionar.

Pero puede crear una vez una vista con la unión y usarla en lugar de su tabla no normalizada.

Así que combina la ventaja de la normalización con la conveniencia de una selección fácil.

Las respuestas que ya han sido actualizadas en gran medida cubren el "cómo evitar la duplicación" (usando vistas) pero no el por qué. Básicamente, muestran que la duplicación de columnas es la solución equivocada al problema de facilitar la escritura de consultas. Pero la pregunta "¿por qué no duplicar cualquier columna aleatoria solo por el gusto de hacerlo?" sigue en pie.

La respuesta es "Debido a la ley de Murphy". La ley de Murphy establece que:

  

Si algo puede salir mal, lo hará.

En este caso, se supone que el contenido de cada campo de fila de una columna duplicada es idéntico al contenido de cada campo de fila correspondiente de la columna original. Lo que puede salir mal, es que el contenido de algunos campos de fila puede diferir de los originales, causando estragos. Podría pensar que ha tomado todas las precauciones posibles para asegurarse de que no difieran, pero la ley de Murphy establece que, dado que pueden diferir, , diferirán. Y el caos se producirá .

Como ejemplo de cómo puede suceder esto, simplemente considere el hecho de que las columnas duplicadas no se llenan con magia; alguien debe escribir un código que almacene valores en ellos cada vez que se creen filas en la tabla original, y alguien debe escribir un código que se actualice cada vez que se modifiquen los originales. Dejando de lado el hecho de que esto agrega una carga indebida al código que ingresa los datos en la base de datos (y que, por definición, es mucho más importante que cualquier código que simplemente consulte la base de datos), alguien, en ciertas circunstancias, podría olvidar Para llevar a cabo esta duplicación. Entonces, los valores serán diferentes. O pueden acordarse de llevar a cabo la duplicación, pero no dentro de una transacción, por lo que puede, bajo ciertas raras condiciones de falla, ser omitido. Pero realmente no necesitaba perder mi tiempo escribiendo estos ejemplos, y realmente no tenía que perder su tiempo leyendo: la belleza de la Ley de Murphy es que nos evita tener que dar con ejemplos de cómo algo puede salir mal. caso por caso: si puede salir mal, lo hará.

Pensar en ello en términos de compensaciones en lugar de buenas / malas será más productivo. Están intercambiando las ventajas de la normalización (especialmente la consistencia) por las ventajas en la facilidad de uso de las consultas.

En un extremo, la base de datos se volvería inútil si los datos fueran muy inconsistentes. En el otro extremo, la base de datos sería inútil si es demasiado difícil para las personas que necesitan consultarla todos los días para obtener resultados con los que puedan contar.

¿Qué puede hacer para reducir los riesgos y los costos?

• Cree una herramienta de comprobación de coherencia y ejecútela regularmente.
• Enrutar el acceso de escritura a través del software que actualiza los datos replicados de manera consistente.
• Agregue vistas o cree herramientas de consulta que hagan las uniones automáticamente para que la gente de negocios pueda pensar en términos de información en lugar de en los datos internos de DB.

Creo que el argumento más sólido para la normalización de datos para los analistas de negocios es que promueve la integridad de los datos. Si sus datos clave se almacenan en un solo lugar (una columna, en una tabla), es mucho menos probable que los datos se dañen por actualizaciones incorrectas. Creo que probablemente les importará la importancia de la integridad de los datos, por lo que esta podría ser una buena manera de convencerlos de que actualicen sus formas de interactuar con la base de datos.

Es probable que un método de consulta un poco más difícil sea preferible a la posible corrupción de datos.

Para agregar a lo que los otros chicos han sugerido anteriormente. Este es un problema de gobernabilidad de datos. Debe trabajar con las partes interesadas relevantes: arquitectos de datos y administradores de datos para desarrollar principios de datos, políticas y convenciones de nombres.

Sea paciente y trabaje metódicamente. El cambio no ocurrirá durante la noche.

Salir.

Honestamente, puedes pasar meses discutiendo sobre la normalización, la coherencia y la lucha contra los bichos locos causados por la pereza y luego renunciar.

O simplemente puede ahorrar tiempo, frustración y dejar de fumar ahora.

Los buenos programadores son personas muy perezosas. Entienden las necesidades del cliente y de la administración. Pero lo más importante es que entienden que resolver problemas bien, usar soluciones bien diseñadas y bien implementadas les ahorra en gran medida ENORME trabajo, esfuerzo y, lo más importante, agonía y estrés.

Por lo tanto, estarías mucho mejor trabajando en un lugar que comprenda y valore la buena ingeniería.

Buena suerte.

Pensamiento posterior: Tal vez lo que necesitan son herramientas de BI / OLAP ... enlace