Restricciones de integridad en una base de datos relacional: ¿debemos pasarlas por alto?


10

Estoy en una discusión permanente con los desarrolladores de la compañía donde trabajo porque dicen que es mejor deshacerse de la aplicación de la relación (a través de definiciones de restricciones FOREIGN KEY) en una base de datos relacional para acelerar consultas grandes y obtener mejores resultados. actuación.

La plataforma en consideración es MySQL 5.x, y no se ha configurado una CLAVE EXTRANJERA, incluso faltan algunas restricciones de la CLAVE PRIMARIA de las tablas relevantes que, al menos para mí, no es razonable. Quizás tengan razón y yo esté equivocado, pero no tengo suficientes argumentos para discutir sobre esta situación.

Este ha sido el enfoque preferido durante tres años. Soy nuevo en esta empresa (solo un mes) pero, como el producto "funciona", hay dudas para mejorar la base de datos; Sin embargo, lo primero que noté es que una página tarda 1 minuto en cargarse (¡sí, 60 segundos!).

Una de las afirmaciones detrás del estado actual de las cosas es que una base de datos "desnormalizada" es más rápida que una normalizada, pero no creo que sea cierto.

La mayoría de las consultas relevantes incluyen operaciones JOIN, lo que hace que se ejecuten muy, muy, muy lentamente con grandes cantidades de datos (la base de datos contiene millones de filas).

Comúnmente, el manejo de las operaciones "CRUD" se implementa a nivel de código del programa de aplicación; por ejemplo, para ELIMINAR algunos datos DE, digamos TableA:

  • es necesario verificar primero sobre la marcha si existe alguna relación entre las filas de TableAy TableB,
  • en caso de que dicha relación sea "detectada", el código del programa de la aplicación no permitirá ELIMINAR las filas pertinentes, pero
  • si por alguna razón el código del programa de la aplicación falla, la operación DELETE "tendrá éxito", sin importar si existe alguna relación con las filas y tablas involucradas.

Pregunta

¿Podría ayudarme a elaborar una respuesta buena, precisa y sólida para enriquecer el debate?


Nota : Tal vez se haya preguntado (y respondido) algo como esto antes, pero no pude encontrar nada por medio de Google.


Los comentarios no son para discusión extendida; Esta conversación se ha movido al chat .
Paul White 9

Respuestas:


12

Si, como se indicó en su publicación, la intención es crear una base de datos relacional (RDB por brevedad) y, por lo tanto, se espera que funcione como tal, la respuesta corta es:

  • No, no debe pasar por alto las restricciones de integridad de datos .

El objetivo principal debe ser administrar los datos pertinentes tal como son, un activo organizacional bastante valioso, y una manera confiable de lograr dicho objetivo es emplear medios técnicos que estén respaldados por una teoría sólida.

Por lo tanto, como profesionales de bases de datos, pueden aprovechar los mecanismos de modelo relacional modernos y elegantes proporcionados por el Dr. EF Codd para hacer cumplir las reglas de negocio y evitar los problemas que eventualmente surgirían si no se utilizan.

A este respecto, compartiré (a) mi opinión general sobre las restricciones y también (b) varias consideraciones sobre el estado de las cosas de la base de datos y el entorno de trabajo en cuestión de la siguiente manera.

RESTRICCIONES EXTRANJERAS, relaciones de datos e integridad referencial

Un RDB debe reflejar las características del contexto comercial de interés con alta precisión, lo que definitivamente requiere un análisis a nivel conceptual en profundidad dirigido por un modelador o diseñador que siga las mejores prácticas, contando con la asistencia indispensable de los expertos en negocios. Ese análisis debe proporcionar la identificación y formulación correctas de las reglas comerciales aplicables .

En consecuencia, si dicho modelador ha identificado que existen interrelaciones entre los datos relevantes, debe configurar las restricciones de nivel lógico correspondientes para que el sistema de gestión de bases de datos (DBMS) pueda garantizar que los datos permanezcan consistentes con las características exactas y reglas determinadas en el análisis mencionado anteriormente en todo momento .

Con respecto a la base de datos en discusión, se puede inferir que se han identificado las interrelaciones pertinentes, ya que usted menciona que hay un intento de procedimiento (y fácil de eludir) para hacerlas cumplir desde fuera de las instalaciones de DBMS, a fuerza del código del programa de aplicación (que es un enfoque pre-relacional) que en cualquier caso tiene que "tocar" la base de datos para tratar de validar la totalidad de dichas interrelaciones.

Sin embargo, como saben, esa no es la técnica óptima para proteger la integridad referencial , porque la ciencia relacional ha prescrito un instrumento muy poderoso para este propósito, es decir, restricciones de CLAVE EXTRANJERA (FK). Estas restricciones son muy fáciles de crear (a través del enfoque declarativo superior) ya que son oraciones simples que evitan recurrir a procedimientos ad hoc innecesarios y propensos a errores. Es muy útil tener en cuenta que la velocidad de ejecución de las restricciones de FK ha sido altamente optimizada por programadores especializados (y los principales proveedores de plataformas han trabajado en ello incluso durante décadas).

Además, dado que un RDB debe ser un componente de software independiente (autoprotector, autodescriptivo, etc.) al que puedan acceder múltiples programas de aplicación (escritorio, automático, web, móvil, combinaciones de los mismos), no debe ser "Acoplado" con el código de cualquiera de estas aplicaciones.

Del mismo modo, los datos, al ser un recurso organizacional significativo, tienden naturalmente a sobrevivir a los programas de aplicación, programadores de aplicaciones, plataformas de desarrollo de aplicaciones y paradigmas de programación.

Restricciones de CLAVE PRIMARIA e implicaciones de filas duplicadas

Cuando, en términos conceptuales, un tipo particular de cosas se considera importante en un entorno empresarial, un modelador de bases de datos tiene que (1) determinar sus características relevantes, es decir, sus propiedades, confirmar dicho tipo de cosas como un prototipo de instancias de entidad . es decir, un tipo de entidad y (2) lo representan mediante una tabla que está integrada por una o más columnas en un diseño lógico.

Entonces, al igual que es primordial distinguir cada instancia individual de un tipo de entidad dada en el mundo real, cada fila encerrada en una tabla también debe distinguirse de manera única. Si una tabla no tiene ninguna CLAVE declarada, eventualmente retendrá duplicados, y si hay dos o más filas que retengan exactamente los mismos valores, entonces todos tienen el mismo significado , todos representan el mismo hecho .

En ese punto, las filas duplicadas deben descartarse debido a múltiples razones. Desde una perspectiva teórica, el diseñador debe asegurarse de que cada fila sea siempre única con el fin de tener tablas que funcionen tan relacionalmente como lo permita el sub-lenguaje de datos SQL (lo que tiene importantes repercusiones en las operaciones de manipulación de datos). Además, desde una perspectiva informativa, si varias filas representan el mismo hecho, su grabación no solo es superflua sino dañina , como se ejemplifica a continuación:

  • Supongamos que alguien ha insertado dos filas idénticas en una tabla determinada.
  • Más tarde, alguien más viene y actualiza solo una aparición de los duplicados. Como consecuencia, la otra ocurrencia ya no está actualizada.
  • Sucesivamente, otra persona actualiza la ocurrencia que no se había modificado hasta ahora. De esta manera, ambos duplicados han sufrido diferentes cambios en distintos momentos.
  • Después de eso, cuando alguien está interesado en seleccionar la información transmitida por las filas en cuestión, puede encontrar dos "versiones" diferentes de la misma.

De este modo:

  • ¿Qué "versión" puede considerarse la correcta y confiable?
  • ¿Cuál refleja el mundo real con precisión?

Como saben, este fenómeno incluso puede tener implicaciones legales, una circunstancia que seguramente es de enorme importancia.

Además, el tiempo y el esfuerzo que debe emplearse para manejar tales contradicciones (quizás a través de algún tipo de "sincronización de actualizaciones") deberían dedicarse mejor a las tareas que realmente producen valor para su organización. Por lo tanto, el diseño debe evitar retener filas contradictorias para mantener intacta la consistencia de una base de datos.

Es por eso que la identificación de una CLAVE PRIMARIA (PK) y la declaración de la restricción respectiva siempre deben ser realizadas por el diseñador de la base de datos. Pero también debe mencionarse que una tabla puede tener más de una columna o combinación de columnas que contienen valores que identifican de forma única cada fila; como consecuencia, además de configurar una restricción PK (idealmente establecida como PRIMARIA debido a razones pragmáticas), el diseñador también debe declarar una o más CLAVES ALTERNATIVAS (generalmente definidas a través de una o más restricciones ÚNICAS más NO NULAS) cuando se aplica (que es muy común).

Otra propiedad ventajosa de las PK es que, cuando se "migran" a otras tablas para participar en FK individuales o compuestas, pueden ayudar a hacer cumplir las proporciones de cardinalidad de las relaciones que existen entre los datos. Todo esto, sí, mediante configuraciones declarativas simples y eficientes, aseguradas por el DBMS.

(Actual) restricciones CHECK y validación de una sola fila

No olvidemos la relevancia de las restricciones (actuales) de CHECK que, restringiendo declarativamente el conjunto válido de valores de columna de una fila (que puede parecer simple, pero de hecho es una característica fundamental de un DBMS relacional), también ayuda a hacer seguro de que las reglas del contexto empresarial se reflejan con precisión en todo momento.

Al marcar su pregunta con la etiqueta MySQL, debe mencionarse que, desafortunadamente, dicha plataforma permite la declaración de dicho tipo de restricción pero, al mismo tiempo, ¡ ignora su aplicación! , situación que, comprensiblemente, se informó como un error desde 2004 .

En este sentido, debería ocuparse de este factor por otros medios, por ejemplo, TRANSACCIONES ACIDAS, DISPARADORES u otros métodos dentro del DBMS (consulte esta respuesta de @ ypercubeᵀᴹ para obtener información sobre este tema) para que los datos continúen se consistente.

Restricciones de ASSERTION: configuración de más reglas de negocio de varias filas y varias tablas de forma declarativa

Un aspecto que, por cualquier motivo, es muy poco compatible, si es que lo hace, por los diferentes DBMS de SQL, incluido MySQL, es habilitar restricciones de múltiples filas y tablas de manera declarativa, más allá de PK y FK, evidentemente.

Por su parte, el estándar SQL incluye ASSERTIONs desde hace muchos años. No sé qué reglas de su entorno empresarial se beneficiarían de ese enfoque de validación de nivel lógico, pero, como diseñador de la base de datos, considero que sería bastante útil restringir los datos con una o más ASERCIONES, aunque debo mencionarlo desde el Desde el punto de vista de los desarrolladores de DBMS, este tipo de herramienta fundamental ha sido difícil de implementar en el nivel físico de abstracción.

Parece que el proveedor y / o desarrolladores de Oracle están evaluando el soporte de ASSERTION desde 2016, y eso haría que ese DBMS sea más compatible con las relaciones y, por lo tanto, más robusto y competitivo. Supongo que, si (i) sus consumidores siguen presionando y (ii) Oracle tiene éxito en la implementación, (iii) otros proveedores / comunidades de DBMS también tendrán que habilitarlos, y su uso comenzará a extenderse. Ciertamente, eso sería un gran progreso en el campo de la gestión de bases de datos, y siendo una de las herramientas más distintivas previstas por el Dr. Codd, personalmente espero que veamos que eso suceda pronto.

Consistencia de datos y el proceso de toma de decisiones.

Como se discutió anteriormente, uno de los aspectos más importantes de un RDB es que garantiza por sí mismo la consistencia de los datos que retiene, y dicha consistencia solo se cumple cuando el RDB cumple con las restricciones de integridad declaradas por el modelador.

A este respecto, es obligatorio tener tablas base (aquellas establecidas en una estructura DDL) cuya integridad esté protegida para poder crear tablas derivadas (por ejemplo, una declaración o vista SELECT que recupere columnas de varias tablas) que sean confiables , porque las tablas derivadas deben producirse necesariamente en términos de tablas base.

Es bien sabido que las personas usan la información como la herramienta principal en el proceso de toma de decisiones organizacional (y ordinario). Entonces, si la información presentada por una base de datos no es coherente y precisa, las decisiones basadas en dicha información no serán sólidas (por decir lo menos). Es por eso que un RDB debe diseñarse e implementarse cuidadosamente: debe construirse para convertirse en un recurso confiable que pueda ayudar a sus usuarios a tomar decisiones bien fundadas.

"Desnormalización"

Por desgracia, "una base de datos 'desnormalizada' es más rápida que una normalizada" es un concepto erróneo ampliamente difundido, aunque también es un argumento que puede ser refutado sobre bases lógicas, físicas y pragmáticas.

En primer lugar, la desnormalización implica necesariamente que una tabla base se ha normalizado previamente (en virtud de un procedimiento formal , basado en la ciencia, cumplido en el nivel lógico de abstracción de una base de datos).

Entonces, suponiendo que dicha tabla se haya normalizado correctamente, "desnormalizándola" (lo que, en contraste con el significado formal de la palabra, implica agregarle columnas que pertenecen a otras tablas en un anuncio y que también forman parte de ellas) . moda específica ) podría ayudar, por ejemplo, a acelerar (a nivel físico) el procesamiento de solo una o unas pocas declaraciones SELECT particulares, mientras que tal curso de acción podría, al mismo tiempo, estar socavando la ejecución de muchos otros datos asociados operaciones de manipulación (p. ej., varias instrucciones INSERT, UPDATE, DELETE y SELECT, o combinaciones de ellas incluidas en una o varias TRANSACCIONES DE ÁCIDO).

Además, la desnormalización (ya sea formal o informal) introduciría anomalías de actualización / modificación que deteriorarían la coherencia de la base de datos, un problema que "puede" manejarse mediante procedimientos complejos, costosos y propensos a errores, cuando todo esto puede evitarse. el principio.

Andamios de nivel físico que admiten tablas normalizadas y "desnormalizadas"

Un diseño lógico (abstracto) (diseño SQL-DDL) destinado a ser utilizado en el mundo real claramente tiene repercusiones físicas (concretas) que deben considerarse.

De esta manera, una tabla "desnormalizada" sería necesariamente "más ancha" (con columnas adicionales), lo que significa que sus filas serían necesariamente más pesadas (que requieren componentes de nivel físico más y más grandes), lo que significa que los procesos informáticos subyacentes (p. Ej. , aquellos que tienen que ver con el disco duro o la memoria) pueden volverse más lentos fácilmente.

En contraste, una tabla normalizada que es, por supuesto, "más estrecha" (que tiene menos columnas) sería un elemento "más ligero" (servido por componentes físicos cada vez más pequeños) que "se comporta más rápido", lo que aceleraría la serie de acciones relacionadas con , por ejemplo, escritura y lectura de datos.

Siendo así, es muy conveniente (a) normalizar las tablas relevantes de manera formal y prudente, manteniéndolas como tales, y luego (b) utilizar cualquier recurso de nivel físico que pueda optimizar la recuperación de datos y la velocidad de modificación, por ejemplo, implementar Una estrategia de indexación cuidadosa y eficiente, que permita configuraciones de servidor de hardware y software adecuadas, actualización de las capacidades de ancho de banda de red, etc.

El funcionamiento de la base de datos bajo consideración.

Los siguientes párrafos de su pregunta tienen que ver con la velocidad de las operaciones de recuperación de datos:

[A] s el producto "funciona", hay dudas para mejorar la base de datos; sin embargo, lo primero que noté es que una página tarda 1 minuto en cargarse (¡sí, 60 segundos!).

Si la carga de una determinada página lleva tanto tiempo, es evidente que los usuarios del sistema no están recibiendo un buen servicio; por lo tanto, incluso cuando "funciona", su funcionamiento no parece ser óptimo en absoluto, punto que demuestra que sus intenciones de hacer que todo el entorno (base de datos y aplicaciones) sean más eficientes están bien sostenidas y muestra una actitud muy constructiva.

Entonces, incluso cuando la ciencia definitivamente lo apoya y, por lo tanto, debe mantener una postura firme, sugiero abordar la situación de una manera diplomática, ya que al final del día, sus empleadores, colegas y usted se unen a los esfuerzos para hacer que toda la organización más exitoso. Por lo tanto, ese es un argumento que debe enfatizar, que, si bien están haciendo otras cosas más que bien, mejorar las prácticas generales y específicas de gestión de datos puede ayudar considerablemente a producir un mayor crecimiento organizacional e individual.

La mayoría de las consultas relevantes incluyen operaciones JOIN, lo que hace que se ejecuten muy, muy, muy lentamente con grandes cantidades de datos (la base de datos contiene millones de filas).

Vale la pena señalar que el operador JOIN es un elemento esencial y poderoso que pertenece a la manipulación relacional de datos. Entonces, aunque las plataformas más robustas sirven con ejecuciones comparativamente más rápidas, la circunstancia que describe es probablemente un síntoma de un diseño no eficiente (en los niveles conceptual, lógico y físico de abstracción). Entonces, mis estimaciones a primera vista son:

  • La configuración del ÍNDICE puede requerir mejoras.
  • Las definiciones de tipo y tamaño de columna PK y FK deben revisarse (y estoy totalmente de acuerdo con @Rick James con respecto a sus consideraciones PK , ya que las CLAVES compuestas tienden a ser mucho más eficientes que los sustitutos adjuntos en los casos apropiados).
  • La normalización adicional (formal, basada en la ciencia) podría ayudar a aliviar estos problemas, debido al hecho de que, en las circunstancias correctas (es decir, llevadas a cabo en un RDB bien diseñado), las uniones se ejecutan muy rápido .

Además, sí, como @TommCatt menciona en su respuesta , a veces una reescritura (lógica) de una consulta modifica su plan de ejecución (físico) acelerando la lectura / escritura de datos, que es un factor que definitivamente debe tenerse en cuenta.


1
Gran respuesta. Cuando considero el rendimiento de una implementación, siempre me recuerdo que un equipo de desarrolladores mucho más inteligente que yo ha estado trabajando en estos problemas durante mucho tiempo. Las bases de datos relacionales están en el corazón de los sistemas más enormes del mundo (Facebook y Twitter, por nombrar algunos obvios).
Nick Bedford el

9

La premisa básica de sus desarrolladores es absolutamente errónea. Las claves externas afectarán ligeramente el rendimiento del DML de su sistema. No se utilizan en absoluto en las consultas, por lo que no tienen ningún efecto en su rendimiento. Por lo tanto, sus desarrolladores no saben de qué están hablando y son las últimas personas de las que debería considerar tomar consejos.

Las claves externas desempeñan un papel fundamental en el mantenimiento de la integridad de sus datos. Esto es mucho más importante que cualquier pequeña mejora en el rendimiento obtenida al eliminarlos (incluso si fuera cierto).

No, bajo ninguna circunstancia, elimine los FK de una base de datos OLTP.

Además, la desnormalización a veces acelerará algunas consultas. Eso, como dicen, depende. Aún así, incluso si hay alguna mejora en la velocidad, generalmente no vale la pena el esfuerzo adicional para mantener la integridad de los datos.

Es muy raro que una simple sintonización no pueda mejorar tu velocidad mucho más que la desnormalización. Aquí es donde un buen DBA puede (finalmente) ganar su paga. También puede ajustar sus consultas. Una vez tomé una consulta que devolvió una respuesta en no menos de 30 minutos y la puse a trabajar en menos de 8 segundos. No hay cambios en la base de datos, solo reescribió la consulta. De acuerdo, este es mi mejor registro personal, por lo que su kilometraje puede variar, pero la desnormalización debería ser lo último que intente.

Es posible que también desee evitar que los desarrolladores escriban las consultas más complicadas. Pregúnteles qué datos quieren y en qué formato lo quieren. Luego, proporcione vistas para dárselos. Las consultas complicadas serán las vistas. Los desarrolladores solo tienen que escribir:

select <something> from <SomeView> where <whatever>;

También estoy asumiendo que su base de datos está bien diseñada. Un diseño deficiente de la base de datos, o incluso pequeñas partes de ella, realmente puede retrasar las cosas. He trabajado a menudo con tablas muy grandes (miles de millones de registros cada una) con consultas que las unieron a izquierda y derecha y esperaban (y obtuve) respuestas en fracciones de segundo. El tamaño de una tabla no determina la velocidad de la consulta.

Realmente me estremezco cuando alguien dice: "porque el producto 'funciona' hay dudas para mejorar la base de datos". Si esta "vacilación" es más como "no en mi reloj, amigo!" entonces es posible que desee comenzar a actualizar su currículum. Nada bueno viene de ese entorno y usted tendrá la culpa de cada falla futura, aunque haya presionado durante horas para hacer un cambio que hubiera evitado la falla. Escuchará, "Ahora no es un buen momento para hacer cambios" una y otra vez. Derecha. Buena suerte.


Una cosa a tener en cuenta es que a veces necesita consultas diferentes para los mismos datos en función de la cantidad de datos que se devolverán. Por ejemplo, una consulta que devuelve una sola fila (o incluso un recuento) podría escribirse mejor de manera diferente que una que devuelva miles de registros.
Joe W

2

Cambiar el título cambia la pregunta. FOREIGN KEYsson opcionales Ellas hacen:

  • Un FK crea implícitamente un INDEXen una de las tablas. Tal índice se puede agregar manualmente. (Por lo tanto, no se requiere FK para esto).
  • Un FK verifica la integridad. Este es el principal reclamo de FK a la fama. No se requiere un FK ya que su aplicación puede hacer verificaciones similares o decidir que no es necesaria una verificación. Entonces...
  • La verificación de integridad cuesta algo en rendimiento; por lo que ralentiza el procesamiento. (Esto generalmente no es un gran problema).
  • Los FK no hacen todo lo que todos quieren; este foro está plagado de preguntas de "por qué los FK no pueden hacer X". En particular, CHECKno se actúa sobre la opción.
  • Los FK pueden hacer CASCADEcosas. (Personalmente, prefiero mantener el control y no asumir que el FK 'hará lo correcto').

En pocas palabras para las FK: algunas personas insisten en las FK; Algunos productos viven perfectamente bien sin ellos. Tú decides.

Deshacerse de PRIMARY KEYInnoDB es un gran error. Por otro lado, deshacerse de un sustituto AUTO_INCREMENTy usar un PK "natural" compuesto por una (o más) columnas es a menudo lo correcto . Un caso simple y común es una tabla de mapeo muchos: muchos, como se discute aquí .

Según la experiencia personal, sugiero que 2/3 de las tablas son mejores que usar 'natural' en lugar de auto_inc PK.


1
Entonces ... confía en una aplicación casi perfecta porque si un desarrollador comete un error con un DELETEpor ejemplo y no tiene una restricción en el lado de la base de datos, terminará perdiendo datos. Este enfoque es válido pero requiere un código intenso y buenas pruebas, que no tenían :)
ReynierPM

Eliminar demasiado puede suceder en la aplicación o con FK. Eliminar muy poco suele ser obvio. OTOH, he visto casos en los que eliminar demasiado poco vale la pena. Piense en una "normalización" donde las cosas rara vez se eliminan. Las filas adicionales no utilizadas son prácticamente inofensivas.
Rick James

He visto un caso "bueno" para no tener índices en una tabla: una tabla de etapas para la ingestión de alta velocidad. Es muy transitorio (por lo tanto, InnoDB no es necesario) y solo necesita leerse por completo (por lo tanto, no se necesitan índices).
Rick James

1
Tenga en cuenta un tema común en mis divagaciones: no hay una respuesta única; No hay una talla única para todos.
Rick James

Si las tablas tienen mil filas de largo; El rendimiento no es un problema. Si sus tablas tienen una longitud de mil millones de filas, todas las "reglas" sobre normalización, PK, índices, FK, UUID, etc., deben ser analizadas. De lo contrario, la base de datos se derretirá.
Rick James
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.