其他分享
首页 > 其他分享> > 数据模型与查询语言

数据模型与查询语言

作者：互联网

数据密集型应用设计读书笔记第二章

速览了一遍，主要是搞明白一点：考虑清楚你的数据模型是怎么样的，从而考虑采用更合适的数据库。

传统上，使用SQL数据库的优点就是其处理多对多关系等复杂连接关系上比较优秀的能力，能够提供较为复杂的查询。

采用NoSQL数据库的背后有几个驱动因素，其中包括：

不同的应用程序有不同的需求，一个用例的最佳技术选择可能不同于另一个用例的最佳技术选择。因此，在可预见的未来，关系数据库似乎可能会继续与各种非关系数据库一起使用 - 这种想法有时也被称为混合持久化（polyglot persistence）。

 

举个例子，现在设计程序基本都是面向对象编程。而一个对象数据，想要插入到表中，往往需要一个转换层，模型之间的不连贯有时被称为阻抗不匹配（impedance mismatch）。

一般一个对象的数据是比较适合转换为JSON文档的，那么文档数据库对这种情况就有比较好的支持。（很多SQL数据库也支持在行中插入JSON文档并支持查询索引，所以其实也有混合持久化的趋势了）

 

当然像JSON文档这种存储数据的方式，有比较好的局部性（相关的数据会被存放在一块），但是缺乏对多对一关系和多对多关系的支持，而数据连接的增加随着业务开发、系统升级，这种需求有时是无法避免的。

支持文档数据模型的主要论据是架构灵活性，因局部性而拥有更好的性能，以及对于某些应用程序而言更接近于应用程序使用的数据结构。关系模型通过为连接提供更好的支持以及支持多对一和多对多的关系来反击。

 

另外，文档模型的架构存在着一些灵活性。

大多数文档数据库以及关系数据库中的JSON支持都不会强制文档中的数据采用何种模式。关系数据库的XML支持通常带有可选的模式验证。没有模式意味着可以将任意的键和值添加到文档中，并且当读取时，客户端对无法保证文档可能包含的字段。

文档数据库有时称为无模式（schemaless），但这具有误导性，因为读取数据的代码通常假定某种结构——即存在隐式模式，但不由数据库强制执行。一个更精确的术语是读时模式（schema-on-read）（数据的结构是隐含的，只有在数据被读取时才被解释），相应的是写时模式（schema-on-write）（传统的关系数据库方法中，模式明确，且数据库确保所有的数据都符合其模式）。
​
读时模式类似于编程语言中的动态（运行时）类型检查，而写时模式类似于静态（编译时）类型检查。就像静态和动态类型检查的相对优点具有很大的争议性一样，数据库中模式的强制性是一个具有争议的话题，一般来说没有正确或错误的答案。

什么时候读模式更有优势呢？

当由于某种原因（例如，数据是异构的）集合中的项目并不都具有相同的结构时,读时模式更具优势。例如，如果：

 

局部性的优点和注意

局部性仅仅适用于同时需要文档绝大部分内容的情况。数据库通常需要加载整个文档，即使只访问其中的一小部分，这对于大型文档来说是很浪费的。更新文档时，通常需要整个重写。只有不改变文档大小的修改才可以容易地原地执行。因此，通常建议保持相对小的文档，并避免增加文档大小的写入。这些性能限制大大减少了文档数据库的实用场景。

 

数据模型是一个巨大的课题，在本章中，我们快速浏览了各种不同的模型。我们没有足够的空间来详细介绍每个模型的细节，但是希望这个概述足以激起你的兴趣，以更多地了解最适合你的应用需求的模型。

在历史上，数据最开始被表示为一棵大树（层次数据模型），但是这不利于表示多对多的关系，所以发明了关系模型来解决这个问题。最近，开发人员发现一些应用程序也不适合采用关系模型。新的非关系型“NoSQL”数据存储在两个主要方向上存在分歧：

  1. 文档数据库的应用场景是：数据通常是自我包含的，而且文档之间的关系非常稀少。

  2. 图形数据库用于相反的场景：任意事物都可能与任何事物相关联。

这三种模型（文档，关系和图形）在今天都被广泛使用，并且在各自的领域都发挥很好。一个模型可以用另一个模型来模拟 — 例如，图数据可以在关系数据库中表示 — 但结果往往是糟糕的。这就是为什么我们有着针对不同目的的不同系统，而不是一个单一的万能解决方案。

文档数据库和图数据库有一个共同点，那就是它们通常不会为存储的数据强制一个模式，这可以使应用程序更容易适应不断变化的需求。但是应用程序很可能仍会假定数据具有一定的结构；这只是模式是明确的（写入时强制）还是隐含的（读取时处理）的问题。

另外仍旧有其他很多数据模型没有提到。

标签：数据库,模式,文档,查询语言,数据,模型,数据模型
来源： https://www.cnblogs.com/dongjl/p/15914386.html