对于懂得软件project的人来说，标题就是一句废话，没有需求分析。哪来的设计？软件设计和实现中，开发人员往往会在不知不觉中忽略用户的需求，站在开发人员的角度，依照自己的意愿去设计软件。
相同在为系统设计数据库的时候，也存在类似的现象，或许你设计的数据库满足三范式的原则。并且很灵活，可是用户方的负责人一看就知道这样的严格依照理论设计的数据库是不能用的，会给带来好多问题，尤其是性能方面的。
那么应该如何去考虑数据库的设计呢？个人理解的是，应该以理论知识为基础，以需求为导向进行数据库的设计，不能仅仅是将系统的实体抽象出来，然后依照三范式的理论进行设计，而全然不考虑系统在实际使用中面临的问题。换句话说就是站在使用者的角度去看待数据库的设计。
近期在设计机房收费系统的数据库。比較迷茫，所以就广泛的阅读博客。好多人都有自己的理解，在看到高玮师哥的实习感悟，顿时有点感觉了。
机房收费系统的数据库怎样设计临时不谈，先来看一个样例：近期学校正在搞“校园一卡通”的项目，期望将学生使用的饭卡和银行卡绑定。为学生充值提供便利，这样你就不用去ATM机排半天队，取出现金。完了再跑到食堂排半天队才干充上钱，直接用手机银行和网上银行就能搞定。在办理一卡通之前。须要核对个人信息。我核对的时候将屏幕的信息用手机拍了下来，方便以后查阅，我们就以一卡通的信息为例，谈谈数据库的设计。
一卡通的信息主要有这么几项：卡号、姓名、学号、性别、民族、剩余金额、国籍、手机号、部门（专业班级等）、身份证号、银行卡号，假设让你为这个系统设计数据。你会怎么考虑？
以我个人的理解，能够抽象出这么几个实体：学生、饭卡、身份证和银行卡，然后我们将上述信息依照第一范式的原则给他们归类：
学生：学号、姓名、部门、手机号
饭卡：卡号、姓名、剩余金额
身份证：身份证号、姓名、性别、民族、国籍
银行卡：卡号、姓名、剩余金额
这是对一卡通屏幕显示的信息的一个分析，去略微还原一下数据库的结构，可能仅仅是部分的信息。可是不影响我们说明问题，一卡通的后台数据库我也接触不到。所以仅仅能这么琢磨了。
在核对信息的时候，我们仅仅需将饭卡贴在自助终端的射频区域就可以显示所有信息。因此饭卡号是一个主键，我的个人信息缺了手机号。在加入的时候仅仅需提供身份证就可以，将我的个人信息所有找出。说明身份证号也是一个主键。
假设以上面的数据库表的结构，怎样通过我的身份证号查找和改动我的手机号呢？你或许会想到使用数据库的联合查询，即joinkeyword，让学生表的姓名等于身份证的姓名。就可以查出我的手机号。可是重名问题怎么解决？多个人的姓名一模一样，怎么精确定位？
两种办法，一种是在身份证的表中加入学号的字段，由于学号是唯一的。还有一种是将学生表和身份证表合并，身份证号作为学生信息的一部分，合并两个表中的的“同类项”（即反复信息）。那种办法好呢。更贴近需求呢？
我个人认为另外一种号，两点原因。第一，身份证的信息里加入一个学号，总认为别扭，不符合自然认知。第二，合并表之后。就不须要联合查询。在海量数据查询中的效率会快非常多。身份证号作为学生信息的一部分，比較合适，况且能够消灭数据冗余。
如今你想想为什么我们之前用的机房收费系统的学生信息会和卡的信息在一张表中了吧。或许有他们自己的道理，总之在设计数据库的时候，应该让需求来引导设计，不要仅仅是单纯的去考虑什么范式和原则等这些理论知识。应该以实际应用为出发点。在实际工作中，数据库的设计目标不是最正确。而是最优化。