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

45

Cuando reviso los modelos de base de datos para RDBMS, generalmente me sorprende encontrar pocas o ninguna restricción (aparte de PK / FK). Por ejemplo, el porcentaje a menudo se almacena en una columna de tipo int (mientras que tinyint sería más apropiado) y no hay una restricción CHECK para restringir el valor a un rango de 0..100. De manera similar, en SE.SE, las respuestas que sugieren restricciones de verificación a menudo reciben comments sugiriendo que la base de datos es el lugar incorrecto para las restricciones.

Cuando pregunto sobre la decisión de no implementar restricciones, los miembros del equipo responden:

  • O que ni siquiera saben que tales características existen en su base de datos favorita. Es comprensible para los programadores que usan ORM solamente, pero mucho menos para los DBA que afirman tener más de 5 años de experiencia con un RDBMS dado.

  • O que apliquen dichas restricciones en el nivel de la aplicación, y duplicar esas reglas en la base de datos no es una buena idea, violando SSOT.

Más recientemente, veo más y más proyectos donde ni siquiera se usan claves externas. Del mismo modo, he visto algunos comentarios aquí en SE.SE que muestran que a los usuarios no les importa mucho la integridad referencial, permitiendo que la aplicación la maneje.

Cuando le preguntan a los equipos sobre la opción de no usar FK, dicen que:

  • Es PITA, por ejemplo, cuando uno tiene que eliminar un elemento al que se hace referencia en otras tablas.

  • NoSQL oscila, y no hay claves foráneas allí. Por lo tanto, no los necesitamos en RDBMS.

  • No es un gran problema en términos de rendimiento (el contexto suele ser pequeñas aplicaciones web de intranet que trabajan con conjuntos de datos pequeños, por lo que incluso los índices no importan demasiado; a nadie le importaría si el rendimiento de un La consulta dada pasa de 1.5 s a 20 ms.)

Cuando miro la aplicación en sí, me doy cuenta sistemáticamente de dos patrones:

  • La aplicación limpia correctamente los datos y los verifica antes de enviarlos a la base de datos. Por ejemplo, no hay manera de almacenar un valor 102 como porcentaje a través de la aplicación.

  • La aplicación asume que todos los datos que provienen de la base de datos son perfectamente válidos. Es decir, si 102 aparece como un porcentaje, o algo, algún lugar se bloqueará o simplemente se mostrará al usuario, lo que dará lugar a situaciones extrañas.

  • Si bien una sola aplicación realiza más del 99% de las consultas, con el tiempo comienzan a aparecer los scripts, ya sea que los scripts se ejecuten a mano cuando sea necesario, o los trabajos cron. Algunas operaciones de datos también se realizan a mano en la propia base de datos. Tanto los scripts como las consultas manuales de SQL tienen un alto riesgo de introducir valores no válidos.

Y aquí viene mi pregunta:

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

Por lo que vale, esta pregunta y las respuestas que recibí (especialmente la interesante discusión con Thomas Kilian) me llevaron a escribir una Artículo con mis conclusiones sobre el tema de las restricciones de la base de datos .

    
pregunta Arseni Mourzenko 29.11.2016 - 12:34

7 respuestas

27

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.

    
respondido por el JacquesB 30.11.2016 - 08:54
15

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.

    
respondido por el Machado 29.11.2016 - 13:13
10
  

¿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.

    
respondido por el Tulains Córdova 30.11.2016 - 12:48
3

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.

    
respondido por el JeffO 30.11.2016 - 22:57
2

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.
respondido por el Rick Marshall 06.12.2016 - 06:47
1

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).

    
respondido por el Thomas Kilian 29.11.2016 - 13:32
1

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.

    
respondido por el user147272 30.11.2016 - 13:13

Lea otras preguntas en las etiquetas

Comentarios Recientes

¿Podemos realmente llegar al muro proverbial con el modelado en el SERP? ¿Podemos realmente mostrar un montón de gráficos semi-fantásticos donde los espacios de columnas cambian todo el tiempo? A veces, de repente, sentimos que hemos pintado la autopista en construcción, excepto que lo tenemos atrapado en un lugar en este momento. Pero, una vez más, cuando sabemos que hay una pestaña en el índice donde se encuentran todos los contenidos de la columna, podremos hacer clic y arrastrarla con control total para... Lee mas