具有引用完整性的 NoSQL/RDBMS 混合（删除级联）？
是否有一种数据库可以为您带来引用完整性的好处并能够使用 SQL 类型语言进行查询，同时还可以松散地定义实体的数据属性以及它们之间的关系？
例如，采用 RBAC 类型模型，其中您拥有权限、用户、用户组和权限。角色。复杂/灵活的模型可以具有以下规则：
- 角色可以拥有一个或多个权限，并且权限可以属于一个或多个角色
- 用户可以拥有一个或多个权限，并且权限可以属于一个或多个用户
- 用户组可以拥有一个一个或多个权限，一个权限可以属于一个或多个用户组
- 用户可以拥有一个或多个角色，一个角色可以属于一个或多个用户
- 用户组可以拥有一个或多个角色，一个角色可以属于一个或多个用户组
- 角色可以拥有一个或多个角色，并且一个角色可以属于一个或多个角色。
在 RDBMS 中对上述内容进行建模将涉及创建大量交集表。理想情况下，我想在数据库中定义的只是实体本身（用户、角色等）加上一些强制属性。其他一切都将是动态的（即不需要 DDL），例如我可以创建一个具有未预定义的新属性的用户。我还可以在尚未预定义的实体之间创建关系，尽管数据库会像普通 RDBMS 一样处理引用完整性。
在 RDBMS 中，可以通过创建一个表来存储实体和另一个表来存储关系等来在某种程度上实现上述目标，但这会使执行简单查询所需的 SQL 过于复杂，并且还可能会影响性能。
Is there a database out there that gives you the benefit of referential integrity and being able to use a SQL type language for querying, but also lets entities be loosely defined with respect to their data attributes and also the relationships between them?
E.g. take a RBAC type model where you have Permissions, Users, User Groups & Roles. A complex/flexible model could have the following rules:
- Roles can have one or more permissions and a permission can belong to one or more Roles
- Users can have one or more permissions and a permission can belong to one or more Users
- Users Groups can have one or more permissions and a permission can belong to one or more Users Groups
- Users can have one or more roles and a role can belong to one or more Users
- User Groups can have one or more roles and a role can belong to one or more User Groups
- Roles can have one or more roles and a role can belong to one or more Roles
To model the above in an RDBMS would involve the creation of lots of intersection tables. Ideally, all I'd like to define in the database is the entities themselves (User, Role, etc) plus some mandatory attributes. Everything else would then be dynamic (i.e. no DDL required), e.g. I could create a User with a new attribute which wasn't pre-defined. I could also create a relationship between entities that hasn't been predefined, though the database would handle referential integrity like a normal RDBMS.
The above can be achieved to some degree in a RDBMS by creating a table to store entities and another one to store relationships etc, but this overly complicates the SQL needed to perform simple queries and may also have performance implications.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
大多数 NoSQL 数据库都是为了很好地扩展而构建的。这是以一致性为代价的，而引用完整性是一致性的一部分。因此大多数 NoSQL 不支持任何类型的关系约束。
有一种类型的 NoSQL 数据库确实支持关系。事实上，它是专门为关系而设计的：图形数据库。图数据库存储节点以及这些节点之间的显式关系（边）。节点和边都可以包含键/值对形式的数据，而无需绑定到预定义的模式。
图形数据库针对关系查询和漂亮的图形操作进行了优化，例如查找两个节点之间的最短路径，或查找距当前节点给定距离内的所有节点。在角色/权限场景中您不需要这样做，但如果需要，使用 RDBMS 实现起来会困难得多。
另一种选择是使整个数据层成为混合层，使用 RDBMS 来存储关系，并使用文档数据库来存储实际数据。这会使您的应用程序稍微复杂化，但我不认为这是一个糟糕的解决方案。您将使用两种不同的技术，两者都可以处理它们旨在处理的问题。
Most NoSQL databases are built to scale very well. This is done at the cost of consistency, of which referential integrity is part of. So most NoSQL don't support any type of relational constraints.
There's one type of NoSQL database that does support relations. In fact, it's designed especially for relations: the graph database. Graph databases store nodes and explicit relations (edges) between these nodes. Both nodes and edges can contain data in the form of key/value pairs, without being tied to a predefined schema.
Graph databases are optimized for relational queries and nifty graph operations, such as finding the shortest path between two nodes, or finding all nodes within a given distance from the current node. You wouldn't need this in a role/permission scenario, but if you do, it'll be a lot harder to achieve using an RDBMS.
Another option is to make your entire data layer a hybrid, by using a RDBMS to store the relations and a document database to store the actual data. This would complicate your application slightly, but I don't think it's such a bad solution. You'll be using two different technologies, both dealing with the problems they were designed to deal with.
考虑到您在问题中指定的要求，图形数据库可能就是您正在寻找的东西，但还有其他选择。正如 @Niels van der Rest 所说，“无先验模式”和“引用完整性”这两个约束很难调和。您也许能够找到一个基于主题图的数据库可以做到这一点，但我不熟悉具体的实现，所以我不能肯定地说。
如果您认为没有引用完整性确实无法实现，那么我担心您可能会陷入 RDBMS 的困境。您可以使用一些技巧来避免您预期的一些问题，我在 https://stackoverflow.com/questions/3395606...，这可能会给您一些想法。尽管如此，对于这种需要动态、后先验模式和元模式元素的数据模型，RDBMS 总是会很尴尬。
如果您愿意放弃引用完整性，那么您仍然可以考虑三种方法。
Map/Reduce - 有两种风格：面向分布式记录（例如 MongoDB）和面向列（例如 Cassandra）。扩展性确实非常好，但是您不会拥有类似 SQL 的语法；加入很糟糕；将您的架构与特定查询类型相匹配至关重要。在您的情况下，您关注的是实体及其属性，而不是实体本身之间的关系，因此我可能会考虑分布式面向记录的存储；但只有当我期望需要扩展到单个节点之外时——它们确实能够很好地扩展。
文档存储 - 从技术上讲有两种风格，但其中一种是上面讨论的分布式面向记录的映射/归约数据存储。另一种是倒排索引（想想 Lucene/Solr）。不要忽视倒排索引的力量；他们可以以惊人的速度解决极其复杂的记录谓词。他们不能很好地处理包含相关性或大型关系连接的查询。尽管如此，您还是会对令人难以置信的灵活性和足够复杂的记录谓词给您带来的惊喜感到惊讶。
图形存储 - 有几种风格，第一种是大规模的临时键值存储（例如 DBM/TokyoTyrant）；第二个是元组空间（想想 Neo4j）；第三个是 RDF 数据库（例如 Sesame/Mulgara）。我对 RDF 情有独钟，曾帮助开发过 mulgara，所以我不是最客观的评论者。尽管如此，如果您的可扩展性限制允许您使用 RDF 存储，我发现 RDF 的指称语义（在 noSQL 数据存储选项中很少见）允许的推理是非常有价值的。
Given the requirements you specify in your question, a graph database is probably the sort of thing you are looking for, but there are other options. As @Niels van der Rest said, the two constraints of "no a priori schema" and "referential integrity" are very hard to reconcile. You might be able to find a Topic-Map based database that might do so, but I'm not familiar with specific implementations so I couldn't say for sure.
If you decide you really can't do without referential integrity, I fear you probably are stuck with an RDBMS. There are some tricks you can use that might avoid some of the problems you anticipate, I cover a couple in https://stackoverflow.com/questions/3395606..., which might give you some ideas. Still, for this sort of data-model requiring dynamic, post-priori schema, with meta-schema elements, an RDBMS is always going to be awkward.
If you are willing to forgo referential integrity, then you still have three approaches to consider.
Map/Reduce - in two flavours: distributed record-oriented (think, MongoDB), and column-oriented (think, Cassandra). Scales really really well, but you won't have your SQL-like syntax; joins suck; and matching your architecture to your specific query types is critical. In your case your focus on the entities and their attributes, rather than the relationships between the entities themselves, so I would probably consider a distributed record-oriented store; but only if I expected to need to scale beyond a single node—they do scale really really well.
Document-store - technically in two flavours, but one of them is a distributed record-oriented map/reduce datastore discussed above. The other is an inverted-index (think, Lucene/Solr). Do NOT disregard the power of an inverted-index; they can resolve obscenely complex record predicates amazingly fast. What they can't do is handle well is queries that include correlation or large relational joins. Still, you will be amazed at the incredible flexibility, sufficiently complex record predicates gives you.
Graph-store - come in a few flavours the first is the large-scale, ad-hoc key-value store (think, DBM/TokyoTyrant); the second is the tuple-space (think, Neo4j); the third is the RDF database (think, Sesame/Mulgara). I have a soft-spot for RDF, having helped develop mulgara, so I am not the most objective commenter. Still, if your scalability constraints will permit you to use an RDF-store, I find the inferencing permitted by RDF's denotational semantics (rare amongst noSQL datastore options) invaluable.
一些 NoSQL 解决方案支持安全性和 SQL。其中之一是 OrientDB。 此处对安全系统进行了（相当）详细的解释。
此外还支持SQL。
Some NoSQL solutions support security and SQL. One of these is OrientDB. The security system is (quite) well explained here.
Furthermore supports SQL.
有 Gremlin 语言，由 Neo4j 图数据库。关于您的示例，请查看 访问控制列出了图数据库方式和此处。还有一个基于 Web 的工具，包括 Neo4j 的 REST API 和 Gremlin 控制台，请参阅 neo4j/webadmin 。
There's the Gremlin language, supported by the Neo4j graph database. Regarding your example, have a look at Access control lists the graph database way and here. There's also a web-based tool including a REST API to Neo4j and a Gremlin console, see neo4j/webadmin.
您可能想查看 MongoDB 它是一个基于文档的数据库，因此具有灵活的架构。它太棒了，值得花时间看看它是否能满足您的需求。
You may want to check out MongoDB it is a document based database and so has a flexible schema. It is awesome and worth the time to see if it would suite your needs.