作为程序员，程序设计前的数据库设计非常重要，这将直接关系到紧接着的代码编写工作，这里谈谈有关数据库设计过程中的一些细节问题。
一．数据表主键的字段选择（ID,Code,Number）
ID（编号）一般是选择GUID，这种格式的字符串是一串全球唯一的字符串。当程序需要调用不同平台上的相同结构的数据库时，建议使用guid来作为主键。这样做的好处是，当在某一平台上汇总不同平台的数据时，同一表中的数据汇总不会出现因为主键相同而无法正常汇总的情况。Code（编码）一般是一串非全数字的字符串，比如字母混合数字格式的字符串。特别是，在设计存在多级关联关系的对象模型时。比如人员部门结构，商品多级分类等树状结构关系的对象模型时（见下图）。
如上图所示的部门结构，在数据库中设置一个部门的编码Code，结构如图中加色的数字。这样做的好处是可以很容易根据这样的编码来取到部门的信息。比如，要获取分局3（0103）下面所属的所有所一级的人员信息，则可截取表中部门编码的前四位，判断其是否等于0103，这样即可获得分局3下面所有所一级的部门编码，再从人员信息表中读取人员信息就非常简单了。Number（序号）一般用在标识记录需要连续计数时，通常是系统自增长生成或者程序自动生成得到。比如某一实物存在多个时，可以使用序号来进行区分。比如图书馆中，一模一样的图书存在多本的时候，可以用一个序号来区别。同时，这样还可以很直观的看出这个对象有多少个相同的个体记录，前提是数据未删除过。设计数据库的时候可以根据具体的情况加以选择，从而达到事半功倍的效果。
二．空间换时间的思想
当一张主表和多张从表存在主外键关系时，通常的做法是在主表中存取从表记录的主键信息。这样读取信息的时候，就需要联合两张以及两张以上的表进行数据读取和组合得到我们需要的信息。数据库思想中，有提到数据库设计应尽可能避免数据冗余，这样可以节省数据存储所占的空间。但是，在当今社会。硬件技术飞快发展的年代，存储介质的存储空间已经可以越来越大，基本不用考虑数据库占用的问题。尽管存储介质的发展很快，但是电脑的处理速度却难以跟上。所以，设计数据库的时候，尽可能考虑怎么使得操作能够快速响应，以节省用户等待的时间。这就是空间换时间的思想。比如说，主表中需要存储用户表中的用户姓名，用户表数据量很大，那么可以考虑在主表中直接存储用户的姓名而不是保存用户信息记录的主键信息。这样，只查询主表即可得到我们需要的信息，而不需要再去联合用户表去查询了。当然，这里也不是通用的做法，有几点需要注意。首先这个涉及从表的字段应该是基本上不会再和其他的业务过程产生联系的，比如我只需要在查询的时候显示这个名字而不需要对其再错查询或者修改等其他一系列的业务操作。另外呢，这个数据需要作为历史记录去查阅，那么就尽可能存储信息本体而不是信息本体所在表记录的主键了。否则，当从表信息修改之后，再次查询记录的时候就会发现与实际情况不符的情况。比如某家公司的快递寄送人是公司的前台，但是前台总会有人事变动，人不在，但是工号还在，会移交给新人使用。那么记录寄件人的信息时就直接保存寄件人的姓名。有时候，我们还会选择将从表的主键以及信息主体直接存储在主表中。比如保存用户的名字同时存储用户的工号。这样，在检索的时候就可以根据工号直接得到主表信息，同时得到用户的工号和姓名。虽然这样做存在数据冗余的情况，但是为了查询的效率，这样做未尝不是一种好办法。
最后，提一下。数据库的设计应该以实际情况为主，理论为辅，兼顾执行效率。不同情况下，这些做法不一定都适合，具体情况具体分析吧。
本文出自 “摇曳的风筝” 博客，请务必保留此出处http://pinzi.blog.51cto.com/4845903/1603837
原文地址：http://pinzi.blog.51cto.com/4845903/1603837
