Integridad de datos referenciales: ¿Necesidad, atractivo o viejo?

Question

Frameworks como Rails han alentado el movimiento de una gran parte de la lógica, incluso cosas como restricciones y claves externas, fuera de la base de datos, en mi opinión. para mejor, ya que es más manejable y fácil de cambiar. Aun así, algunas operaciones son más fáciles más rápido, o simplemente solo es posible en SQL.

La reciente explosión en popularidad de las bases de datos no SQL como MongoDB, Cassandra, etc., ha cambiado el enfoque de las mejores prácticas en el desarrollo de bases de datos de forma aún más radical.

Mi pregunta: ¿La integridad de los datos referenciales ya no es una necesidad?

Me doy cuenta que a menudo se trata de elegir la mejor herramienta para el trabajo, pero excluyamos aplicaciones financieras y aplicaciones similares donde tener transacciones es imprescindible y centrarnos en aplicaciones más típicas que hacen dinero pero no lo hacen requiere integridad a nivel bancario.

¿Cuán necesaria es la integridad de los datos referenciales? ¿Puede alguien enumerar algunos problemas que han tenido cuando no lo están usando?

Está utilizando una base de datos como PostgreSQL para datos más críticos, y MongoDB para datos menos críticos pero muy solicitados, la estrategia inteligente? ¿Cómo sugiere que se defina exactamente qué datos son "críticos" y cuáles "no críticos"?

Answer 1

He trabajado en una empresa (ebay.com) donde las bases de datos son enormes. No se supone que usemos ninguna integridad referencial en la base de datos. Esta restricción se estableció teniendo en cuenta el factor de rendimiento solo. Ni siquiera definiremos nada en el nivel ORM (Asignación relacional de objetos). Todo tiene que ser manejado lógicamente. Sé que es un poco difícil de imaginar, pero aún así es lo que proporciona un mejor rendimiento.

Ahora, para su pregunta, con demasiadas abstracciones sucediendo en el nivel de ORM, las personas ni siquiera se preocupan por lo que sucede en el lado de la base de datos. Por lo menos, los nuevos que salen de la codificación apenas se encargan de escribir disparadores, declarando la integridad referencial directamente en una base de datos (como Oracle) donde puedes hacer muchos lotes escribiendo los procedimientos de la tienda. Pero aún la gente prefiere y se siente más fácil codificar todo en el nivel ORM. Entonces, IMO, siento que se está convirtiendo en un viejo sombrero.

Answer 2

Creo que su último comentario sobre tener dos tiendas de datos es el futuro de la mayoría de las nuevas aplicaciones medianas que saldrán al mercado. Un backend con integridad referencial para cosas como conectar los componentes principales del sitio y otro para datos de escala de Internet más grandes.

Las compañías heredadas como eBay no deben usarse como una comparación ya que tienen los recursos para hacer un control de calidad riguroso y para pensar en las implicaciones de todo lo que hace el desarrollador. Una puesta en marcha típica de pequeña y mediana escala no tiene esos recursos y mantener los datos críticos en una tienda con integridad referencial evita que muchas fallas de la aplicación puedan permanecer en silencio en su sitio durante mucho tiempo.

Echa un vistazo a Django's support for multiple databases. Tenga en cuenta que pasar de un almacén de datos ACID a un almacén de datos CRUD es mucho más fácil que al revés.

Answer 3

Si desea asociar y consultar datos, la integridad referencial siempre será una preocupación válida. La pregunta moderna no es si es necesario, sino si se debe gestionar en la base de datos tradicional sql para validar campos de claves externas a través de índices administrados por programadores y administradores de bases de datos. Las bases de datos simples adaptadas al acceso a los objetos pueden ocultar los métodos tradicionales de integridad de datos o pueden permitir la gestión de problemas programáticamente como excepciones, o dichas preocupaciones se pueden gestionar de forma manual.

Dicho esto, los métodos tradicionales funcionan bien para la mayoría de aplicaciones (aunque aparentemente no eBay). La integridad referencial parece tonta hasta que tenga un problema de integridad que sea difícil de recuperar. Dado que es una implementación trivial, debe comenzar con ella y solo eliminarla cuando se vuelva aparente una necesidad de rendimiento que no pueda cumplirse por otros medios.

En cuanto a mongo, lo utilizan cuando se hace una aplicación más fácil de implementar y mantener. Definitivamente puede usar ambos si es necesario.

Answer 4

Creo que la otra cosa a considerar es el ciclo de vida de la tienda de aplicaciones y datos. Si el almacén de datos es útil para el negocio, es probable que tenga acceso a más de una aplicación y/o tenga interfaces con otros almacenes de datos. Cuanto más cerca de los datos se encuentre la integridad referencial, menos riesgos habrá de que una interfaz u otra cosa realice una mala actualización.

Y mientras la aplicación se está trabajando en ahora ahora pueden tener interfaces lo que alrededor de 7 años por la pista? (Aparentemente, la aplicación empresarial promedio se retiene durante 7 años) Cuando la empresa crezca, se usarán otras herramientas (por ejemplo, mediante implementación en el mismo negocio o mediante la adquisición de otro negocio)

Answer 5

Creo que la pregunta y la mayoría de las respuestas aquí parece decir lo mismo: la integridad de los datos (RI es solo un aspecto común de la integridad de los datos) definitivamente ES necesario y sigue siendo tan importante como siempre. La integridad de los datos es probablemente aún más importante hoy en día que en el pasado debido a las preocupaciones crecientes sobre el gobierno, la regulación y la protección de datos.

Sucede que las personas descubren que el DBMS no proporciona las instalaciones que necesitan, por lo que buscan implementar reglas de integridad en otros lugares. Esto es extraño, porque después de todo, el DBMS está más cerca de los datos y, por lo tanto, debería estar en la mejor posición para implementar reglas de negocios de manera eficiente. Las reglas declarativas deberían ser más fáciles de mantener y validar que las de procedimiento. Mantener las reglas centralmente en la base de datos también debería ser más rentable que distribuir las reglas en muchas otras capas y aplicaciones.

Mi conclusión es que si estas cosas no son que prueban ser ciertas para algunas personas, entonces eso realmente dice mucho acerca de las deficiencias del software de base de datos de hoy. Lo hace no implica que la integridad no es importante, sino todo lo contrario.