原文：http://chaochaoblog.com/archives/1745
对于信息管理类的程序来说，一个系统就是一个信息库。在大量的信息中为了索引、区别，最好的办法就是用数据库。然而建立一个简洁、高效、全面的数据库却并不简单。一个优秀的数据库无疑能够帮助程序员减少业务逻辑操作，减少出错的可能性；而一个糟糕的数据库设计会在需要添加功能的时候无从扩展，或是大量的冗余造成性能的瓶颈。
因此，建立一个优秀的数据库，设计好每一张表格变成了尤为重要的事情。然而，很多的问题考虑起来就非常的复杂和繁琐，且需要对系统的深彻把握和对程序代码的经验积累。但是我认为最好的方式还是“综合考虑，利弊权衡。”
如何开始你的数据库设计？
也许你是拿到任务就开始建立表了，user表、product表等等。一张一张的完成，倒是很有速度也很有成就感，但是这绝对是最差的做法。因为你面向的对象是一个系统，而对付这一个系统的时候，你就需要好好思考了。
对于数据库而言，最简单的理解方式：数据库就是一个系统，表就是它的对象，而字段即是它的属性。一个确保数据库事务正确执行的四个基本要素是：
(1) 原子性。基本表中的字段是不可再分解的。 (2) 原始性。基本表中的记录是原始数据（基础数据）的记录。 (3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。 (4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。
基本的原则我们是需要遵照执行的，然而作为一个系统来考虑的话我们不得不考虑其整体的架构了。
就软件开发而言，这些年来比较热门的当数“领域驱动设计”了。2004年著名建模专家Eric Evans发表了他最具影响力的书籍:《Domain-Driven Design Tackling Complexity in the Heart of Software》(中文译名：领域驱动设计软件核心复杂性应对之道)，书中提出了领域驱动设计(简称 DDD)的概念。
DDD基于面向对象分析与设计技术，对技术架构进行了分层规划，同时对每个类进行了策略和类型的划分。因此“领域驱动设计”能够指导面向对象开发人员、系统分析人员和设计人员合理地组织工作，各有侧重、彼此协作，有条不紊地进行复杂系统的开发，帮助他们建立丰富而实用的领域模型，并由此创建长期适用的优质软件。
按我的理解“领域驱动设计”即是为业务专家和编程人员建立了一座沟通的桥梁，一种有效的操作手段和方法，其核心还是领域建模。
这种思想自然是有他的借鉴之处，我们按照“领域驱动设计”的思想建立了一个个独立的事物类，不同类之间能够通过各种映射相互影响的话，那么我们的数据库的设计最好的方式是基于这些功能类的设计方法和准则，而不是基于业务和系统了，这样做的最大好处区分的独立子系统能够很好的考虑其效率、冗余等各方面的问题了。
范式设计？
为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。在实际开发中最为常见的设计范式有三个：
1．第一范式(确保每列保持原子性)
2．第二范式(确保表中的每列都和主键相关)
3．第三范式(确保每列都和主键列直接相关,而不是间接相关)
按照范式设计的数据库最大的好处就是确保了数据库不会冗余，结构简单、稳定。但是，同时带来的问题就是性能的下降，比如我们有一张表记录了一条数据，其中有一个字段是用户的ID，并且大部分时候这张表的业务只需要显示用户的名称，至于用户的密码、邮箱等信息都不需要显示，那么在这张表中你会加入用户名称这个字段么？
这实际上是讨论的最多的“关联”还是不关联的问题了，很多人说：“当然关联，不关联叫什么关系型数据库？；但是我也见过一些公司做的项目完全不关联的，所有的表都是独立的表的。
关联的好处：
1、整洁、简单，独立性强。从整个系统来看，虽然关联多出了不少表格，但是每张表都是独立的，很好的维护了整个系统的简洁性。
2、将部分逻辑业务交给了DBA，在数据库接口层注重的是sql查询语句的编写，上层业务开发人员可以省下不少力气。
3、由于关联的字段都是用主键进行查询的，减少了出错的可能性。再者，不关联的表的记录的更改可能会涉及到多张表格的同步问题，处理不好也容易出错。
4、关联的表多用到sql语句来完成业务与逻辑，而不关联的表可能要上层程序本身负担一部分逻辑判断的任务，这样子混乱的逻辑与烦杂的判断，则需要多次封装继承。因此关联还是降低了程序员出错的可能性。
关联的坏处：
1、反复的查询一张固定的表，造成资源的重复浪费，降低了性。
2、查询一条记录需要查询两张或者以上的表，造成执行时间的延长，降低了服务器的性能，降低了用户的体验。
3、关联造成的多个外键、连接一定程序上增加了系统的复杂性。
那么到底该不该关联，是部分不关联还是完全不关联？究竟要不要完全的按照范式来设计我们的数据库？这原本就是一个见仁见智的问题。从功能模块出发，从全局出发，找到综合处理该问题的平衡点才是最终的王道吧。
NoSQL还是关系型数据库？
关系型的数据模型定义了高度结构化的数据结构，以及对这些结构之间关系的严格定义。通过这些年的发展，关系型数据库已经提供了相当强大的复杂操作功能，但是由此也引发了一些问题：
1、负载不确定性。使用SQL的一个问题就是计算某个查询的代价或者产生的负载几乎是不可能的。使用简单的查询语言可能会导致应用层的逻辑更复杂，但是这样可以将存储系统的工作简单化，让它只需要响应一些简单的请求。
2、模型严格性。对一个问题建模有很多种方式。其中关联型的数据模型是非常严格的一种：表结构的定义规定了表中每一行数据的存储内容。如果你的数据结构化并没有那么强，或者对每一行数据的要求比较灵活，那可能关联型的数据模型就太过严格了。类似的，应用层的开发人员可能对关联型的数据结构并不满意。比如很多应用程序是用面向对象的语言写的，数据在这些语言中通常是以列表、队列或集合的形式组织的，程序员们当然希望他们的数据存储层也能和应用层的数据模型一致。
3、性能瓶颈。当数据量增长到一台机器已经不能容纳，我们需要将不同的数据表分布到不同的机器。而为了避免在不同机器上的数据表在进行联合查询时需要跨网络进行。我们必须进行反范式的数据库设计，这种设计方式要求我们把需要一次性查询到的数据存储在一起。这样做使得我们的系统变得就像一个主键查询系统一样，于是我们开始思考，是否有其它更适合我们数据的数据模型。
“NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字，而真正现在所说的“NoSQL”概念是2009年提出来的。NoSQL最常见的解释是“non-relational”，顾名思义，NoSQL系统的数据操作接口应该是非SQL类型的。但在NoSQL社区，NoSQL被赋予了更具有包容性的含义，其意为Not Only SQL，即NoSQL提供了一种与传统关系型数据库不太一样的存储模式，这为开发者提供了在关系型数据库之外的另一种选择。
1、扩展性。NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。
2、高性能。NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。
3、灵活的数据模型。NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。
4、高可用性。NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。
截止到今天，虽然还没有成熟的NoSQL平台出现，但是像百度、腾讯这种性能要求极高，数据量极大地企业都已经部署了NoSQL的存储平台。就NoSQL来讲，目前应用的还不是很广泛，但是在web2.0中产生了大概这三种模式：
1、以NoSQL为主。
2、SQL与NoSQL的相互融合。
3、以NoSQ架构作为缓存。
按照现有的趋势来讲，一个数据量极大的系统，部署“云计算”是迟早的事情。一方面“云计算”解决了性能瓶颈，另外一方面降低了硬件要求，这在互联网免费的时代，无疑对互联网公司有着致命的诱惑力。也许我们很难清楚我们该部署怎样的一个平台，使用怎样一种模式，但是当我们仔细的分析我们的现实情况、仔细研究现有的成熟模式之后，一定会找到自己的理想的存储平台。
