数据库系列（一）基本知识

数据库系列（一）基本知识

1 数据库设计PowerDesigner&三大范式
2 命名风格、主键选择、外键、存储过程
3 触发器、游标、视图、自定义函数，字段类型、字段可空、统计字段、逻辑删除

1 数据库设计PowerDesigner&三大范式

三大范式只是建议，其实都可能被违背
为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。
在实际开发中最为常见的设计范式有三个：

1．第一范式(确保每列保持原子性)

第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。
第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。

2．第二范式(确保表中的每列都和主键相关)

第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

3．第三范式(确保每列都和主键列直接相关,而不是间接相关)

第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。
比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。

2 命名风格、主键选择、外键、存储过程

2.1 命名风格：

大写字母的模块缩写，不要下划线(避免映射)，英文单词，首字母大写拼音/汉字完全反对

2.2 主键：

主键只是唯一标识，主键一般对用户没有意义；主键最好单例，提升查询效率；
复合索引(mapping/几个外键组合)，永不更新，数据不要变化；最好由计算机生成！
主键生成方案选择：
自增ID : 数据库自动增加，int/bigint，sqlserver默认聚集索引，空间小，可以有业务意义(比如大于1000w都是新用户)多库环境、不同环境的数据库id冲突； 订单连续，容易让同行推算出你的销量；
GUID： GUID程序生成的，全球唯一，插入数据库，不会错误的join，无限的，方便导入
空间大，没有自身含义，没有聚集索引(创建时间来聚集)

2.3 外键

2.4 存储过程

存储过程Procedure是一组为了完成特定功能的SQL语句集合，经编译后存储在数据库中，用户通过指定存储过程的名称并给出参数来执行。
存储过程不好维护；逻辑分散了；不好管理；全部数据库操作；
少用，大量复杂的逻辑、计算、数据传输，可以用，否则还是程序来完成

3 触发器、游标、视图、自定义函数，字段类型、字段可空、统计字段、逻辑删除

3.1. 触发器： 触发器是一种特殊类型的存储过程，触发器主要是通过事件进行触发被自动调用执行的（不要用）
3.2.游标： 游标实际上是一种能从多条数据记录的结果集中每次提取一条记录的机制（几乎不用）
3.3.视图：视图就是一个虚拟的数据表，该数据表中的数据记录是有一条查询语句的查询结果得到的，没问题，有需要就用(多表拼成临时表，方便查询/权限控制)
3.4. 函数： 不太推荐使用自定义函数，因为计算交给数据库，没法使用索引
3.5.字段类型：…
3.6.字段可空：数值类型的 不要可空，in查询 not in查询 会没有结果，一般给个默认值，尽量非空，其他看情况(时间不适合默认值)
3.7.统计字段：创建时间、创建人、最后更新时间、最后更新人、state、isEnable
3.8.软删除：假删除、逻辑删除，把状态改成删除，而不是物理删除