数据库设计时需考虑的因素
设计数据库时需遵守的几个原则
•三个范式
•满足当前需求
•分离主体与附属
•适当的冗余
•应对可能出现的新需求
•应对大数据量
三个范式
第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；
第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；
第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。
参考：http://www.cnblogs.com/knowledgesea/p/3667395.html
满足当前需求
数据结构的设计要能达到应用场景的要求，这是最基本的。举个例子，文章的正文存储在了数据表中的某个字段，该字段的长度被设定为10000字，在文章字数没有被限制在10000字以内的前提下，这显然不能满足应用场景的当前需求。需要考虑，什么样的字段类型才能存储大规模的文本数据？
分离主体与附属
文章页面中的元素，哪些是主体部分，哪些是附属部分？
一篇文章可以没有评论，评论的有无、多少不影响文章本身的完整性，评论可以被添加、删除。由此可见，文章的评论属于附属部分。阅读次数、喜欢该文章的用户与数量同样如此。
主体
•作者
•标题
•正文（字数）
•发布时间
•更新时间
附属
•阅读次数
•评论
•喜欢该文章的用户与数量
拆分的好处在于，首先数据结构更清晰了，其次可以提高读写性能。当文章有了新评论，只需更新存放评论的表。如果不拆分，需要更新的记录占用的磁盘空间很大，这对磁盘IO速度是个考验。
适当的冗余
或许你已经注意到了，文章的标题下面有这篇文章的字数。计算文章的字数，有两个时机：
•保存文章时
•读取文章时
后者的优势在于数据表中少了一个字段，而且这个字段不是必需的。哪个时机更好？个人觉得前者更好，理由如下
•计算长篇文章的字数是比较耗时的，应尽量减少计算次数
•总体来看，文章的保存次数远小于读取次数
如果能够提高应用的性能，适当的冗余是必要的。
页面的头部有文章作者的昵称，这适合作为冗余字段存储在文章主体数据中吗？用户可以随时更改自己的昵称，如果将昵称作为冗余字段，需要额外的工作以保持数据一致性，从这一点看，用户昵称不适合作为冗余字段。
应对可能出现的新需求
如何存储喜欢文章的用户信息才能做智能推荐？一个好的数据结构应该能应对可能出现的新需求。
为了达到应用的要求，最简单的方式是将这些用户放在一条记录里，存储的字段可以是数组类型。这样设计，喜欢文章的用户信息与用户数量都能轻易获取，读写性能也很好。但对于“喜欢该文章的人还喜欢了”此类的智能推荐，这样的设计明显是难以应对的。将用户放在数组里支持“查询喜欢某文章的用户”，对“查询某用户喜欢的文章”的支持就很差或者根本做不到了，这是一种单向查询的数据结构。
应对大数据量
随着用户量不断增加，网站业务数据越来越多，文章数量也达到了百万级。这时如果只把文章存在一张数据表里，读写性能必然是会急剧下降的，这可能会导致用户体验变差，用户流失。老板不能容忍，DBA也不能容忍。
合理的解决方案之一是分为两张数据表，一张存储热门文章，另一张存储非热门文章。热门文章的占比很少，相应的加载速度就会好于非热门文章。
参考：
http://www.jianshu.com/p/4cdb59716483
https://zhidao.baidu.com/question/921197548485724819.html
http://www.2cto.com/database/201501/367171.html