数据库设计原则与方法

1. 原始单据与实体之间的关系

可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单据对应多个实体，或多张原始单据对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。

〖例1〗：一份职工履历资料，在人力资源信息系统中，就对应三个基本表：职工基本情况表、社会关系表、工作简历表。这就是“一张原始单据对应多个实体”的典型例子。

2. 主键与外键

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

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

3. 基本表的性质

基本表与中间表、临时表不同，因为它具有如下四个特性：

(1) 原子性。基本表中的字段是不可再分解的。

(2) 原始性。基本表中的记录是原始数据〔基础数据〕的记录。

(3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。

(4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。

理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。

4. 范式标准

基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，到达以空间换时间的目的。

一、命名要简洁，并体现其应用或功能。如库名BxxCRM，Bxx为公司简称，CRM为Crm系统中的主数据库；为了防止被分析破解，表名建议采用子系统简写＋功能单词首字母，如BOM子系统中：BOMMD，该表的字段名为MD001，MD002......MD022并预留五到十字段供扩展，对常用表还应定义十个以上的自定义字段，供客户自定制，自定义字段统一命名UDF01...UD99。表和字段都应该在数据字典作标准，实际开发时，用向导从数据字典生成具体应用数据绑定窗口和控件。

二、与第一条相关，在开发应用之前，一定必须先输入数据字典。这条是血泪教训（之前我的SB老板，我制定了一些标准，那Sb不执行不重视，现在公司快倒了吧！这是题外话）。没有字典，维护和表的共用都是问题，且直接影响开发效率！而且开发框架一般都和数据字典集成的！

三、嵌套关系的数据表，一定要在数据字典中注明，并备注好关键字段。注意这里嵌套并不一定是主从表。如工单表，一个成品对应一张工单，该成品由N个半成品制成，又是N张工单，N个半成品可能又可细分若干层的半成品。一般就由单头单身表二个表表示这样的数据，也可用一张表。

四、数据字典的设计，表和视图都必须记录在字典中；其对应的触发器和存储过程也必须备注中对应的表中；表、视图必须按模块分类管理。

五、严格控制存储过程的使用，这是血泪教训呀，我们公司的HR有600多个存储过程，三四个人二三批维护修正了十个月都没完全搞定。这就是开发时的随意和图修改方便造成的恶果，那个别人开发的HR在我看来是垃圾，我都不碰那个东西。建议，除非大数据量的处理，则不用存储过程！业务逻辑封装到程序业务类中，或将SQL语句放在配置文件或数据库中，动态装入执行。

六、尽量少用自增长字段，有人不以为然，认为自增长字段在表的数据量巨大时速度快。但它不稳定，特别是D7中支持不是太好，而且处理麻烦。更有甚者是其更新的问题，及需要读写该字段的值时更是麻烦，所以建议还是不用为妙。遇到大数据表时，多设计几个关键字段和索引应该问题不大！ [ 注：在甲骨文数据库中，根本就不须自增长字段，因为它的每个表都有辅助列！]

数据库设计的基本原则

数据库设计是一个非常重要的环节，它直接关系到整个系统的稳定性和数据的完整性。因此，在进行数据库设计时，需要遵循一些基本原则。

1. 数据库设计应该符合企业的需求

在进行数据库设计之前，首先需要了解企业的需求。只有深入了解企业的运营模式、业务流程以及数据结构，才能够设计出符合企业需求的数据库。因此，在进行数据库设计之前，需要与相关人员进行充分沟通和交流。

2. 数据库设计应该具有可扩展性

随着企业发展和数据量增加，数据库也需要不断地进行扩展和升级。因此，在进行数据库设计时，需要考虑到未来可能出现的需求，并为其预留足够的空间。

3. 数据库设计应该具有高效性

在实际应用中，我们希望能够快速地对数据进行查询、修改和删除等操作。因此，在进行数据库设计时，需要考虑到查询效率、索引建立以及表结构等方面。

4. 数据库设计应该具有安全性

在信息化时代，数据安全已经成为了一个非常重要的问题。因此，在进行数据库设计时，需要考虑到数据安全方面的问题，并采取相应措施来保护数据安全。

5. 数据库设计应该具有一致性

在进行数据库设计时，需要保证数据的一致性。这意味着，在多个表之间建立正确的关系，避免出现数据冗余和数据不一致等问题。

6. 数据库设计应该具有易用性

在进行数据库设计时，需要考虑到用户的使用习惯和操作方式，并为其提供简单、易用的界面和操作方式。这样可以提高用户的使用效率和满意度。

7. 数据库设计应该具有可维护性

在实际应用中，我们可能需要对数据库进行维护和升级。因此，在进行数据库设计时，需要考虑到维护方面的问题，并采取相应措施来简化维护工作。

总之，数据库设计是一个非常复杂而又重要的环节。只有遵循上述基本原则，并根据企业实际需求进行合理设计，才能够建立一个稳定、高效、安全、易用和可维护的数据库系统。

数据库主键设计的原则与方法

在数据库设计过程中，主键的设计是至关重要的一步。主键的选择会影响数据库的性能和数据完整性。因此，本文将介绍数据库主键设计的原则与方法，以帮助读者更好地理解和应用主键设计。

1. 原则一：唯一性

主键必须具有唯一性，即每条记录的主键值必须是唯一的。这样可以确保数据库中不存在重复的数据，避免数据冗余和不一致性。常用的实现唯一性的方法包括自增长字段、全局唯一标识符（GUID）等。

2. 原则二：稳定性

主键的值应该是稳定的，不会频繁发生变化。主键的变化会引起相关数据的变动，增加数据库维护的复杂度和成本。因此，最好选择一个与业务逻辑无关、不会经常改变的属性作为主键。

3. 原则三：简洁性

主键的设计应该简洁明了，避免过于复杂的组合字段作为主键。复杂的主键设计会增加数据库的存储空间和查询的复杂度，影响数据库的性能。通常情况下，使用一个字段作为主键已经足够满足大部分需求。

4. 原则四：不可空性

主键的值不应该为空，它应该在插入新记录时必须有值。空主键将导致数据库无法保证记录的唯一性和一致性。如果数据库中某些记录没有主键值，可以考虑使用自增长字段或者默认值作为主键。

5. 方法一：自增长主键 自增长主键是最常用的主键设计方法之一。数据库会自动为每条新插入的记录分配一个唯一的主键值，无需手动指定。这种主键设计简单方便，且能够确保唯一性。

6. 方法二：组合主键

在某些情况下，使用一个字段作为主键可能无法满足需求。可以考虑使用多个字段组合作为主键，称之为组合主键。组合主键要求多个字段的组合值在整个表中唯一。

7. 方法三：全局唯一标识符（GUID）

全局唯一标识符（GUID）是一个128位的二进制数，通常以字符形式呈现。GUID保证在全球范围内的唯一性，适用于分布式系统。可以将GUID作为主键，确保数据在不同数据库之间的唯一性。

8. 方法四：业务相关字段

在某些情况下，可以使用业务相关字段作为主键。例如，对于一个学校的学生表，可以使用学生的学号作为主键。此种方法可以方便地根据业务需求对记录进行查找和查询。