NoSQL/RDBMS híbrido con integridad referencial (eliminar cascada)?

Question

¿Existe una base de datos que le brinde el beneficio de la integridad referencial y pueda utilizar un lenguaje de tipo SQL para consultas, pero también permite que las entidades se definan libremente con respecto a sus atributos de datos y también las relaciones entre ellos?

E.g. tome un modelo de tipo RBAC donde tenga permisos, usuarios, grupos de usuarios & Roles. Un modelo complejo/flexible podría tener las siguientes reglas:

• roles pueden tener uno o más permisos y autorización pueden pertenecer a una o varias funciones
• Los usuarios pueden tener uno o más permisos y autorización pueden pertenecer a uno o más usuarios
• Usuarios Los grupos pueden tener uno o más permisos y autorización puede pertenecer a uno o más grupos de usuarios de
• Los usuarios pueden tener una o más funciones y una función puede pertenecer a uno o más usuarios
• usuario Los grupos pueden tener uno o más roles y un rol puede pertenecer a correos o más Grupos de Usuarios
• roles pueden tener uno o más papeles y un papel pueden pertenecer a una o varias funciones

Para modelar lo anterior en un RDBMS implicaría la creación de un montón de mesas de intersección. Idealmente, todo lo que me gustaría definir en la base de datos son las propias entidades (Usuario, Rol, etc.) más algunos atributos obligatorios. Todo lo demás sería dinámico (es decir, no se requiere DDL), p. Podría crear un usuario con un nuevo atributo que no estaba predefinido. También podría crear una relación entre entidades que no se haya predefinido, aunque la base de datos manejará la integridad referencial como un RDBMS normal.

Lo anterior se puede lograr hasta cierto punto en un RDBMS creando una tabla para almacenar entidades y otra para almacenar relaciones, etc., pero esto complica demasiado el SQL necesario para realizar consultas simples y también puede tener implicaciones de rendimiento.

Answer 1

La mayoría de las bases de datos NoSQL están diseñadas para escalar muy bien. Esto se hace a costa de la coherencia, de la que forma parte la integridad referencial. Entonces, la mayoría de los NoSQL no admiten ningún tipo de restricciones relacionales.

Hay un tipo de base de datos NoSQL que admite relaciones. De hecho, está diseñado especialmente para las relaciones: el graph database. Las bases de datos de gráficos almacenan nodos y relaciones explícitas (bordes) entre estos nodos. Ambos nodos y bordes pueden contener datos en forma de pares clave/valor, sin estar vinculados a un esquema predefinido.

Las bases de datos de gráficos están optimizadas para consultas relacionales y operaciones de gráficos ingeniosos, como encontrar la ruta más corta entre dos nodos o encontrar todos los nodos dentro de una distancia dada desde el nodo actual. No lo necesitaría en un escenario de rol/permiso, pero si lo hace, será mucho más difícil lograrlo utilizando un RDBMS.

Otra opción es hacer que toda su capa de datos sea híbrida, utilizando un RDBMS para almacenar las relaciones y una base de datos de documentos para almacenar los datos reales. Esto complicaría su aplicación un poco, pero no creo que sea una solución tan mala. Utilizará dos tecnologías diferentes, ambas relacionadas con los problemas para los que fueron diseñadas.

Answer 2

Hay Gremlin el lenguaje, con el apoyo de la base de datos Neo4j gráfico. En cuanto a su ejemplo, eche un vistazo a Access control lists the graph database way y here.También hay una herramienta basada en web que incluye una API REST para Neo4j y una consola Gremlin, consulte neo4j/webadmin.

Answer 3

Teniendo en cuenta los requisitos que especifica en su pregunta, una base de datos de gráficos es probablemente el tipo de cosa que está buscando, pero hay otras opciones. Como dijo @Niels van der Rest, las dos limitaciones del "esquema no a priori" y la "integridad referencial" son muy difíciles de conciliar. Es posible que pueda encontrar una base de datos basada en Topic-Map que pueda hacerlo, pero no estoy familiarizado con las implementaciones específicas, así que no podría decirlo con certeza.

Si decide que realmente no puede prescindir de la integridad referencial, me temo que probablemente esté atascado con un RDBMS. Hay algunos trucos que puede usar que podrían evitar algunos de los problemas que anticipa, cubro un par en https://stackoverflow.com/questions/3395606..., que podría brindarle algunas ideas. Sin embargo, para este tipo de modelo de datos que requiere un esquema dinámico, post-priori, con elementos de meta-esquema, un RDBMS siempre será incómodo.

Si está dispuesto a renunciar a la integridad referencial, entonces todavía tiene tres enfoques a considerar.

1. Mapa/Reducir - en dos sabores: orientado a registros distribuido (pensar, MongoDB), y orientada a columnas (pensar, Cassandra). Escala realmente muy bien, pero no tendrá su sintaxis similar a SQL; se une a chupar; y hacer coincidir su arquitectura con sus tipos de consulta específicos es fundamental. En tu caso, tu enfoque en las entidades y sus atributos, más que en las relaciones entre las entidades mismas, entonces probablemente consideraría una tienda distribuida orientada a registros; pero solo si esperaba necesitar escalar más allá de un solo nodo, se escalan realmente realmente bien.

2. Almacén de documentos: técnicamente en dos formas, pero una de ellas es un almacén de datos distribuido/orientado a registros distribuidos que se discutió anteriormente. El otro es un índice invertido (piense, Lucene/Solr). NO ignore el poder de un índice invertido; pueden resolver predicados de registro obscenamente complejos increíblemente rápido. Lo que no pueden hacer es manejar bien las consultas que incluyen correlación o grandes uniones relacionales. Aún así, se sorprenderá de la increíble flexibilidad que le ofrecen los predicados de registro suficientemente complejos.

3. Graph-store: en algunos casos, el primero es el almacén ad-hoc de gran valor y clave (think, DBM/TokyoTyrant); el segundo es el espacio de tuplas (piense, Neo4j); el tercero es la base de datos RDF (creo, Sesame/Mulgara). Tengo un punto débil para RDF, habiendo ayudado a desarrollar mulgara, así que no soy el comentarista más objetivo. Sin embargo, si sus restricciones de escalabilidad le permitirán usar un almacenamiento RDF, creo que la inferencia permitida por la semántica denotacional de RDF (rara entre las opciones de almacenamiento de datos no SQL) es invaluable.

Answer 4

Es posible que desee comprobar hacia fuera MongoDB es una base de datos de documentos y por lo tanto tiene un esquema flexible. Es impresionante y vale la pena el tiempo para ver si satisface sus necesidades.

Answer 5

Algunas soluciones NoSQL admiten seguridad y SQL. Uno de estos es OrientDB. El sistema de seguridad está (bastante) bien explicado here.

Además es compatible con SQL.