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

nosql mongodb (5)

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

Por ejemplo, tome un modelo de tipo RBAC donde tenga permisos, usuarios, grupos de usuarios y roles. Un modelo complejo / flexible podría tener las siguientes reglas:

Los roles pueden tener uno o más permisos y un permiso puede pertenecer a uno o más roles
Los usuarios pueden tener uno o más permisos y un permiso puede pertenecer a uno o más usuarios
Los grupos de usuarios pueden tener uno o más permisos y un permiso puede pertenecer a uno o más grupos de usuarios
Los usuarios pueden tener uno o más roles y un rol puede pertenecer a uno o más usuarios
Los grupos de usuarios pueden tener uno o más roles y un rol puede pertenecer a uno o más grupos de usuarios
Los roles pueden tener uno o más roles y un rol puede pertenecer a uno o más roles

Modelar lo anterior en un RDBMS implicaría la creación de muchas tablas de intersección. Idealmente, todo lo que me gustaría definir en la base de datos son las entidades mismas (Usuario, Rol, etc.) más algunos atributos obligatorios. Todo lo demás sería dinámico (es decir, no se requiere DDL), por ejemplo, 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 ha sido predefinida, aunque la base de datos manejaría la integridad referencial como un RDBMS normal.

Lo anterior se puede lograr hasta cierto punto en un RDBMS mediante la creación de 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 en el rendimiento.

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

Además soporta SQL.

Dados los requisitos que especifica en su pregunta, una base de datos gráfica es probablemente el tipo de cosa que está buscando, pero hay otras opciones. Como dijo @Niels van der Rest, las dos restricciones de "esquema a priori" e "integridad referencial" son muy difíciles de reconciliar. Es posible que pueda encontrar una base de datos basada en Topic-Map que pueda hacerlo, pero no estoy familiarizado con implementaciones específicas, por lo que no puedo asegurarlo.

Si decide que realmente no puede prescindir de la integridad referencial, me temo que probablemente esté atascado con un RDBMS. Hay algunos trucos que puedes usar que podrían evitar algunos de los problemas que anticipas, cubro un par en https://.com/questions/3395606... , lo que podría darte algunas ideas. Aún así, para este tipo de modelo de datos que requiere un esquema dinámico, posterior a priori, con elementos de esquema meta, un RDBMS siempre será incómodo.

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

Mapa / Reducir - en dos versiones: distribuido orientado a registros (think, MongoDB) y orientado a columnas (think, Cassandra). Las escalas 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 su caso, su enfoque en las entidades y sus atributos, en lugar de las relaciones entre las mismas entidades, por lo que probablemente consideraría una tienda distribuida orientada a registros; pero solo si esperaba tener que escalar más allá de un solo nodo, realmente escalan muy bien.
Document-store: técnicamente en dos versiones, pero una de ellas es un mapa de datos / reducir de datos orientado a registros distribuidos que se mencionó 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 sorprendentemente rápidos. Lo que no pueden hacer es manejar bien las consultas que incluyen correlación o uniones relacionales grandes. Aún así, se sorprenderá de la increíble flexibilidad que le brindan los predicados de registros lo suficientemente complejos.
Graph-store: en algunos sabores, el primero es el almacén de valor-clave ad-hoc a gran escala (think, DBM / TokyoTyrant); el segundo es el espacio de la tupla (piense, Neo4j); el tercero es la base de datos RDF (piense, Sesame / Mulgara). Tengo un punto débil para RDF, al haber ayudado a desarrollar mulgara, por lo que no soy el comentarista más objetivo. Sin embargo, si sus restricciones de escalabilidad le permiten usar una tienda RDF, encuentro que la inferencia permitida por la semántica de denotación de RDF (rara entre las opciones de almacenamiento de datos noSQL) es invaluable.

Es posible que desee revisar MongoDB , es una base de datos basada en documentos y por lo tanto tiene un esquema flexible. Es increíble y vale la pena ver si se ajusta a sus necesidades.

Existe el lenguaje Gremlin , soportado por la base de datos del gráfico Neo4j . Con respecto a su ejemplo, eche un vistazo a las listas de control de acceso de la base de datos de gráficos y here . También hay una herramienta basada en web que incluye una API REST para Neo4j y una consola Gremlin, consulte neo4j/webadmin .

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. Así que la mayoría de los NoSQL no admiten ningún tipo de restricciones relacionales.

Hay un tipo de base de datos NoSQL que soporta relaciones. De hecho, está diseñado especialmente para las relaciones: la base de datos gráfica . Las bases de datos de gráficos almacenan nodos y relaciones explícitas (bordes) entre estos nodos. Tanto los nodos como los 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 gráficas ingeniosas, como encontrar la ruta más corta entre dos nodos o encontrar todos los nodos a una distancia determinada del nodo actual. No necesitaría esto en una situación de rol / permiso, pero si lo hace, será mucho más difícil lograr el uso de un RDBMS.

Otra opción es hacer que toda su capa de datos sea un híbrido, utilizando un RDBMS para almacenar las relaciones y una base de datos de documentos para almacenar los datos reales. Esto complicaría un poco su aplicación, 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.