是否有一个数据库可以提供参照完整性的好处,并且能够使用SQL类型语言进行查询,还可以根据数据属性以及它们之间的关系来松散地定义实体吗？
例如,采用RBAC类型模型,您可以在其中拥有权限,用户,用户组和角色.复杂/灵活的模型可以具有以下规则:
角色可以拥有一个或多个权限,权限可以属于一个或多个角色
用户可以拥有一个或多个权限,权限可以属于一个或多个用户
用户组可以拥有一个或多个权限,权限可以属于一个或多个用户组
用户可以拥有一个或多个角色,角色可以属于一个或多个用户
用户组可以具有一个或多个角色,角色可以属于一个或多个用户组
角色可以具有一个或多个角色,角色可以属于一个或多个角色
在RDBMS中对上述模型进行建模将涉及创建大量交集表.理想情况下,我想在数据库中定义的只是实体本身(用户,角色等)以及一些强制属性.其他所有内容都是动态的(即不需要DDL),例如,我可以创建一个具有未预定义的新属性的用户.我还可以在尚未预定义的实体之间创建关系,尽管数据库将像普通RDBMS一样处理引用完整性.
通过创建一个存储实体的表和另一个存储关系等的表,可以在某种程度上在RDBMS中实现上述目的,但这会过度复杂化执行简单查询所需的SQL,并且还可能具有性能影响.
大多数NoSQL数据库都可以很好地扩展.这是以一致性为代价的,参考完整性是其中的一部分.因此大多数NoSQL不支持任何类型的关系约束.
有一种类型的NoSQL数据库支持关系.事实上,它专为关系而设计:图形数据库.图数据库存储这些节点之间的节点和显式关系(边).节点和边都可以包含键/值对形式的数据,而不依赖于预定义的模式.
图形数据库针对关系查询和漂亮的图形操作进行了优化,例如查找两个节点之间的最短路径,或查找距当前节点给定距离内的所有节点.在角色/权限场景中你不需要这个,但如果你这样做,使用RDBMS实现起来要困难得多.
另一个选择是通过使用RDBMS存储关系和文档数据库来存储实际数据,使整个数据层成为混合.这会使您的应用程序稍微复杂化,但我认为这不是一个糟糕的解决方案.您将使用两种不同的技术,既处理它们旨在处理的问题.
根据您在问题中指定的要求,图形数据库可能是您正在寻找的类型,但还有其他选项.正如@Niels van der Rest所说,"没有先验架构"和"参照完整性"的两个限制很难调和.您可能能够找到可能这样做的基于主题地图的数据库,但我不熟悉具体的实现,所以我无法肯定地说.
如果你认为你真的离不开参照完整性,我担心你可能会陷入RDBMS.你可以使用一些技巧来避免你预期的一些问题,我在/sf/ask/17360801/中介绍了一些...,这可能会给你一些想法.对于这种需要动态的,先验后的模式的数据模型,使用元模式元素,RDBMS总是很尴尬.
如果您愿意放弃参照完整性,那么您仍然需要考虑三种方法.
Map/Reduce - 有两种形式:分布式记录导向(思考,MongoDB)和列导向(想想,Cassandra).Scales真的很好,但你不会有类似SQL的语法; 加入吮吸; 并将您的架构与特定查询类型相匹配至关重要.在你的情况下你专注于实体及其属性,而不是实体本身之间的关系,所以我可能会考虑一个分布式记录导向的商店; 但是,只有当我预计需要扩展到单个节点之外时 - 它们确实非常好地扩展.
文档存储 - 从技术上讲有两种形式,但其中一种是上面讨论的面向分布式记录的map/reduce数据存储.另一个是倒指数(想想,Lucene/Solr).不要忽视倒指数的力量; 他们可以非常快速地解决猥亵复杂的记录谓词.他们不能做的就是处理好包含相关或大关系连接的查询.不过,你会惊讶于令人难以置信的灵活性,足够复杂的记录谓词给你.
图形存储 - 有几种形式,第一种是大规模的临时键值存储(想想,DBM/TokyoTyrant); 第二个是元组空间(想想,Neo4j); 第三个是RDF数据库(想想,Sesame/Mulgara).我对RDF有一个软肋,帮助开发了mulgara,所以我不是最客观的评论者.但是,如果您的可伸缩性约束允许您使用RDF存储,我发现RDF的指称语义允许的推理(在noSQL数据存储选项中很少见)是非常宝贵的.
一些NoSQL解决方案支持安全性和SQL.其中之一是OrientDB.安全系统在这里得到了很好的解释.
此外还支持SQL.
京公网安备 11010802040832号 | 京ICP备19059560号-6 