做了一年的大一年度项目了，对于关系型数据库结构还是有些了解了，有的时候还是觉得这种二维表不是很顺手。在看过一篇文章之后，对NoSQL有了初步的了解，（https://keen.io/blog/53958349217/analytics-for-hackers-how-to-think-about-event-data）。这篇文章写的很好，确实写出来了在实际情况下NoSQL的“用武之地”，而且用了MineCraft作分析，但是也许不够全面。比如文章中只是提到了，entity数据用关系型怎么存，event数据用NoSQL怎么存，我想借我这篇文章，来分析一下event类型的数据原始的关系型数据库是怎样存数据的，然后再对这两种储存方式做一种对比，算是对原文都一种补充吧。
对于这种死亡事件，有这样的两条数据，一个是关于creeper的爆炸，一种是掉进岩浆。如果必须用关系型二维表数据库，我会这样存储。（如果您还不知道是什么样的数据，可以先看之后的NoSQL储存方法，那样看起来更清楚。）
这种情况的数据可以说是数据库设计中比较复杂的一种情况了，因为它包含两种情况（当然不止这两种情况，那么就会产生更多的结构），不同情况的数据表结构是不同的，这非常麻烦。我们一般的解决方案是设计四个表格，利用关系型数据库的关系性。设计如下四张表格。（在这里我就简写了）
第一张表
|
1
2
3
4
5
6
|
id #首先用于关联，主表需要有个id，这个倒不是什么区别，因为NoSQL一般也会有个_id的预设 timestamp #所有共同部分就可以存在一张表中。 cause player_UID player_experience player_age #对于player_inveneory_id 因为这是一个可以任意长度的数组，又只能保存在另一个表中了 |
第二张表（用于保存creeper死亡方式的死亡事件的）
|
1
2
3
4
5
6
|
id #这是这张表的id以后可以跟别的表格关联 mid #用于关联主表 enemy_type enemy_power enemy_distance enemy_age |
第三张表（用于保存lava死亡方式的死亡事件的）
|
1
2
3
4
5
|
id #这是这张表的id以后可以跟别的表格关联mid #用于关联主表place_xplace_yplace_z |
第四张表（用于保存player_inveneory）
|
1
2
3
|
id #这是这张表的id以后可以跟别的表格关联mid #用于关联主表inveneory |
至此关系性数据库就将这种有不同结构的事件存放方式规定好了，接下来存放如下（我就不画表格了）
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
1. id timestamp cause player_UID player_experience player_age 1 "2013-05-23T1:50:00-0600" "creeper" "99234890823" 8873729 228 2 "2013-05-24T23:25:00-0600" "lava" "99234890823" 88737 222. id mid enemy_type enemy_power enemy_distance enemy_age 1 1 "creeper" .887 3.34 .66773. id mid place_x place_y place_z 1 2 45.366 -13.333 -39.2884. id mid inveneory 1 1 "diamend sword" 2 1 "torches" 3 2 "stone" |
至此，我们就用关系性数据库将这两个事件数据存下了。（好麻烦是吧！）
我们再看NoSQL的储存方法，因为每条数据并不受字段（列名）限制，完全可以直接保存，不用分表。（比如JSON格式）
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
#第一条数据{ "timestamp": "2013-05-23T1:50:00-0600", "cause":"creeper", "enemy":{ "type":"creeper" "power": .887 "distance_from_player":3.34 "age":.6677 }, "player": { "UID":"99234890823", "experience": 8873729, "age": 228, "inveneory":["diamend sword","torches"] }}#第二条数据{ "timestamp": "2013-05-24T23:25:00-0600", "cause":"lava", "place":{ x:45.366 y:-13.333 z:-39.288 } "player": { "UID":"99234890823", "experience": 88737, "age": 22, "inveneory":["stone"] }} |
下面我们分析NoSQL对这种数据存放方式的好处
1.首先是把分散的表结构整合了，让应该在一起的数据在一起了。
这就像C语言中开多个数组储存还是用一个结构体数组的区别，将一些有关系的数据放在一起是人类一种自然的想法，当然会让人更加舒服，而且可以提高关联性和升级扩展的简易程度。
2.存放变得方便
让我们来考虑有数据来了我们怎么储存。
对于二维表数据库：
1.分析数据是那种类型的
2.存放主表数据，并获得返回id
3.分支，加上主表id在不同情况下向lava或creeper表中存放数据
4.开循环，向inveneory表中插入多条记录
这还只是一个简述，还要考虑到对多个表格操作时的数据回滚问题，实际写起来30行左右，那么出错的可能就大大提高了。
对于NoSQL类型
一句话：
insert(data);#伪码
其实想想便知道，取数据时原来的关系性数据库也会同样麻烦。
3.NoSQL更利于动态生成存放方式，灵活性高了很多，至少我们可以在存放数据的时候再设计数据库了（虽然可能预先设计会好一些）
当然，如果存储的不是事件性或者类似此类数据那么就另当别论了，二维表还是有很多它本身的优势的。以上是我的一些个人的分析，当然还有很多普遍认同的观点，以下是一些普遍认同的关于两种数据库模式的优缺点分析，我也基本同意。
关系性优势：
1.事务处理---保持数据的一致性；
2.由于以标准化为前提，数据更新的开销很小（相同的字段基本上只有一处）；
3.可以进行Join等复杂查询。
关系型缺点：
1. 扩展困难：由于存在类似Join这样多表查询机制，使得数据库在扩展方面很艰难;
2. 读写慢：这种情况主要发生在数据量达到一定规模时由于关系型数据库的系统逻辑非常复杂，使得其非常容易发生死锁等的并发问题，所以导致其读写速度下滑非常严重;
3. 成本高：企业级数据库的License价格很惊人，并且随着系统的规模，而不断上升;
4. 有限的支撑容量：现有关系型解决方案还无法支撑Google这样海量的数据存储;
NoSQL优势，主要体现在下面几点：
1. 简单的扩展：典型例子是Cassandra，由于其架构是类似于经典的P2P，所以能通过轻松地添加新的节点来扩展这个集群;
2. 快速的读写：主要例子有Redis，由于其逻辑简单，而且纯内存操作，使得其性能非常出色，单节点每秒可以处理超过10万次读写操作;
3. 低廉的成本：这是大多数分布式数据库共有的特点，因为主要都是开源软件，没有昂贵的License成本;
NoSQL数据库还存在着很多的不足，常见主要有下面这几个：
1. 不提供对SQL的支持：如果不支持SQL这样的工业标准，将会对用户产生一定的学习和应用迁移成本;
2. 支持的特性不够丰富：现有产品所提供的功能都比较有限，大多数NoSQL数据库都不支持事务，也不像MS SQL Server和Oracle那样能提供各种附加功能，比如BI和报表等;
3. 现有产品的不够成熟：大多数产品都还处于初创期，和关系型数据库几十年的完善不可同日而语;
