选择关系型or非关系型数据库？
规范的数据结构 & 千万条以下的数据，关系型够用了（这么粗暴的结论会不会被打？2333）
写这篇时碰上ohmyzsh更新，放图镇楼，之后要抽时间认真研究下这个东西的用法（扔进待办事项flag
需求
我需要录入2年的数据，关于每一节课的信息，以2小时为一单位。这样的数据无法设立主键，因为没有唯一值。但列出一列来计数又没有任何意义，因为这列主键不能和任何教师信息、校区信息等链表查询，提升查询速度还是要靠索引和视图。
目前使用数据库的主要目的是连表做一些简单的计算操作，比如整个fy16财年的老生生均，40w＋的数据在excel中匹配由学员编号＋教师组别＋学科组等组成的唯一列，运算非常慢，同时还需要对某两列去重，每一步这样的操作都需要复制粘贴出一个新的sheet进行操作。以后的话希望能和python结合可以有新的模型预测一些数据，比如fy17财年各教学组的任务分配、奖金方案等。
上学时简单的学了sql server，做完作业就扔一边了。那时对非关系型数据库只是几分钟带过，现在要重新梳理下两种数据库的优劣，找出最合适业务数据（以下称为目标数据）的数据库。
两种数据库对比
- 存储方式：数据表VS数据集
关系型：表格式，容易提取
非关系型：数据集的形式，像文档、键值或图结构
目标数据都是表格式的，除个别值，总体比较规范。
- 表结构：预定义结构VS动态结构
关系型：每列在建立表头时固定数据类型
非关系型：动态结构
目标数据的大部分列是固定的数据类型，文本、数字、日期。
- 存储规范化VS存储代价
关系型：遵循数据规范性，数据拆分为最小的逻辑表
非关系型：存储为一个整体
这是目前关系型最大的问题，目标数据需要可以重复的存在，拆分导入的成本很高，不拆分又体现不出关系型的一些优势。
- 纵向扩容VS横向扩容
关系型：纵向扩展提高处理能力，相同数据集速度更快。
非关系型：横向扩展，可以添加节点来分担负载。
关系型表中提高的处理能力体现在多表操作时，如果目标数据本身就是一个大表，这个优势就没啥意义了吧？不是很明白非关系型数据库通过资源池添加更多普通数据库服务器（节点）的意义（应该是概念问题
- 结构化查询VS非结构化查询
关系型：sql非常好用，索引非常好用
非关系型：unQL?
unQL需要深入了解一下……
- 映射VS本地化
关系型：ORM层(对象关系映射)是位于关系型数据源和开发者使用的面向对象数据实体之间的一个映射层。
非关系型：应用程序中使用的对象通常序列化为JSon串，存储在NoSQL数据库的JSon文档中
不懂的两项内容，需要查询下ORM是否可以解决主键的问题。
- 事务性VS纯扩展性
关系型：高事务型或复杂数据查询
非关系型：操作的扩展性和大数据量处理
目标数据还远算不上大数据，数据库中的事务具体指什么？
- ACID VS CAP
关系型：ACID属性(原子性，一致性，隔离性，持久性)保证数据完整性
非关系型：在CAP(一致性，可用性，分区容忍度)中的任意两项中选择，因为在基于节点的分布式系统中，很难做到三项都满足。
嗯，不懂CAP
- 数据VS大数据
关系型：规范的存储处理数据
非关系型：无模式的方式做数据管理
选择关系型
比较明确了，目标数据这么点简单内容还用不上NoSQL，然后看看orm吧～
附：NoSQL的更多信息[引自参考]
CAP定理
在计算机科学中, CAP定理（CAP theorem）, 又被称作 布鲁尔定理（Brewer’s theorem）, 它指出对于一个分布式计算系统来说，不可能同时满足以下三点:
一致性(Consistency) (所有节点在同一时间具有相同的数据)
可用性(Availability) (保证每个请求不管成功或者失败都有响应)
分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。
因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
NoSQL 数据库分类
| 类型 | 部分代表 | 特点 |
|---|---|---|
| 列存储 | Hbase Cassandra Hypertable | 顾名思义，是按列存储数据的。最大的特点是方便存储结构化和半结构化数据，方便做数据压缩，对针对某一列或者某几列的查询有非常大的IO优势。 |
| 文档存储 | MongoDB CouchDB | 文档存储一般用类似json的格式存储，存储的内容是文档型的。这样也就有有机会对某些字段建立索引，实现关系数据库的某些功能。 |
| key-value存储 | “Tokyo Cabinet/Tyrant Berkeley DB MemcacheDB Redis | 可以通过key快速查询到其value。一般来说，存储不管value的格式，照单全收。（Redis包含了其他功能） |
| 图存储 | Neo4J FlockDB | 图形关系的最佳存储。使用传统关系数据库来解决的话性能低下，而且设计使用不方便。 |
| 对象存储 | db4o Versant | 通过类似面向对象语言的语法操作数据库，通过对象的方式存取数据。 |
| xml数据库 | Berkeley DB XML BaseX | 高效的存储XML数据，并支持XML的内部查询语法，比如XQuery,Xpath。 |
btw:markdown自带的表格真的难用暴了，列宽不能设置，最后用了html= =以后还是做图片吧～