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)
fuente
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.
fuente
Las restricciones de memoria siguen siendo importantes. La cantidad no es un problema, la velocidad sí.
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.
fuente
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.
fuente
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.
fuente