【发布时间】:2011-11-24 10:08:42
【问题描述】:
再次,对不起我的愚蠢问题,但似乎我从关系数据库中学到的东西应该被“删除”,没有连接,那么我到底将如何在 NoSql 中使用 Merise 和 UML 绘制?
http://en.wikipedia.org/wiki/Class_diagram
这个不适用于 NoSql 吗?
【问题讨论】:
再次,对不起我的愚蠢问题,但似乎我从关系数据库中学到的东西应该被“删除”,没有连接,那么我到底将如何在 NoSql 中使用 Merise 和 UML 绘制?
http://en.wikipedia.org/wiki/Class_diagram
这个不适用于 NoSql 吗?
【问题讨论】:
您如何组织项目是用于持久性的技术的独立概念;特别是; UML 或 ERD 或任何此类工具并不特别适用于关系数据库,就像它适用于文档数据库一样。
NoSQL 具有“无连接”的想法既愚蠢又无益。 (大多数)文档数据库不提供连接运算符是完全正确的。但这只是意味着当您确实需要连接时,您可以在应用程序代码中而不是查询语言中进行操作;组织项目的基本事实保持不变。
另一个区别是文档数据库使表达某些东西更容易,而另一些则更难。例如,关系数据库中的实体关系约束通常更容易,但在文档数据库中表示继承层次结构更容易。两种技术都可以支持这两种概念,当您的应用程序需要它们时,您肯定会使用它们;不管你最终使用的是什么技术。
简而言之,您应该在设计应用程序之前先不选择持久性技术。一旦你对你想要坚持的东西有了一个很好的想法,你可能会更好地了解哪种技术更适合。可能你真正需要的是两者,或者你可能需要完全不同的东西。
编辑:外键的想法并不比简单地说“这是那种东西的名字”更神奇。碰巧许多 SQL 数据库提供了一些非常简洁和有用的特性来处理这类事情;具体来说,约束(此列引用此其他关系;因此除非引用中存在相应的行,否则它不能取值)和级联,(如果引用的状态发生变化,则对引用进行相应的更改)。这确实使得即使在最低级别也可以轻松保持数据的一致性,因为无法告诉数据库进入缺少所指对象的状态。
要区分的重要一点是,提供数据库实体(关系数据库中的行,文档数据库中的文档)的想法与模式约束的概念不同。文档数据库的优点之一是它们可以轻松地组合或重新定位数据所在的位置,这样您就不必总是拥有实际存在的引用对象;大多数文档数据库使用文档类作为键的一部分,因此您仍然可以确定键是有意义的,即使所指对象实际上并不存在。
但大多数时候,您实际上确实希望所指对象存在;您不希望博客文章有作者,除非该作者确实存在于您的系统中。对此的支持程度在很大程度上取决于特定的文档数据库。一些数据库确实提供触发器或其他工具来强制引用的完整性,但许多其他数据库只提供某种事务能力,这需要在应用程序中强制执行完整性。
重点是;对于大多数类型的数据库,数据库中的每个值都有一些种标识符;在关系数据库中,这是一个三元组的关系:列:键;在文档数据库中,它通常类似于 document_class:path 对。当您需要一个实体来引用另一个实体时,您可以使用任何类型的键来识别该数据库的数据。在 RDBMses 中发现的外键约束只是(非常有用的)语法糖,用于“如果不存在引用,则引发 ForeignKeyError”,如果这对您的特定用途有帮助,可以以其他方式以同等的能力实现。
【讨论】:
rowid,表中每一行的唯一ID;许多其他人具有可选的自动增量功能,有些需要您发明一个关键结构,GUID 是推荐的解决方案。