论数据的组织与存储

不同时间，人对数据的理解也不同。如何组织数据？用什么结构存储？

Stage 1

在最初的认识中，数据是以二维表形式组织的，比如：

Stage 2

接触数据库后，二维表正好能对应数据库的表，一个数据库中有多个表。 把二维表的行看成x，列看成y，那么数据库又多了一个维度z。

通过外键，表与表之间增加了约束，这样表之间就不是单独存在，而是相互依赖的了，字段之间建立起了联系，有利于数据引用的准确性。 这个阶段中，我在dms中大量使用了外键，例如log表的user_name字段的外键为 user表的 user_name字段，如下图所示:

Stage 3

sams也是用的传统的关系型数据库，但是在接触Json和面向对象的思想后，能感觉到关系型数据库的局限：

• 一方面，数据的联系是靠不同表的字段对应起来，一个relation就要涉及到两张表，对数据进行操作也要将两张表进行连接，有没有别的数据存储方法呢？
• 另一方面，数据的组织、提取要徒手写SQL语句，有其它简单的方法吗？（不可否认的是，标准SQL为不同的RDBMS提供了操作数据的统一接口）

对于后者的需求，ORM的出现解决了这个问题，它把数据转化为对象看待，在程序逻辑里操作对象就可以了，剩下的SQL语句由ORM代劳。

对于前者的需求，一种方案是面向文档的数据库，在关系型数据库中，键-值存储中“值”的部分，存储的是单纯的字符串；而面向文档的数据库“值”的部分是拥有结构的文档，文档的内容可以查询。典型代表如MongoDB。 还有一种方案是面向对象的数据库，它将面向对象语言中的对象直接进行永久保存。

Stage 4

在进入云计算时代后，数据库服务器成为了云计算系统的瓶颈，有很多场景只是需要通过键来获取值这样简单的操作，并不一定要动用RDB。
在这样的背景下，就出现了只管理键值对并将数据保存在内存中的缓存系统memcached。

数据库中的数据大多放在磁盘上，当对数据库进行查询时，操作开销很大，而memcached将查询结果缓存在内存中，这样可以提高性能。