¿La normalización de la base de datos está muerta? [cerrado]

Fui educado en la vieja escuela, donde aprendimos a diseñar el esquema de la base de datos ANTES de la capa empresarial de la aplicación (o usando OOAD para todo lo demás). He sido bastante bueno diseñando esquemas (en mi humilde opinión :) y normalizado solo para eliminar la redundancia innecesaria, pero no donde afecta la velocidad, es decir, si las uniones fueron un golpe de rendimiento, la redundancia se mantuvo en su lugar. Pero sobre todo no lo fue.

Con la llegada de algunos marcos ORM como ActiveRecord o ActiveJDBC de Ruby (y algunos otros que no recuerdo, pero estoy seguro de que hay muchos) parece que prefieren tener una clave sustituta para cada tabla, incluso si algunos tienen claves principales como 'correo electrónico' - rompiendo 2NF directamente. De acuerdo, no entiendo demasiado, pero me pone de los nervios (casi) cuando algunos de estos ORM (o programadores) no reconocen 1-1 o 1-0 | 1 (es decir, 1 a 0 o 1). Ellos estipulan que es mejor tener todo como una gran mesa, sin importar si tiene un montón de nulls "los sistemas de hoy pueden manejarlo" es el comentario que he escuchado con más frecuencia.

Estoy de acuerdo en que las restricciones de memoria tenían una correlación directa con la normalización (también hay otros beneficios :) pero en la actualidad, con la memoria barata y las máquinas de cuatro núcleos, ¿queda el concepto de normalización de DB solo en los textos? Como DBA, ¿todavía practica la normalización a 3NF (si no es BCNF :)? ¿Importa? ¿El diseño de "esquema sucio" es bueno para los sistemas de producción? ¿Cómo debería uno hacer el caso "para" la normalización si todavía es relevante?

( Nota: no estoy hablando de los esquemas de estrella / copo de nieve de datawarehouse que tienen redundancia como parte / necesidad del diseño, sino sistemas comerciales con una base de datos de fondo como StackExchange, por ejemplo)

Una razón para la normalización es eliminar las anomalías de modificación de datos Los
ORM generalmente no son compatibles con esto.

Tengo muchos ejemplos de bases de datos diseñadas por Hibernate que rompen este principio:

• hinchado (cadena repetida en cientos de millones de filas)
• sin tablas de búsqueda (ver arriba)
• sin DRI (restricciones, claves)
• índices agrupados varchar
• tablas de enlaces innecesarias (por ejemplo, exigir 1..0: 1 cuando una columna FK anulable sería suficiente)

Lo peor que he visto es una base de datos MySQL de 1TB que quizás era 75-80% demasiado grande debido a esto

También sugeriría que la afirmación "los sistemas de hoy pueden manejarlo" es cierta para la mayoría de los sistemas de Mickey Mouse. A medida que escala, los sistemas de hoy no lo harán.

En mi ejemplo anterior, no hubo tracción para refactorizar o cambiar claves o corregir datos: solo se quejan de las tasas de crecimiento de la base de datos y la incapacidad de construir un DW significativo sobre él

parece que prefieren tener una clave sustituta para cada tabla, incluso si algunas tienen claves principales como 'correo electrónico', rompiendo 2NF directamente.

Las claves sustitutas no rompen 2NF. 2NF dice "Si una columna depende solo de una parte de una clave de valores múltiples, elimine esa columna a una tabla separada".

Ellos estipulan que es mejor tener todo como una mesa grande sin importar si tiene un montón de nulos

Tener varias columnas en una tabla es válido siempre que se sigan las reglas de normalización. No es correcto fusionar tablas sin análisis si desea obtener los beneficios de SQL y la normalización.

Estoy de acuerdo en que las restricciones de memoria tenían una correlación directa con la normalización. Relación Formas normales es un concepto matemático y no tiene nada que ver con la memoria.

La normalización está ahí no solo para guardar memoria o disco, está ahí para agregar integridad. Después de todo, es un concepto matemático independiente del hardware.

Ejemplo simple: Digamos que mantiene la información de la escuela como:

Rec 1: North Ridge High School, California, EE. UU.

Rec. 2: South Toronto Braves High School, Ontario, Canadá

Si le pregunta a su sistema dónde está Ontario, puede descubrir que está en Canadá. Pocos días después, eliminas la segunda fila y le haces la misma pregunta al sistema y no obtienes nada. En este ejemplo, no importa cuánto espacio en disco o memoria o CPU, no obtendrá la respuesta.

Esta es una anomalía que las relaciones de normalización ayudan a prevenir.

Editar: Cambié la palabra Toronto a Ontario según el comentario a continuación.

Cuanto más cambian las cosas, más permanecen igual. Siempre ha habido desarrolladores flojos que cortan esquinas o simplemente no saben o no quieren seguir las mejores prácticas. Muchas veces pueden salirse con la suya en aplicaciones más pequeñas.

Solía ​​estar bloqueando estructuras de datos inspiradas en COBOL en los primeros RDBMS, o el horrible desastre que era dBase. Ahora son ORM y "Code-First". Al final, estas son solo formas de personas que intentan encontrar la bala de plata de conseguir un sistema de trabajo sin "perder" el tiempo pensando mucho en lo que quiere y necesita hacer. Tener prisa siempre ha sido un problema y siempre lo será.

Para aquellos que tienen el buen sentido (y la buena suerte) de tomarse el tiempo para diseñar adecuadamente, el modelo de datos siempre será el lugar más lógico para comenzar. Lo que se incluye en la base de datos es información sobre las cosas (tangibles e intangibles) que le interesan a su empresa. Lo que le importa a su empresa cambia mucho menos rápidamente que cómo opera su empresa. Es por eso que su base de datos es generalmente mucho más estable que su código.

La base de datos es la base legítima de cualquier sistema y tomarse el tiempo para sentar sus bases adecuadamente inevitablemente lo beneficiará a largo plazo. Eso significa que la normalización siempre será un paso importante y útil para cualquier aplicación de tipo OLTP.

Estoy de acuerdo en que las restricciones de memoria tenían una correlación directa con la normalización ...

Las restricciones de memoria siguen siendo importantes. La cantidad no es un problema, la velocidad sí.

• Las CPU no se están acelerando en este momento (estamos obteniendo más núcleos, no ciclos por segundo)
• Las arquitecturas modernas de CPU intentan superar la limitación de velocidad al proporcionar memoria separada para cada procesador ( NUMA ).
• Los tamaños de caché en matriz no están creciendo a un ritmo comparable a la memoria principal.
• El rendimiento de la memoria no es tan alto como la mayoría de la gente espera. QPI está en la región de 25 GB / seg.

Parte de este terreno fue cubierto en ¿ Cuándo usar TINYINT sobre INT? lo cual puede ser útil También sugiero seguir las travesuras de @ThomasKejser ( blog ) del equipo SQLCAT, ya que tienden a estar a la vanguardia de impulsar el rendimiento de la base de datos. La publicación reciente sobre El efecto de los cachés de la CPU y los patrones de acceso a la memoria y la presentación de SQLBits sobre modelado relacional para la escala extrema DW son buenos ejemplos.

En mi opinión, todavía se trata del equilibrio entre normalizar y desnormalizar . Estoy totalmente de acuerdo en que los marcos ORM son simplemente enfoques para hacer las cosas, pero no creo que sean estos marcos los que causen la tendencia a la normalización .

Todavía es ese debate que desea eficiencia en el tiempo o desea eficiencia en el espacio. En el momento en que surge la teoría de la base de datos relacional, el almacenamiento en disco es costoso, la gente obviamente no quiere gastar tanto dinero en esto, es por eso que en ese momento las bases de datos relacionales son las que se mantienen firmes en medio de las adversidades

Hoy en día las cosas son bastante diferentes, el almacenamiento es muy, muy barato. Entonces, obviamente, podemos tolerar más redundancia en comparación con los viejos tiempos, esto también es POR QUÉ apareció el enfoque BIG_TABLE. Para buscar una mayor eficiencia en el tiempo, se debe sacrificar la eficiencia en el espacio.

Pero, el enfoque de la gran mesa tampoco es el final de la historia, sigue siendo el equilibrio entre el tiempo y el espacio, en términos de datos de volumen PB para administrar, algunos desarrolladores también comenzaron a buscar el equilibrio de nuevo en la eficiencia espacial, es por eso que son trabajos realizados para normalizar algunos datos en BIG-TABLE como estructuras.

En una palabra, el enfoque de normalización no está definitivamente muerto, pero en comparación con los viejos tiempos, definitivamente se pasa por alto.

CJ Date responde a su pregunta aquí: el video de normalización (preliminar) es gratuito.

http://shop.oreilly.com/product/0636920025900.do

La respuesta corta: la normalización es la forma matemáticamente correcta de hacer las cosas. Si no se normaliza correctamente, su modelo de datos es simplemente incorrecto.