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.