大数据时代-使用关系型数据库的价值意义？
不知道大家有没有这种经历：一个系统刚上线的时候是有完整的架构逻辑的，数据库表的设计也是经过精细推敲，以为可以经得起时间的考验。结果呢？上线之后各种新业务支持、新需求支持。不得不在原有的数据表中添加字段，一张表最后扩展到五六十个字段。甚至要建立几个ext（扩展）字段，把用下划线分割或者干脆一个json对象塞进去，像极了自家的衣柜。
这时候，甚至让人产生怀疑：当时技术选型是不是选错了？使用了关系型数据库表建立了一套结构化数据，最终数据塞的太多，失去了意义。对我来说简直就是key-value嘛，为什么要用关系型数据库嘞？
以下是本人对这个问题的思考。
按结构分类的体系结构
结构化数据
定义
业界指关系模型数据，即以关系数据库(RDBMS)表形式管理的数据
简析
虽然专业角度上看，结构化就是关系模型的说法并不准确，但针对目前业内现状，还是定义为关系模型最为妥善，因为它准确的代表了我们传统上最熟悉的企业业务数据。
半结构化数据
定义
非关系模型的、有基本固定结构模式的数据，例如日志文件、XML文档、JSON文档、Email等。
解析
严格讲，结构化与半结构化数据都是有基本固定结构模式的数据。但是关系型数据的结构更加严谨，可进行排序和计算等。而半结构化数据已经是大数据领域的范畴了。
非结构化数据
定义
没有固定模式的数据，如WORD、PDF、PPT、EXL，各种格式的图片、视频等。
简析
区分半结构化与非结构化的意义在于，对两者的处理方法是不同的。对于非结构化数据，现在的大数据处理方法基本也就是当个磁带用，存储一下。需要的时候按照id给调用出来。高级一点的就是搜索引擎，分个词，按照关键词给调出来。
结论：在业界，希望数据是结构化的，目前最成熟的还是关系型数据库存储。
OLTP与OLAP
数据处理大致可以分成两大类：联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。
OLTP
是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易、订单处理。
OLAP
是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
现在联机分析处理的内容主要还是采集的结构化数据，半结构化数据都很少。有人说现在分析技术很牛X呀？什么AI人工智能啊。大家有没有听说人工智能的更精确表述：人工智障。AI除了作为一个中性的名词之外，还是一个贬义词，比如AI演技。
不过从选择行业的角度看，AI还是很有前途的。将来说不定可以做出神盾局特工里的Aida那样的超级机器人，只是千万要给她植入正确的观念，不要以摧毁世界为己任。
两者比较
结论：在业界，希望OLTP操作，关系型数据库仍是首选。
NoSQL
定义
非关系型数据库（NoSQL =not only sql ），是对不同于传统的关系型数据库的数据库管理系统的统称。一般是分布式的，且一般不保证遵循 ACID 原则的数据存储系统。
RDBMS vs NoSQL
RDBMS
高度组织化结构化数据
结构化查询语言（SQL）：数据操作语言，数据定义语言
数据和关系都存储在单独的表中
严格的一致性
基础事务
NoSQL
没有声明性查询语言
没有预定义的模式
键 - 值对存储，列存储，文档存储，图形数据库
最终一致性，而非ACID属性
非结构化和不可预知的数据
CAP定理
高性能，高可用性和可伸缩性
结论：在业界，希望严格的一致，关系型数据库仍是第一选择。
数据库表与程序设计Q&A
RDBMS对程序设计提了很高的要求，强制在设计阶段想明白很多东西，不然数据表结构是设计不出来的：需要存储哪些字段，字段是什么类型，是否需要关联触发器、两个表之间是什么关系……所以有了如UML建模这种建模工具，来建立概念模型和物理模型。
Q：用了关系型数据库却基本用不到关系型运算，那使用关系型数据库还有价值吗？
A：关系型运算是指选择、投影、连接、除法、外连接等。现在业界越来越不推荐直接在OLTP程序里使用join来连接表了，尽量使用单表操作。用的最多的还是选择，简单理解就是select+where的查询语句。业界也不推荐在OLTP程序中使用过于复杂的查询条件。
那是不是关系型数据库的优势就发挥不出来了呢？咱们这么想这件事情哈。现在数据库资源非常宝贵，所以为了保护数据库资源现在有很多措施：比如优先走缓存，再比如把刚才说的不推荐的join和复杂查询改用搜索引擎来做。
这里的搜索引擎呢数据来源还是关系型数据库。试想有个支付系统，在OLTP程序里完成了实时交易。数据都落到了关系型数据库中。商家想在后台看看自己今天的交易流水，这个就很合适将数据库中的数据采集到搜索引擎当中。商家查询时展示的是搜索引擎的结果。试想，搜索引擎的结果不是从关系型数据库中得来的，而是来源于key-value形式的nosql呢？那中间还要加一层数据处理，这个处理要做的事情就是把数据处理成结构化数据。那直接存在关系型数据库里就好了呀。
有的朋友就说了现在我们就是只做OLTP，这些后台查询都没有。可是现在没有不代表将来没有。有很多需求不是专门的需求人员提出来的，而是我们技术人员围绕着资源自己挖掘出来的，技术引领业务嘛！
Q：怎样技术引领业务呢？
A：我非常建议大家找工作的时候第一看重的是公司和项目的前景和发展。有不错的业务量，有不错的增长。数据就是引领业务的钥匙。这就涉及到另外一个问题：数据要尽量满足范式的要求，让数据是简洁的、明晰的。
ext（扩展）字段，把用下划线分割或者干脆一个json对象塞进去，我是不建议的。我建议把字段定义清楚，该用关联子表的用子表。用子表从目前的业务上讲虽然处理上复杂些，开发可能会稍微减慢。但是从长远来看，现在可以放成一坨的数据，将来都是要分析的。如果现在定义清楚了，将是一笔宝贵的资源。