数据库（表结构）设计技巧及注意事项

库设计：
1、数据库名称要明确，可以加前缀或后缀的方式，使其看起来有业务含义，比如数据库名称可以为Business_DB(业务数据库）。
2、在一个企业中，如果依赖很多产品，但是每个产品都使用同一套用户，那么应该将用户单独构建一个库，叫做企业用户中心。
3、不同类型的数据应该分开管理，例如，财务数据库，业务数据库等。
4、由于存储过程在不同的数据库中，支持方式不一样，因此不建议过多使用和使用复杂的存储过程。为数据库服务器降低压力，不要让数据库处理过多的业务逻辑，将业务逻辑处理放到应用程序中。

表设计：
1、  数据库表命名，将业务和基础表区分，采用驼峰表示法等。

2、  数据不要物理删除，应该加一个标志位，以防用户后悔时，能够恢复。还有就是比如人员登记加入某系统，采用登记卡的方式，一段时间后该人员退出了该系统，那么此时我们将该人员对应的记录标记为不可用，那么这个人就从系统中移除了，一段时间后这个人又回来了，那么我们直接修改标记字段为可用，这个人就从新加入系统，避免了其它信息的录入。

3、  数据是否有效的标示字段，其作用为：例如某条记录只有经过某个流程或者被某个人员审核通过后才有用，在这之前一直没有用。

4、  排序字段，按照某种类型来排序（sortcode）最好不依赖id排序，这样方便我们查询记录时按照某种方式排序，而不依赖id。

5、  数据是否允许删除和允许编辑，例如管理员不能删除，这样我们在查询数据时就可以根据该字段标示来决定某条记录是否可以编辑。而不用固化到代码中。

6、  增加备注字段，虽然我们考虑了很多用户需要输入信息的需求，但是无论何时我们都不可能考虑全，因此可以定义一个备注字段，允许用户将其它的信息填写在这里。无论表设计的再神奇，那么还是加一个备注字段。

7、  将记录创建人Id和记录创建人名字做为字段，这样看起来或许感到冗余有了Id还要名字干什么，使用住外键关联不就可以了吗，但是我们可以这样思考，如果只使用名字，那么人多了免不了名字重复，只使用id当然没有问题，但是我们查询时为了知道创建者的人名需要关联查询另外一张表，性能上不好，而且数据库看起来不是那么一目了然。并且创建人的名字也不是经常修改的。

8、  添加时间，有添加时间可以明确知道记录什么时候添加的。

9、  修改时间，可以知道记录什么时候被修改了，一旦数据出现问题，可以根据修改时间来定位问题。比如某人在这个时间做了哪些事。

10、             修改人id和名字，其作用就是标记谁对记录做了修改

11、             最后修改人

12、             最后修改时间

13、             记录所属公司id，方便我们查询只属于某个公司的记录

14、             记录所属部门id，方便我们查询只属于某个部门的记录

15、             记录所属工作组id，方便我们查询只属于某个工作组的记录

16、基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是

最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间

的目的。

17、若两个实体之间存在多对多的关系，则应消除这种关系。消除的办法是，在两者之间增加第三个实

体。这样，原来一个多对多的关系，现在变为两个一对多的关系。要将原来两个实体的属性合理地分配

到三个实体中去。这里的第三个实体，实质上是一个较复杂的关系，它对应一张基本表。一般来讲，数

据库设计工具不能识别多对多的关系，但能处理多对多的关系。

18、 主键PK的取值方法，PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串, 由程序自动加1来实现。也可

以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时，建议字段的个

数不要太多，多了不但索引占用空间大，而且速度也慢。

19、主键与外键在多表中的重复出现, 不属于数据冗余，这个概念必须清楚，事实上有许多人还不清楚

。非键字段的重复出现, 才是数据冗余！而且是一种低级冗余，即重复性的冗余。高级冗余不是字段的

重复出现，而是字段的派生出现。
〖例4〗：商品中的“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量”派生出

来的，它就是冗余，而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数

据的不一致性，因为同一数据，可能从不同时间、地点、角色上多次录入。因此，我们提倡高级冗余(派

生性冗余)，反对低级冗余(重复性冗余)。

20、中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与

外键(数据仓库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维

护，临时表由程序员自己用程序自动维护。

21、防止数据库设计打补丁的方法是“三少原则”
(1) 一个数据库中表的个数越少越好。只有表的个数少了，才能说明系统的E–R图少而精，去掉了

重复的多余的实体，形成了对客观世界的高度抽象，进行了系统的数据集成，防止了打补丁式的设计；
(2) 一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的

外键，所以组合主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间；
(3) 一个表中的字段个数越少越好。只有字段的个数少了，才能说明在系统中不存在数据重复，且

很少有数据冗余，更重要的是督促读者学会“列变行”，这样就防止了将子表中的字段拉入到主表中去

，在主表中留下许多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，另外单独建一

个子表。这个方法很简单，有的人就是不习惯、不采纳、不执行。
数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概

念，综合观点，不能孤立某一个原则。该原则是相对的，不是绝对的。“三多”原则肯定是错误的。试

想：若覆盖系统同样的功能，一百个实体(共一千个属性) 的E–R图，肯定比二百个实体(共二千个属性)

的E–R图，要好得多。
提倡“三少”原则，是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将

文件系统集成为应用数据库，将应用数据库集成为主题数据库，将主题数据库集成为全局综合数据库。

集成的程度越高，数据共享性就越强，信息孤岛现象就越少，整个企业信息系统的全局E—R图中实体的

个数、主键的个数、属性的个数就会越少。
提倡“三少”原则的目的，是防止读者利用打补丁技术，不断地对数据库进行增删改，使企业数据

库变成了随意设计数据库表的“垃圾堆”，或数据库表的“大杂院”，最后造成数据库中的基本表、代

码表、中间表、临时表杂乱无章，不计其数，导致企事业单位的信息系统无法维护而瘫痪。
“三多”原则任何人都可以做到，该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则

是少而精的原则，它要求有较高的数据库设计技巧与艺术，不是任何人都能做到的，因为该原则是杜绝

用“打补丁方法”设计数据库的理论依据。

22、在给定的系统硬件和系统软件条件下，提高数据库系统的运行效率的办法是：
(1) 在数据库物理设计时，降低范式，增加冗余, 少用触发器, 多用存储过程。
(2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条)，复杂计算要先在数据库外面，以

文件系统方式用C++语言计算处理完成之后，最后才入库追加到表中去。这是电信计费系统设计的经验。
(3) 发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。水平分割的做法是，

以该表主键PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过

八十个，则垂直分割该表，将原来的一个表分解为两个表。
(4) 对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数。
(5) 在使用面向数据的SQL语言进行程序设计时，尽量采取优化算法。
总之，要提高数据库的运行效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化

，这三个层次上同时下功夫。

主键设计：
1、不建议用多个字段做主键，单个表还可以，但是关联关系就会有问题，主键自增是高性能的。导入导出就有问题

2、一般情况下，如果有两个外键，不建议采用两个外键作为联合住建，另建一个字段作为主键。除非这条记录没有逻辑删除标志，且该表永远只有一条此联合主键的记录。

3、一般而言，一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。

主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与、外键的配对，表示实体之间的连接。

来自http://mushiming.top/mushblog/archives/207