sql >> Base de Datos >  >> RDS >> Mysql

tabla fija única con varias columnas frente a tablas abstractas flexibles

Determinados problemas deben aclararse y resolverse antes podemos entrar en una discusión razonable.

Resolución de requisitos previos

  1. Etiquetas
    En una profesión que exige precisión, es importante que usemos etiquetas precisas, para evitar confusiones y para que podamos comunicarnos sin tener que usar descripciones y calificativos prolijos.

    Lo que ha publicado como tablas fijas es no normalizado . Bastante justo, puede ser un intento de la tercera forma normal, pero de hecho es un archivo plano, no normalizado (no "desnormalizado). Lo que ha publicado como AbstractTables es, para ser precisos, Entity-Attribute-Value , que es casi, pero no del todo, la sexta forma normal y, por lo tanto, está más normalizada que 3NF. Suponiendo que se haga correctamente, por supuesto.

    • El archivo sin formato no normalizado no está "desnormalizado". Está repleto de duplicaciones (no se ha hecho nada para eliminar los grupos repetidos y las columnas duplicadas o para resolver las dependencias) y Nulls, es un acaparador de rendimiento de muchas maneras y evita la concurrencia.

    • Para ser Desnormalizado, primero tiene que ser Normalizado, y luego la Normalización retrocedió un poco por alguna buena razón. Dado que no está Normalizado en primer lugar, no puede desnormalizarse. Simplemente no está normalizado.

    • No se puede decir que esté desnormalizado "para el rendimiento", porque al ser un acaparador de rendimiento, es la antítesis misma del rendimiento. Bueno, necesitan una justificación por la falta de un diseño formalizado], y eso es "por desempeño". Incluso el escrutinio formal más pequeño expuso la tergiversación (pero muy pocas personas pueden proporcionarla, por lo que permanece oculta, hasta que logran que un tercero aborde, lo adivinó, el enorme problema de rendimiento).

    • Las estructuras normalizadas funcionan mucho mejor que las estructuras no normalizadas. Las estructuras más normalizadas (EAV/6NF) funcionan mejor que las estructuras menos normalizadas (3NF/5NF).

    • Estoy de acuerdo con la idea central de OMG Ponies, pero no con sus etiquetas y definiciones

    • en lugar de decir 'no "desnormalices" a menos que tengas que hacerlo' , estoy diciendo, 'Normalizar fielmente, punto' y 'si hay un problema de rendimiento, no se ha normalizado correctamente' .

  2. Wikipedia
    Las entradas para Formas normales y Normalización ofrecen definiciones que son incorrectas; confunden las Formas Normales; faltan respecto al proceso de Normalización; y dan el mismo peso a los NF absurdos o cuestionables que han sido desacreditados hace mucho tiempo. El resultado es que Wikipedia se suma a un tema ya confuso y rara vez entendido. Así que no pierdas tu tiempo.

    Sin embargo, para poder avanzar, sin que esa referencia suponga un obstáculo, permítanme decir esto.

    • La definición de 3NF es estable y no ha cambiado.
    • Hay mucha confusión de los NF entre 3NF y 5NF. La verdad es que esta es un área que progresó en los últimos 15 años; y muchas organizaciones, académicos y proveedores con sus productos con limitaciones, saltaron para crear un nuevo "Formulario normal" para validar sus ofertas. Todos al servicio de intereses comerciales y académicamente poco sólidos. 3NF en su estado original sin alteraciones pretendía y garantizaba ciertos atributos.
    • La suma total es, 5NF es hoy, lo que se pretendía que fuera 3NF hace 15 años, y puede omitir las bromas comerciales y las doce o más NF "especiales" (comerciales y pseudoacadémicas) intermedias, algunas de los cuales están identificados en Wikipedia, e incluso eso en términos confusos.

  3. Quinta Forma Normal
    Puesto que ha podido comprender e implementar el EAV en su publicación, no tendrá problemas para comprender lo siguiente. Por supuesto, un verdadero modelo relacional es un requisito previo, claves sólidas, etc. La quinta forma normal es, ya que nos estamos saltando la cuarta:

    • Tercera forma normal
      • que en términos simples y definitivos es, cada columna que no es clave en cada tabla tiene una relación 1::1 con la clave principal de la tabla,
      • y a ninguna otra columna que no sea clave
    • Cero duplicación de datos (el resultado, si la Normalización avanza diligentemente; no se logra solo con inteligencia o experiencia, o trabajando para lograrlo como una meta sin el proceso formal)
    • sin anomalías de actualización (cuando actualiza una columna en algún lugar, no tiene que actualizar la misma columna ubicada en otro lugar; la columna existe en un solo lugar).
    • Si comprende lo anterior, 4NF, BCNF y todos los "NF" tontos pueden descartarse, son necesarios para los sistemas de archivo de registros físicos, tal como lo promueven los académicos, bastante ajenos al modelo relacional (Codd).

  4. Sexta Forma Normal

    • El propósito es eliminación de datos faltantes (columnas de atributos), también conocida como eliminación de nulos
    • Esta es la única solución verdadera al problema nulo (también llamado Manejo de valores perdidos), y el resultado es una base de datos sin valores nulos. (Se puede hacer en 5NF con estándares y sustitutos nulos, pero eso no es óptimo). Cómo interpreta y muestra los valores faltantes es otra historia.
    • Técnicamente, no es una verdadera Forma Normal, porque no tiene 5FN como requisito previo, pero tiene un valor

  5. EAV vs Sexta Forma Normal
    Todas las bases de datos que he escrito, excepto una, son 5NF puras. He trabajado (administrado, reparado, mejorado) con un par de bases de datos EAV y he implementado muchas bases de datos 6NF verdaderas. EAV es una implementación suelta de 6NF, a menudo realizada por personas que no tienen un buen conocimiento de la normalización y las NF, pero que pueden ver el valor y necesitan la flexibilidad de EAV. Eres un ejemplo perfecto.

    La diferencia es esta:debido a que es flexible, y debido a que los implementadores no tienen una referencia (6NF) a la que ser fieles, solo implementan lo que necesitan y lo escriben todo en código; eso termina siendo un modelo inconsistente.

    Mientras que una implementación pura de 6NF tiene un punto de referencia académico puro y, por lo tanto, suele ser más estricta y consistente. Normalmente, esto aparece en dos elementos visibles:

    • 6NF tiene un catálogo para contener metadatos, y todo está definido en metadatos, no en código. EAV no tiene uno, todo está en código (los implementadores realizan un seguimiento de los objetos y atributos). Obviamente, un catálogo facilita la adición de columnas, la navegación y permite formar utilidades.
    • 6NF cuando se entiende, proporciona la verdadera solución al problema nulo. Los implementadores de EAV, dado que están ausentes del contexto 6NF, manejan los datos faltantes en el código, de manera inconsistente o, lo que es peor, permiten valores nulos en la base de datos. Los implementadores de 6NF no permiten nulos y manejan los datos faltantes de manera consistente y elegante, sin requerir construcciones de código (para el manejo de nulos; todavía tiene que codificar los datos faltantes, por supuesto).

P.ej. Para las bases de datos 6NF con un catálogo, tengo un conjunto de procesos que [re]generarán el SQL necesario para realizar todas las SELECCIONES, y proporciono Vistas en 5NF para todos los usuarios, por lo que no necesitan conocer o comprender la estructura subyacente de 6NF . Se eliminan del catálogo. Por lo tanto, los cambios son fáciles y automatizados. Los tipos de EAV lo hacen manualmente, debido a la ausencia del catálogo.

Discusión

Ahora, podemos comenzar la discusión.

"Por supuesto que puede ser más abstracto si los valores están predefinidos (Ejemplo:las especialidades podrían tener su propia lista)"

Por supuesto. Pero no te pongas demasiado "abstracto". Mantenga la coherencia e implemente dichas listas de la misma manera EAV (o 6NF) que otras listas.

"Si tomo el enfoque abstracto, puede ser muy flexible, pero las consultas serán más complejas con muchas uniones. Pero no sé si esto afecta el rendimiento, ejecutando estas consultas 'más complejas'".

  1. Las uniones son peatonales en las bases de datos relacionales. El problema no es la base de datos, el problema es que SQL es engorroso al manejar uniones, especialmente claves compuestas.

  2. Las bases de datos EAV y 6NF tienen más Joins, que son tan comunes, ni más ni menos. Si tiene que codificar cada SELECT manualmente, claro, lo engorroso se vuelve realmente engorroso.

  3. Todo el problema puede eliminarse (a) yendo con 6NF sobre EAV y (b) implementando un catálogo, desde el cual puede (c) generar todo el SQL básico. También elimina toda una clase de errores.

  4. Es un mito común que las uniones de alguna manera tienen un costo. Totalmente falso.

    • La unión se implementa en el momento de la compilación, no hay nada de sustancia para 'costear' los ciclos de CPU.
    • El problema es el tamaño de las tablas que se están uniendo, no el costo de la unión entre esas mismas tablas.
    • Unir dos tablas con millones de filas cada una, en una relación PK⇢FK correcta, cada una de las cuales tiene los índices apropiados
      (Único en el lado principal [PK]; Único en el lado secundario [PK=parent FK + algo]
      es instantáneo
    • Cuando el índice secundario no es único, pero al menos las columnas iniciales son válidas, es más lento; donde no hay un índice útil, por supuesto que es muy lento.
    • Nada de esto tiene que ver con el costo de unirse.
    • Donde se devuelven muchas filas, el cuello de botella será la red y el diseño del disco; no el procesamiento de unión.

  5. Por lo tanto, puede obtener la "complejidad" que desee, no hay costo, SQL puede manejarlo.

Me interesaría saber cuáles son las ventajas y desventajas de ambos métodos. Puedo imaginármelo, pero no tengo la experiencia para confirmarlo.

  1. 5NF (o 3NF para aquellos que no han hecho la progresión) es el más fácil y mejor, en términos de implementación; facilidad de uso (tanto desarrolladores como usuarios); y mantenimiento.

    • El inconveniente es que, cada vez que agrega una columna, debe cambiar la estructura de la base de datos (tabla DDL). Eso está bien en algunos casos, pero no en la mayoría de los casos, debido al control de cambios en el lugar, bastante oneroso.
    • Segundo, debe cambiar el código existente (el código que maneja la nueva columna no cuenta, porque es un imperativo):donde se implementan buenos estándares, eso se minimiza; donde están ausentes, el alcance es impredecible.

  2. EAV (que es lo que ha publicado), permite agregar columnas sin cambios de DDL. Esa es la única razón por la que la gente lo elige. (el código que maneja la nueva columna no cuenta, porque es un imperativo). Si se implementa bien, no afectará el código existente; si no, lo hará.

  3. Pero necesita desarrolladores compatibles con EAV.

    • Cuando EAV se implementa mal, es abominable, un desastre peor que 5NF mal hecho, pero no peor que Sin normalizar, que es lo que la mayoría de las bases de datos existen (tergiversadas como "desnormalizadas para el rendimiento").
    • Por supuesto, es aún más importante (que en 5NF/3NF) mantener un contexto Transaction fuerte, porque las columnas están mucho más distribuidas.
    • Del mismo modo, es esencial conservar la integridad referencial declarativa:los problemas que he visto se debieron en gran parte a que los desarrolladores eliminaron DRI porque se volvió "demasiado difícil de mantener", el resultado fue, como pueden imaginar, una madre de un montón de datos con filas y columnas duplicadas 3NF/5NF por todas partes. Y manejo nulo inconsistente.

  4. No hay diferencia en el rendimiento, suponiendo que el servidor se haya configurado razonablemente para el propósito previsto. (Ok, hay optimizaciones específicas que son posibles solo en 6NF, que no son posibles en otros NF, pero creo que eso está fuera del alcance de este hilo). Y nuevamente, EAV mal hecho puede causar cuellos de botella innecesarios, no más que Sin normalizar.

  5. Por supuesto, si vas con EAV, recomiendo más formalidad; comprar la quid completa; ir con 6NF; implementar un catálogo; utilidades para producir SQL; Puntos de vista; manejar los datos faltantes de manera consistente; eliminar Nulls por completo. Esto reduce su vulnerabilidad a la calidad de sus desarrolladores; pueden olvidarse de los problemas esotéricos de EAV/6NF, usar Vistas y concentrarse en la lógica de la aplicación.