¿Qué pasó con las restricciones de la base de datos?

Es importante distinguir entre diferentes casos de uso para bases de datos.

A la base de datos de negocios tradicional se accede mediante múltiples aplicaciones y servicios independientes y quizás directamente por usuarios autorizados. Es fundamental tener un esquema y restricciones bien pensados en el nivel de la base de datos, por lo que un error o una supervisión en una sola aplicación no corrompe la base de datos. La base de datos es crítica para el negocio, lo que significa que los datos incoherentes o corruptos pueden tener resultados desastrosos para el negocio. Los datos vivirán para siempre mientras las aplicaciones vayan y vengan. Estos son los lugares que pueden tener un DBA dedicado para garantizar la consistencia y el estado de la base de datos.

Pero también hay sistemas en los que la base de datos está estrechamente integrada con una sola aplicación. Aplicaciones independientes o aplicaciones web con una sola base de datos integrada. Siempre que una sola aplicación acceda a la base de datos, puede considerar restricciones redundantes, siempre que la aplicación funcione correctamente. Estos sistemas a menudo son desarrollados por programadores con un enfoque en el código de la aplicación y quizás no una comprensión profunda del modelo relacional. Si la aplicación utiliza un ORM, las restricciones podrían declararse en el nivel de ORM de una forma más familiar para los programadores de aplicaciones. En el extremo inferior tenemos aplicaciones PHP que usan MySQL, y durante mucho tiempo MySQL no admitió restricciones básicas en absoluto, por lo que tenías que confiar en la capa de aplicación para asegurar la consistencia.

Cuando los desarrolladores de estos diferentes orígenes se encuentran, se produce un choque cultural.

En esta mezcla obtenemos la nueva ola de bases de datos de "almacenamiento en la nube" distribuidas. Es muy difícil mantener una base de datos distribuida coherente sin perder el beneficio del rendimiento, por lo que estas bases de datos a menudo evitan las comprobaciones de coherencia en el nivel de la base de datos y básicamente permiten que los programadores lo manejen en el nivel de la aplicación. Las diferentes aplicaciones tienen diferentes requisitos de consistencia, y aunque el motor de búsqueda de Google prioriza la disponibilidad en lugar de la coherencia en sus servidores, estoy dispuesto a apostar que su sistema de nómina se ejecuta en una base de datos relacional con muchas restricciones.

En la actualidad, cada vez más sistemas se ejecutan en entornos distribuidos, en la nube y adoptan la técnica para "escalar", en lugar de "escalar". Eso es aún más importante si se trata de aplicaciones en línea orientadas a Internet, como las aplicaciones de comercio electrónico.

Dicho esto, todas las aplicaciones que deben escalarse están limitadas por el Teorema de CAP , donde debe elegir 2 de 3: Consistencia, disponibilidad y tolerancia de partición (tolerancia a fallos de red).

Al estudiar el teorema de la PAC, verá que no hay muchas opciones, sino elegir perder la disponibilidad o la consistencia, ya que NUNCA se puede confiar realmente en la red el 100% del tiempo.

En general, varias aplicaciones pueden permitirse ser inconsistentes durante un período de tiempo razonable, pero no pueden permitirse el lujo de no estar disponibles para los usuarios. Por ejemplo, una línea de tiempo un poco desordenada en Facebook o Twitter es mejor que no tener acceso a una línea de tiempo en absoluto.

Por lo tanto, varias aplicaciones están optando por dejar de lado las restricciones de las bases de datos relacionales, ya que las bases de datos relacionales son realmente buenas en la consistencia, pero al costo de la disponibilidad.

Nota personal: también estoy pasado de moda, y he estado trabajando con algunos sistemas financieros muy antiguos en los que la consistencia de los datos es un requisito de primera clase la mayor parte del tiempo, y soy un gran fanático de las restricciones de la base de datos. Las restricciones de la base de datos son la última línea de defensa contra años y años de mal desarrollo y equipos de desarrolladores que vienen y se van.

"Est modus in rebus". Sigamos usando la consistencia de DB de "bajo nivel" donde la consistencia es un requisito de primera clase. Pero a veces, dejarlo ir no es un gran pecado, después de todo.

- EDITAR: -

Ya que hay una pequeña edición en la pregunta, hay otra razón legítima para eliminar las restricciones en la base de datos, IMO. Si diseña un producto desde cero, donde diseña su sistema para que sea compatible con la tecnología de bases de datos múltiples, puede conformarse con el mínimo común denominador entre las bases de datos compatibles y, finalmente, eliminar el uso de cualquier restricción, dejando toda la lógica de control para su aplicación.

Aunque es legítimo, también es un área gris para mí, porque hoy no puedo encontrar ningún motor de base de datos que no admita restricciones simples como la que se propuso en la pregunta original.

  

¿Cuáles son las razones para modelar bases de datos relacionales sin verificación?   ¿Restricciones y eventualmente incluso sin claves externas?

Primero, aclaremos que estoy hablando aquí solo de RDBM, no de bases de datos no-SQL.

He visto algunas bases de datos sin FK o PK, y mucho menos con restricciones, pero para ser sincero, son una minoría. Tal vez porque trabajo en una gran empresa.

En mi experiencia a través de los años, puedo decir que algunas razones pueden ser:

• En el caso de los programadores principiantes o afición , un reconocimiento de habilidades de modelado
• Uso extenso o casi exclusivo de ORM sin contacto real con el mundo de la base de datos
• Ausencia de un DBA u otro experto en modelado de datos en un equipo o proyecto pequeño
• Falta de participación del DBA o experto en modelado de datos en las primeras etapas del desarrollo
• Decisiones de diseño deliberadas por parte de la comunidad de desarrolladores que considera que incluso una restricción de verificación que impone que una determinada columna solo pueda tener 1,2 or 3 como valor, o que la columna "age" debe ser >= 0 es "tener lógica empresarial en la base de datos" . Incluso algunos consideran las cláusulas predeterminadas como una lógica de negocios que no pertenece a una base de datos, como puede ver en varias preguntas y respuestas recientes en este mismo sitio. Los desarrolladores que así lo consideren, obviamente usarán la menor cantidad de restricciones posible y harán todo lo que esté en el código, incluso la integridad referencial y / o la unicidad. Creo que esta es una posición extrema.
• Uso de RDBM como almacenamiento de valores clave , ya sea para emular el comportamiento no-SQL debido a que los requisitos eran lo suficientemente simples como para ser satisfechos al usar tablas RDBMS como depósitos de valores clave aislados.
• Suponiendo que la base de datos siempre será escrita por "la aplicación" y que nadie necesitará realizar una carga masiva de datos, o editar o insertar filas a través de un cliente SQL (en muchos casos para corregir errores) Datos de la aplicación insertada). En el mejor de los casos, siempre habrá otra aplicación (además de "la aplicación") que emita instrucciones DML a la base de datos: un cliente SQL.
• Sin darse cuenta de que los datos pertenecen al propietario de la empresa , no a la aplicación.

Dicho esto, me gustaría afirmar que los RDBMS son piezas de software muy avanzadas que se han construido sobre los hombros de gigantes y han demostrado ser muy eficientes para una gran cantidad de requisitos empresariales, liberando a los programadores de tareas rutinarias de reforzar la integridad referencial en una serie de archivos binarios o de texto. Como siempre digo "ya no vivimos en un mundo de una sola aplicación, una base de datos" . Como mínimo, un cliente SQL emitirá DML además de "la aplicación". Por lo tanto, la base de datos debería defenderse de los errores humanos o de programación en una medida razonable

En aquellos tipos de requisitos bien conocidos en los que RDBMS no se escalará bien, por supuesto que adopta la tecnología no-SQL . Pero es preocupante la proliferación de bases de datos relacionales sin restricciones donde miles de líneas de código (generadas o mecanografiadas) se dedican a aplicar lo que RDBMS debería aplicar para usted de manera más eficiente.

Hay restricciones externas que impulsan las decisiones tecnológicas. Solo hay algunas situaciones en las que tiene la necesidad o el lujo de utilizar restricciones de campo de base de datos de forma regular.

1. Las empresas tienen desarrolladores para aplicaciones y bases de datos junto con DBA, pero la mayoría de los desarrolladores no trabajan en este tipo de entorno. Hacen todo lo que pueden en el código. Además, algunos en el lado de la base de datos no se involucran en las reglas comerciales. Principalmente están ahí para mantener las cosas funcionando. Nunca empujarán por restricciones en la db. Tener que lidiar con aplicaciones heredadas, integraciones, migraciones, fusiones, adquisiciones y una restricción de DB puede ser la mejor solución.
2. Sobrecargar la base de datos puede crear un cuello de botella que no se resuelve fácilmente lanzando más máquinas al problema. Hay algunas situaciones en las que el lenguaje db no maneja algunos problemas de programación sin un gran impacto en el rendimiento, por lo que no puede planear usar una restricción para todo. Stackoverflow tiene un servidor de base de datos porque lanzar 2 a un problema es un desafío.
3. Pruebas automatizadas: están llegando, pero muchos desarrolladores de bases de datos llegan tarde a la fiesta junto con los marcos IDE / testing.
4. Implementación - más cosas de db lo hace más complicado. ¿Qué sucede cuando no se permite una actualización de la base de datos de un cliente porque hay datos que violan la restricción? Se acabó el juego a menos que tengas una manera de abordar esto. En tu aplicación, puedes decidir dejar que el usuario maneje esto según sea necesario o instruir a algún administrador para que lo haga por lotes.
5. Solo la aplicación / api / service alguna vez escribirá datos en la base de datos, ¿por qué molestarse? Esto se mantiene la mayor parte del tiempo, por lo que no es común.
6. Manejar los errores de la base de datos es bastante difícil sin cientos de infracciones de restricciones con las que lidiar si todo se sale de control. La mayoría está feliz de hacer una conexión y obtener el nombre correcto de la tabla.

Muchos equipos de desarrollo no quieren darle demasiado control a un desarrollador de db. Tienes suerte si obtienes más de uno, así que las vacaciones son muy divertidas. No muchos requieren un control absoluto sobre el dominio de la base de datos y se responsabilizan de cada consulta, regla de negocio, rendimiento, disponibilidad, seguridad y qué datos van a qué RAID. Aquí están los procedimientos almacenados que se le permite ejecutar. Que te diviertas. Ni siquiera pienses en tocar una mesa.

Este es un problema con el que he luchado durante toda mi carrera (casi 40 años) y también al escribir mi DBMS. Aquí hay una descripción de mi punto final: enlace . Así que aquí están mis pensamientos.

1. En términos generales, la mayoría de las restricciones se manejan mejor en la aplicación, de modo que las diferentes partes de la aplicación pueden imponer diferentes restricciones. por ejemplo, un código de estado podría no aplicarse en todas las jurisdicciones.
2. Como un aparte, cuidado con%. Las marcas son > 100% o vas a la quiebra :)
3. Las restricciones se describen mejor negativamente. Es decir, lo que no pueden ser, no lo que deberían ser. Siempre es una lista más simple.
4. Las claves foráneas son siempre buenas y deben usarse. Fullstop. FK es una de las pocas construcciones semánticas en un RDBMS y es muy útil. La mayor dificultad es decidir si dejar que un valor cuelgue si se elimina el FK o usar filas dependientes como una razón para no eliminar el registro de FK.
5. Las restricciones en el mundo real suelen ser más complejas que una restricción de valor de campo único.
6. Algunas restricciones, incluso a nivel de aplicación, funcionan en contra de buenas operaciones. Por ejemplo, la comprobación agresiva de fechas oculta errores en fechas aparentemente buenas. Necesita un error del operador para obtener una medida de los errores en fechas que parecen sensatas.

Las restricciones de la base de datos podrían haber sido una idea inteligente, pero ¿qué tal un uso práctico para ellas? Tome su restricción de porcentaje. Si aplica eso, su base de datos rechazará felizmente los porcentajes no válidos. ¿Y entonces? Necesitará lógica de negocios para manejar la excepción. Lo que realmente significa que la lógica de negocios al escribir un porcentaje incorrecto ya falló en otra parte. En resumen: la única restricción práctica que queda son las que ve (como PK / FK).

Más a menudo en estos días, las personas usan software (por ejemplo, Entity Framework) para generar tablas y columnas automáticamente. La idea es que no necesitan habilidades de SQL, lo que libera la capacidad del cerebro.

Las expectativas de que el software "solucione las cosas" a menudo no son realistas, y no crea las restricciones que un humano haría.

Para obtener mejores resultados, cree tablas usando SQL y agregue restricciones manualmente, pero a veces las personas no pueden hacer esto.