sql - tipos - ¿Cuáles son las[des] ventajas de usar una tabla de clave/valor sobre columnas que no admiten nulos o tablas separadas?

sentencias de nosql (5)

Estoy actualizando un sistema de gestión de pagos que creé hace un tiempo. Actualmente tiene una tabla para cada tipo de pago que puede aceptar. Se limita a solo poder pagar por una cosa, que esta actualización es para aliviar. He estado pidiendo sugerencias sobre cómo debería diseñarlo, y tengo estas ideas básicas para trabajar:

Tenga una tabla para cada tipo de pago, con algunas columnas comunes en cada una. (diseño actual)
Coordine todos los pagos con una tabla central que asume las columnas comunes (unificando las ID de pago sin importar el tipo), e identifica otra tabla e ID de fila que tiene columnas especializadas para ese tipo de pago.
Tenga una tabla para todos los tipos de pago y anule las columnas que no se utilizan para ningún tipo dado.
Utilice la idea de la tabla central, pero almacene columnas especializadas en una tabla de clave / valor.

Mis objetivos para esto son: no ser ridículamente lentos, auto-documentarse tanto como sea posible, y maximizar la flexibilidad mientras mantengo los otros objetivos.

No me gusta mucho 1 debido a las columnas duplicadas en cada tabla. Refleja las clases de tipo de pago que heredan una clase base que proporciona funcionalidad para todos los tipos de pago ... ¿ORM al revés?

Me estoy inclinando más hacia 2, porque es tan "seguro" y auto-documentado como el diseño actual. Pero, como con 1, para agregar un nuevo tipo de pago, necesito agregar una nueva tabla.

No me gusta 3 debido a su "espacio desperdiciado", y no está claro de inmediato qué columnas se utilizan para qué tipos de pago. La documentación puede aliviar el dolor de esto de alguna manera, pero las herramientas internas de mi compañía no tienen un método efectivo para almacenar / encontrar documentación técnica.

El argumento que me dieron para 4 fue que aliviaría la necesidad de cambiar la base de datos al agregar un nuevo método de pago, pero sufre aún más que 3 debido a la falta de explicación. Actualmente, cambiar la base de datos no es un problema, pero podría convertirse en una pesadilla logística si decidimos comenzar a permitir que los clientes mantengan su propia base de datos en el futuro.

Así que, por supuesto, tengo mis prejuicios. Alguien tiene mejores ideas? ¿Qué diseño crees que encaja mejor? ¿En qué criterios debo basar mi decisión?

Quizás deberías mirar esta pregunta.

La respuesta aceptada de Bill Karwin se relaciona con argumentos específicos en contra de la tabla clave / valor que generalmente se conoce como Valor de atributo de entidad (EVA)

.. Aunque muchas personas parecen estar a favor de EAV, yo no. Parece la solución más flexible, y por lo tanto la mejor. Sin embargo, ten en cuenta el adagio TANSTAAFL . Estas son algunas de las desventajas de EAV:
No hay forma de hacer que una columna sea obligatoria (equivalente a NOT NULL ).
No hay forma de usar tipos de datos SQL para validar entradas.
No hay forma de asegurarse de que los nombres de los atributos se escriban de forma coherente.
No hay forma de poner una clave externa en los valores de ningún atributo dado, por ejemplo, para una tabla de búsqueda.
La obtención de resultados en un diseño tabular convencional es compleja y costosa, ya que para obtener atributos de varias filas, debe JOIN para cada atributo.
El grado de flexibilidad que EAV le otorga requiere sacrificios en otras áreas, probablemente haciendo que su código sea tan complejo (o peor) de lo que hubiera sido resolver el problema original de una manera más convencional.
Y en la mayoría de los casos, es innecesario tener ese grado de flexibilidad. En la pregunta del OP sobre los tipos de productos, es mucho más simple crear una tabla por tipo de producto para los atributos específicos del producto, por lo que tiene una estructura coherente aplicada al menos para las entradas del mismo tipo de producto.
Usaré EAV solo si se debe permitir que cada fila tenga potencialmente un conjunto distinto de atributos. Cuando tienes un conjunto finito de tipos de productos, EAV es una exageración. La herencia de la tabla de la clase sería mi primera opción.

Nota
Este tema se está discutiendo y se está haciendo referencia a este hilo en otros hilos, por lo tanto, le he dado un tratamiento razonable, por favor tenga paciencia conmigo. Mi intención es proporcionar comprensión, para que pueda tomar decisiones informadas, en lugar de decisiones simplistas basadas simplemente en etiquetas. Si lo encuentra intenso, léalo en trozos, a su gusto; Vuelve cuando tengas hambre, y no antes.

¿Qué, exactamente, sobre EAV, es "malo"?

1. Introducción

Hay una diferencia entre EAV que se realiza correctamente y que se hace mal, al igual que hay una diferencia entre que 3NF se hace correctamente y se hace mal. En nuestro trabajo técnico, debemos ser precisos sobre qué funciona exactamente y qué no; sobre lo que funciona bien, y lo que no funciona. Las declaraciones generales son peligrosas, informan mal a las personas y, por lo tanto, dificultan el progreso y la comprensión universal de los temas en cuestión.

No estoy a favor ni en contra de nada, excepto implementaciones deficientes por parte de trabajadores no calificados, y tergiversación del nivel de cumplimiento de las normas. Y donde veo malentendidos, como aquí, intentaré solucionarlo.

La normalización también es a menudo mal entendida, por lo que una palabra sobre eso. Wiki y otras fuentes gratuitas en realidad publican "definiciones" completamente sin sentido, que no tienen una base académica, que tienen sesgos de los proveedores para validar sus productos que no cumplen con los estándares. Hay un Codd que publica sus Doce Reglas. Implemento un mínimo de 5NF, que es más que suficiente para la mayoría de los requisitos, así que lo usaré como una línea de base. En pocas palabras, asumiendo que la tercera forma normal es entendida por el lector (al menos esa definición no es confusa) ...

2 Quinta forma normal

2.1 definición

La quinta forma normal se define como:

Cada columna tiene una relación 1 :: 1 con la clave principal, solo
ya ninguna otra columna, en la tabla, o en cualquier otra tabla
el resultado es no columnas duplicadas, en cualquier lugar; Sin anomalías de actualización (no es necesario que haya desencadenantes ni códigos complejos para garantizar que, cuando se actualiza una columna, sus duplicados se actualizan correctamente).
mejora el rendimiento porque (a) afecta a menos filas y (b) mejora la concurrencia debido a la reducción del bloqueo

Hago la distinción de que, no es que una base de datos esté Normalizada a una NF en particular o no; La base de datos está simplemente normalizada. Es que cada tabla está Normalizada a una NF particular: algunas tablas solo requieren 1NF, otras 3NF y otras requieren 5NF.

2.2 Rendimiento

Hubo un momento en que la gente pensaba que la normalización no ofrecía el rendimiento, y tenían que "desnormalizarse para el rendimiento". Gracias a Dios, se ha desacreditado el mito y la mayoría de los profesionales de TI de hoy se dan cuenta de que las bases de datos normalizadas funcionan mejor. Los proveedores de bases de datos optimizan para las bases de datos normalizadas, no para los sistemas de archivos no estructurados. La verdad "desnormalizada" es que la base de datos NO se normalizó en primer lugar (y funcionó mal), no se normalizó, y se hicieron algunas luchas adicionales para mejorar el rendimiento. Para ser Desnormalizado, primero debe ser fielmente Normalizado, y eso nunca tuvo lugar. He reescrito puntuaciones de dichas bases de datos "desnormalizadas para rendimiento", proporcionando una normalización fiel y nada más, y se ejecutaron al menos diez, y hasta cien veces más rápido. Además, solo requerían una fracción del espacio en disco. Es tan peatonal que garantizo el ejercicio, por escrito.

2.3 Limitación

Las limitaciones, o más bien la extensión total de 5NF es:

no maneja valores opcionales, y se deben usar Nulls (muchos diseñadores no permiten Nulls y usan sustitutos, pero esto tiene limitaciones si no se implementa de manera adecuada y consistente)
aún necesita cambiar DDL para agregar o cambiar columnas (y hay más y más requisitos para agregar columnas que no se identificaron inicialmente, después de la implementación; el control de cambios es oneroso)
aunque proporciona el nivel más alto de rendimiento debido a la Normalización (lectura: eliminación de duplicados y relaciones confusas), consultas complejas como pivotar (producir un informe de filas o resúmenes de filas, expresadas como columnas) y "acceso de columnas" como se requiere para Las operaciones de almacenamiento de datos son difíciles, y solo esas operaciones no funcionan bien. No es que esto se deba solo al nivel de habilidad de SQL disponible, y no al motor.

3 Sexta forma normal

3.1 definición

La Sexta Forma Normal se define como:

la relación (fila) es la clave principal más un atributo (columna) como máximo

Se conoce como la forma normal irreductible , la NF definitiva, porque no hay más normalización que se pueda realizar . Aunque se discutió en círculos académicos a mediados de los años noventa, se declaró formalmente solo en 2003. Para aquellos que gustan de denigrar la formalidad del Modelo Relacional, al confundir relaciones, relaciones, "relaciones", y cosas por el estilo: todo lo que el disparate puede hacer. se acueste porque formalmente, la definición anterior identifica la relación irreductible , a veces llamada la relación atómica.

3.2 Progresión

El incremento que proporciona 6NF (que 5NF no) es:

Soporte formal para valores opcionales y, por lo tanto, eliminación de El problema nulo.
- Un efecto secundario es que las columnas se pueden agregar sin cambios de DDL (más adelante)
giro sin esfuerzo
Acceso columnar simple y directo.
- permite (no en su forma de vainilla) un nivel de rendimiento aún mayor en este departamento

Permítanme decir que yo (y otros) proporcionamos tablas 5NF mejoradas hace 20 años, explícitamente para pivotar, sin ningún problema en absoluto, y permitiendo así que (a) se use SQL simple y (b) se proporcione un rendimiento muy alto; fue bueno saber que los gigantes académicos de la industria habían definido formalmente lo que estábamos haciendo. Durante la noche, mis mesas de 5NF fueron renombradas a 6NF, sin que yo levantara un dedo. Segundo, solo hicimos esto donde lo necesitábamos; de nuevo, fue la tabla, no la base de datos, la que se normalizó a 6NF.

3.3 Limitación de SQL

Es un lenguaje engorroso, particularmente las reincorporaciones, y hacer algo moderadamente complejo lo hace muy engorroso. (Es un tema aparte que la mayoría de los programadores no entienden o usan subconsultas). Admite las estructuras necesarias para 5NF, pero solo. Para implementaciones robustas y estables, se deben implementar estándares adicionales, que pueden consistir en parte, en tablas de catálogo adicionales. La fecha de "uso por" para SQL había transcurrido bien y verdaderamente a principios de los noventa; está totalmente desprovisto de soporte para tablas 6NF, y necesita ser reemplazado desesperadamente. Pero eso es todo lo que tenemos, así que solo tenemos que lidiar con eso.

Para aquellos de nosotros que habíamos estado implementando estándares y tablas de catálogo adicionales, no fue un esfuerzo serio extender nuestros catálogos para proporcionar la capacidad requerida para soportar estructuras de 6NF al estándar : qué columnas pertenecen a qué tablas y en qué orden; obligatorio / opcional; desplegar formato; Esencialmente un catálogo completo de MetaData, casado con el catálogo SQL.

Tenga en cuenta que cada NF contiene cada NF anterior dentro de ella, por lo que 6NF contiene 5NF. No rompimos 5NF para proporcionar 6NF, proporcionamos una progresión de 5NF; y donde SQL se quedó corto proporcionamos el catálogo. Lo que esto significa es, restricciones básicas como las claves foráneas; y los dominios de valor que se proporcionaron a través de la integridad referencial declarativa de SQL; Tipos de datos; CONTROLES; y las REGLAS, en el nivel 5NF, permanecieron intactas, y estas restricciones no fueron subvertidas. La alta calidad y el alto rendimiento de las bases de datos 5NF que cumplen con los estándares no se redujeron de ninguna manera al introducir 6NF.

3.4 Catálogo

Es importante proteger a los usuarios (cualquier herramienta de informe) y a los desarrolladores, de tener que lidiar con el salto de 5NF a 6NF (es su trabajo ser geeks de codificación de aplicaciones, es mi trabajo ser el geek de base de datos). Incluso en 5NF, ese fue siempre un objetivo de diseño para mí: una base de datos correctamente normalizada, con un Directorio de datos mínimo, es bastante fácil de usar, y no había forma de renunciar a eso. Tenga en cuenta que debido al mantenimiento y la expansión normales, las estructuras de 6NF cambian con el tiempo, las nuevas versiones de la base de datos se publican a intervalos regulares. Sin duda, el SQL (ya incómodo a 5NF) requerido para construir una fila de 5NF a partir de las tablas de 6NF, es aún más engorroso. Agradecido, eso es completamente innecesario.

Como ya teníamos nuestro catálogo, el cual identificó el completo 6NF-DDL-que-SQL-no-proporciona-si es así, escribí una pequeña utilidad para leer el catálogo y:

generar la tabla 6NF DDL.
Genere 5NF VIEWS de las tablas 6NF. Esto permitió a los usuarios permanecer felizmente inconscientes de ellos, y les dio la misma capacidad y rendimiento que tenían a 5NF
genere el SQL completo (no una plantilla, los tenemos por separado) necesarios para operar contra las estructuras 6NF, que luego utilizan los codificadores. Se liberan del tedio y la repetición que de otro modo se exige, y son libres de concentrarse en la lógica de la aplicación.

No escribí una utilidad para Pivoting porque se elimina la complejidad presente en 5NF, y ahora son muy fáciles de escribir, como sucede con el 5NF-mejorado-para-pivote. Además, la mayoría de las herramientas de informes proporcionan una función de giro, por lo que solo necesito proporcionar funciones que incluyan un gran número de estadísticas, que deben realizarse en el servidor antes de enviarlas al cliente.

3.5 Rendimiento

Todo el mundo tiene su "enfermedad" para sufrir, su cruz para soportar; Estoy obsesionada con el rendimiento. Mis bases de datos de 5NF funcionaron bien, así que permítame asegurarle que ejecuté muchos más puntos de referencia de los necesarios, antes de poner algo en producción. La base de datos 6NF realizó exactamente lo mismo que la base de datos 5NF, ni mejor ni peor. Esto no es una sorpresa, porque lo único que hace el "complejo" 6NF SQL, que el 5NF SQL no, es realizar muchas más combinaciones y subconsultas.

Tienes que examinar los mitos.

Cualquiera que haya evaluado el problema (es decir, que haya examinado los planes de ejecución de las consultas) sabrá que el Costo Nada se une , es una resolución en tiempo de compilación, no tienen ningún efecto en el momento de la ejecución.
Sí, por supuesto, el número de tablas unidas; el tamaño de las mesas que se unen; si se pueden utilizar índices; la distribución de las claves que se unen; etc, todo cuesta algo.
Pero la unión en sí no cuesta nada.
Una consulta en cinco tablas (más grandes) en una base de datos no normalizada es mucho más lenta que la consulta equivalente en diez tablas (más pequeñas) en la misma base de datos si estuviera normalizada. el punto es que ni las cuatro ni las nueve juntas cuestan nada; no figuran en el problema de rendimiento; el conjunto seleccionado en cada unión figura en él.

3.6 Beneficio

Acceso columnar no restringido. Aquí es donde realmente destaca el 6NF. El acceso directo a la columna fue tan rápido que no hubo necesidad de exportar los datos a un almacén de datos para obtener la velocidad de las estructuras especializadas de DW.
Mi investigación en algunos DW, de ninguna manera completa, muestra que constantemente almacenan datos por columnas, en lugar de filas, que es exactamente lo que hace 6NF. Soy conservador, por lo que no estoy dispuesto a hacer ninguna declaración de que 6NF desplazará a los DW, pero en mi caso eliminó la necesidad de uno.
No sería justo comparar las funciones disponibles en 6NF que no estaban disponibles en 5NF (por ejemplo, Pivoting), que obviamente se ejecutaron mucho más rápido.

Esa fue nuestra primera base de datos verdadera de 6NF (con un catálogo completo, etc; a diferencia de la 5NF siempre con mejoras solo según sea necesario; que luego resultó ser 6NF), y el cliente está muy contento. Por supuesto, estuve supervisando el rendimiento durante algún tiempo después de la entrega, e identifiqué un método de acceso por columnas aún más rápido para mi próximo proyecto de 6NF. Eso, cuando lo haga, podría presentar un poco de competencia para el mercado DW. El cliente no está listo y no reparamos lo que no está roto.

3.7 ¿Qué, exactamente, sobre 6NF, es "Malo"?

Tenga en cuenta que no todos abordarían el trabajo con tanta formalidad, estructura y cumplimiento de los estándares. Por lo tanto, sería tonto concluir de nuestro proyecto, que todas las bases de datos de 6NF funcionan bien y son fáciles de mantener. Sería tan tonto concluir (al observar las implementaciones de otros) que todas las bases de datos de 6NF tienen un mal desempeño, son difíciles de mantener; los desastres Como siempre, con cualquier esfuerzo técnico, el rendimiento resultante y la facilidad de mantenimiento dependen estrictamente de la formalidad, la estructura y el cumplimiento de las normas, además del conjunto de habilidades relevante.

3.8 disponibilidad

No se exponga y solicite nada más allá de los límites de la práctica comercial estándar, como "referencias publicadas", el cliente es un banco australiano, toda la implementación es confidencial; Pero soy libre de tomar perspectivas en las visitas. También puede ver (pero no copiar) la documentación en nuestras oficinas en Sydney. La metodología (estructuras y estándares más allá de la educación pública 6NF disponible) y las utilidades, es nuestra propiedad intelectual patentada, y está disponible para tareas. En esta etapa, lo estoy vendiendo solo como parte de una asignación, porque (a) Necesito asegurar razonablemente el éxito del proyecto (para no dañar nuestra reputación), y (b) un proyecto exitoso no es suficiente madurez para clasificarlo como ''listo para el mercado''.

Me complace continuar respondiendo preguntas y brindando información útil sobre el catálogo 6NF, consejos sobre qué funciona y qué no, etc. sin publicar nuestra IP (documentación). También estoy feliz de ejecutar puntos de referencia calificados para usted.

4 Valor de atributo de entidad

Divulgación: Experiencia. He inspeccionado algunos de estos, en su mayoría sistemas hospitalarios y médicos. He realizado tareas correctivas en dos de ellos. La entrega inicial por parte del proveedor en el extranjero fue bastante adecuada, aunque no excelente, pero las extensiones implementadas por el proveedor local fueron un desastre. Pero no es casi el desastre que la gente ha publicado acerca de re EAV en este sitio. Unos meses de intenso trabajo los arreglamos muy bien.

4.1 Qué es

Para mí era obvio que las implementaciones de EAV en las que he trabajado son simplemente subconjuntos de Sixth Normal Form. Aquellos que implementan EAV lo hacen porque desean algunas de las características de 6NF (por ejemplo, la capacidad de agregar columnas sin cambios de DDL), pero no tienen el conocimiento académico para implementar la verdadera 6NF, o los estándares y estructuras para implementarla y administrarla. de forma segura Incluso el proveedor original no sabía acerca de 6NF, o de que EAV era un subconjunto de 6NF, pero se pusieron de acuerdo cuando lo señalé. Debido a que las estructuras requeridas para proporcionar EAV, y de hecho 6NF, de manera eficiente y efectiva (catálogo; Vistas; generación automatizada de código) no se identifican formalmente en la comunidad de EAV, y faltan en la mayoría de las implementaciones, clasifico a EAV como el hijo bastardo Sexta forma normal .

4.2 ¿Qué, exactamente, sobre EAV, es "malo"?

A juzgar por los comentarios en este y otros hilos, sí, EAV mal hecho es un desastre. Más importantes (a) son tan malos que se pierde el rendimiento proporcionado a 5NF (olvidar 6NF) y (b) no se ha implementado el aislamiento ordinario de la complejidad (los codificadores y los usuarios están "obligados" a utilizar una navegación incómoda). Y si no implementaron un catálogo, no se habrán evitado todo tipo de errores evitables. Todo eso puede ser cierto para implementaciones malas (EAV u otras), pero no tiene nada que ver con 6NF o EAV. Los dos proyectos en los que trabajé tuvieron un desempeño bastante adecuado (claro, podría mejorarse; pero no hubo un mal desempeño debido al EAV ) y un buen aislamiento de la complejidad. Por supuesto, no estaban cerca de la calidad o el rendimiento de mis bases de datos de 5NF o mi verdadera base de datos de 6NF, pero eran lo suficientemente justas, dado el nivel de comprensión de los problemas publicados dentro de la comunidad de EAV. No fueron los desastres y el absurdo sub-estándar supuestamente EAV en estas páginas.

5 nulos

Hay un problema conocido y documentado llamado El problema nulo. Es digno de un ensayo por sí mismo. Para este post, basta con decir:

El problema es realmente el valor opcional o faltante; Aquí la consideración es el diseño de la tabla de modo que no haya columnas Null vs Nullable
en realidad no importa porque, independientemente de si utiliza Nulls / No Nulls / 6NF para excluir los valores faltantes, tendrá que codificar para eso , el problema precisamente entonces, es el manejo de los valores faltantes , que no se pueden eludir.
- Excepto, por supuesto, para 6NF puro, que elimina el problema nulo.
- La codificación para manejar los valores perdidos permanece.
  - Excepto, con generación automatizada de código SQL, je je.
Los valores nulos son malas noticias para el rendimiento, y muchos de nosotros hemos decidido hace décadas que no se permiten valores nulos en la base de datos (los valores nulos en los parámetros y los conjuntos de resultados pasados, para indicar valores faltantes, está bien)
- lo que significa un conjunto de sustitutos nulos y columnas booleanas para indicar valores perdidos
Los valores nulos hacen que las columnas len fijas sean variables len; Las columnas variables de len nunca deben usarse en índices, porque se debe realizar un pequeño ''desempaquetado'' en cada acceso de cada entrada de índice, durante el recorrido o la inmersión.

6 posiciones

No soy un proponente de EAV o 6NF, soy un proponente de calidad y estándares. Mi posición es:

Siempre, en todos los sentidos, haga lo que esté haciendo con el más alto nivel del que tenga conocimiento.
La normalización a la tercera forma normal es mínima para una base de datos relacional (5NF para mí). Los tipos de datos, la integridad referencial declarativa, las transacciones y la normalización son todos requisitos esenciales de una base de datos; Si faltan, no es una base de datos.
- Si tiene que "desnormalizar el rendimiento", ha cometido graves errores de normalización, su diseño no está normalizado. Período. No "desnormalizar", por el contrario, aprender Normalización y Normalizar.
No hay necesidad de hacer trabajo extra. Si su requisito puede cumplirse con 5NF, no lo implemente más. Si necesita valores opcionales o la capacidad de agregar columnas sin cambios de DDL o la eliminación completa del problema nulo, implemente 6NF, solo en las tablas que los necesitan .
Si lo hace, solo por el hecho de que SQL no proporciona el soporte adecuado para 6NF, deberá implementar:
- un catálogo simple y efectivo (las combinaciones de columnas y la pérdida de integridad de datos simplemente no son aceptables)
- Acceso 5NF para las tablas 6NF, a través de VIEWS, para aislar a los usuarios (y desarrolladores) del SQL encogido (no "complejo")
- escriba o compre utilidades, de modo que pueda generar el incómodo SQL para construir las filas de 5NF a partir de las tablas de 6NF y evitar escribir las mismas
- Medir, monitorear, diagnosticar y mejorar. Si tiene un problema de rendimiento, ha cometido (a) un error de Normalización o (b) un error de codificación. Período. Haz una copia de seguridad de unos pocos pasos y arréglalo.
Si decide ir con EAV, reconozca que es, 6NF, e impleméntelo correctamente, como se muestra arriba. Si lo haces, tendrás un proyecto exitoso, garantizado. Si no lo hace, tendrá un desayuno para perros, garantizado.

6.1 No hay tal cosa como un almuerzo gratis

Ese adagio ha sido referido, pero en realidad ha sido mal utilizado. La forma en que realmente se aplica es la anterior: si desea los beneficios de 6NF / EAV, es mejor que esté dispuesto a hacer el trabajo necesario para obtenerlo (catálogo, estándares). Por supuesto, el corolario es que, si no hace el trabajo, no obtendrá el beneficio. No hay "pérdida" de tipos de datos; Dominios de valor; Llaves extranjeras; Cheques Reglas. Con respecto al rendimiento, no hay penalización de rendimiento para 6NF / EAV, pero siempre hay una penalización de rendimiento sustancial para el trabajo deficiente, sub-estándar.

7 pregunta especifica

Finalmente. Con la debida consideración al contexto anterior, y que se trata de un proyecto pequeño con un equipo pequeño, no hay duda:

No utilice EAV (o 6NF para esa materia)
No utilice las columnas Null o Nullable (a menos que desee subvertir el rendimiento)
Utilice una sola tabla de pagos para las columnas de pago comunes
y una tabla secundaria para cada tipo de pago, cada uno con sus columnas específicas
Todo totalmente encasillado y restringido.
¿Qué es este "otro row_id" negocio? ¿Por qué algunos de ustedes ponen una identificación en todo lo que se mueve, sin verificar si es un ciervo o un águila? No. El niño es un hijo dependiente. La relación es 1 :: 1. La PK del hijo es la PK del padre, la tabla de pagos común. Este es un cluster ordinario de supertipo-subtipo, el diferenciador es PaymentTypeCode. Los subtipos y supertipos son una parte ordinaria del modelo relacional, y están completamente cubiertos en la base de datos, así como en cualquier buena herramienta de modelado.
Claro, las personas que no tienen conocimiento de las bases de datos relacionales creen que lo inventaron 30 años después, y le dan nuevos nombres divertidos. O peor aún, lo reetiquetan a sabiendas y lo reclaman como propio. Hasta que algunos pobres, con un poco de educación y orgullo profesional, exponen la ignorancia o el fraude. No sé cuál es, pero es una de ellas; Sólo estoy afirmando hechos, que son fáciles de confirmar.

Gracias por quedarte conmigo hasta el final.

A. Respuestas a los comentarios

A.1 Atribución

Al afirmar que "soy fiel a la RM" y al referirme a los "Gigantes de la industria", asumí que los profesionales de TI entenderían lo que eso significaba. Disculpas humildes.

No tengo definiciones personales, privadas o especiales. Todas las declaraciones con respecto a la definición (como imperativos) de:
- Normalización,
- Formas normales, y
- El modelo relacional.
  .
  consulte los muchos textos originales Por EF Codd y CJ Fecha (no disponible de forma gratuita en la web)
  .
  Lo último son Datos temporales y El modelo relacional por CJ Date, Hugh Darwen, Nikos A Lorentzos
  .
  y nada más que esos textos
  .
  "Estoy sobre los hombros de gigantes"
  .
La esencia, el cuerpo, todas las afirmaciones con respecto a la implementación (por ejemplo, subjetiva y en primera persona) de lo anterior se basan en la experiencia; implementar los principios y conceptos anteriores, como organización comercial (consultor asalariado o asesoría), en grandes instituciones financieras de Estados Unidos y Australia, durante 32 años.
- Esto incluye puntuaciones de tareas grandes que corrigen o reemplazan implementaciones subnormales o no relacionales.
  .
El problema nulo con respecto a la sexta forma normal
Puede encontrar un Libro Blanco disponible gratuitamente relacionado con el título (no define el problema nulo solo) en:
http://www.dcs.warwick.ac.uk/~hugh/TTM/Missing-info-without-nulls.pdf .
.
Se puede encontrar una definición "en pocas palabras" de 6NF (significativa para aquellos experimentados con las otras FN) en p6

A.2 Pruebas de apoyo

Como se dijo al principio, el propósito de este post es contrarrestar la información errónea que abunda en esta comunidad, como un servicio a la comunidad.
Se pueden proporcionar declaraciones de respaldo de la evidencia en relación con la implementación de los principios anteriores, siempre y cuando se identifiquen declaraciones específicas; y en la misma medida en que se evidencian las declaraciones incorrectas publicadas por otros, a las que responde esta publicación. Si va a haber una pelea de bollos, asegurémonos de que el campo de juego esté nivelado.
Aquí hay algunos documentos que puedo poner en mis manos de inmediato, para comenzar (estoy en una asignación en Nueva Zelanda, proporcionaré más en un par de días, los nombres de los clientes deben ser ofuscados).
a. Banco grande
Este es el mejor ejemplo, ya que se llevó a cabo por razones explícitas en este post y se cumplieron los objetivos. Tenían un presupuesto para Sybase IQ (producto DW) pero los informes fueron tan rápidos cuando terminamos el proyecto que no lo necesitaron. Las estadísticas analíticas comerciales fueron mis extensiones pivotantes 5NF plus, que resultaron ser 6NF , descritas anteriormente. Creo que todas las preguntas formuladas en los comentarios han sido respondidas en el documento, excepto:
- número de filas:
- la base de datos antigua es desconocida, pero puede extrapolarse de las otras estadísticas
- nueva base de datos = 20 tablas sobre 100M, 4 tablas sobre 10B.
segundo. Pequeño Instituto Financiero Parte A
Parte B - La carne
Parte C - Diagramas de referencia
Parte D - Apéndice, Auditoría de índices antes / después (1 línea por índice)
Tenga en cuenta cuatro documentos; el cuarto solo para aquellos que desean inspeccionar los cambios detallados del Índice. Estaban ejecutando una aplicación de terceros que no podía cambiarse porque el proveedor local estaba fuera del negocio, más un 120% de extensiones que podían, pero no querían, cambiar. Nos llamaron porque actualizaron a una nueva versión de Sybase, que era mucho más rápida, lo que modificó los distintos umbrales de rendimiento, lo que causó una gran cantidad de interbloqueos. Aquí, Normalizamos absolutamente todo en el servidor, excepto el modelo db, con el objetivo (garantizado de antemano) de eliminar los interbloqueos (lo siento, no lo voy a explicar aquí: las personas que discuten sobre el tema de la "desnormalización", estarán en un color rosa). encaja sobre esto). Incluía una inversión de "dividir las tablas en una base de datos de archivo para el rendimiento", que es el tema de otra publicación (sí, la nueva tabla única se realizó más rápido que las dos derramadas). Este ejercicio se aplica también a MS SQL Server [insertar versión de reescritura].
do. Hospital Yale New Haven
Esa es la Escuela de Medicina de Yale, su hospital docente. Llevo años apoyándolos. Aplicación de terceros en la parte superior de Sybase. El problema con las estadísticas es que el 80% de las veces que recolectaban instantáneas solo en los tiempos de las pruebas nominadas, pero no tienen un historial coherente, por lo que no existe una "imagen anterior" con la que comparar nuestras nuevas estadísticas consistentes. No conozco a ningún otro compañero que pueda obtener estadísticas internas de Unix y Sybase en los mismos gráficos, de manera automatizada . Ahora la red es el umbral (confíe en que el lector aprecie que eso es algo bueno).

Solo algo para empezar, que ha sido aprobado para su publicación. Más tarde. Ok, tengamos alguna evidencia que apoye la idea de que "''desnormalización'' mejora el rendimiento", etc. Tu turno.

Longitud A.3

No me disculpo por la longitud o por la naturaleza condensada. Las personas con períodos de atención cortos (sin ofensas, es una realidad en estos días), o que no están familiarizados con la tecnología o la terminología relacional, deben consultar los textos de origen o los defensores de dicha tecnología.
Por definición, eso excluye a Wiki, y cualquier persona que denigre dicha tecnología, como los carteles a los que responde esta publicación. Es imposible para un elefante definir una gacela; y si ellos postulan sobre la vida de las gacelas, no debemos escucharlas.

A primera vista, optaría por la opción 2 (o 3): cuando sea posible, generalizar. La opción 4 no es muy relacional, creo, y hará que sus consultas sean complejas. Cuando me enfrento a esas preguntas, generalmente enfrento esas opciones con "casos de uso": ¿
cómo se está comportando el diseño 2/3 cuando se realiza esta operación o esta?

Mi principio # 1 es no rediseñar algo sin motivo. Así que me quedaría con la opción 1 porque ese es su diseño actual y tiene un historial comprobado de trabajo.

Pase el tiempo de rediseño en nuevas características en su lugar.

Si estuviera diseñando desde cero, iría con el número dos. Te da la flexibilidad que necesitas. Sin embargo, con el número 1 ya instalado y funcionando, y esto es bastante central para toda la aplicación, probablemente desconfiaría de realizar un cambio de diseño importante sin tener una buena idea de exactamente qué consultas, procesos almacenados, vistas, UDF, informes, importaciones Tendrías que cambiar, etc. Si fuera algo que pudiera hacer con un riesgo relativamente bajo (y una buena prueba de alrady en su lugar), podría optar por el cambio a la solución 2, de lo contrario, podría estar introduciendo nuevos errores peores.

Bajo ninguna circunstancia utilizaría una tabla EAV para algo como esto. Son horribles para las consultas y el rendimiento, y la flexibilidad está sobrevalorada (pregunte a los usuarios si prefieren poder agregar nuevos tipos 3 o 4 veces al año sin un cambio de programa a costa del rendimiento diario).