数据库设计
一、规范化
数据库规范化有一些规则。每一条规则都被称为“规范形式”。如果遵守第一条规则，则称数据库处于“第一范式”。
如果遵守前三条规则，则认为数据库处于“第三范式”。尽管可以进行其他级别的规范化，但第三种范式被认为是大多数应用程序所必需的最高级别。
下面的描述包括一些示例。
第一范式
- 消除单个表中的重复组。
- 为每组相关数据创建一个单独的表。
- 用主键标识每一组相关数据。
- 不要在一个表中使用多个字段来存储类似的数据
上述记录中的字段Class1、Class2和Class3表示设计问题
第二范式
- 为应用于多个记录的值集创建单独的表。例如学生和老师的关系
- 将这些表与外键关联。消除冗余数据.
上述表中每个学生的多个类值。Class#在功能上不依赖于Student（主键），拆表设计
第三范式
- 消除不依赖于键的字段。
- 只对频繁变化的数据应用第三范式可能更可行。
- 如果某些依赖字段仍然存在，请将应用程序设计为在任何更改时要求用户验证所有相关字段。
规范化示例表
（源文链接：https://docs.microsoft.com/en-us/office/troubleshoot/access/database-normalization-description）
二、数据类型
定义适当的属性类型.可以提高数据库的性能，还能在存储数据前验证数据
我们应该在“integer”、“numeric”字段中保存数值数据；在“timestamp”、“timestamptz”字段中保存时间戳；在“bit”、“char(1)”或“boolean”字段中保存布尔值等等。
日期值得特别注意。如果 Date 属性假设只有日期部分（OrderDate，ReleaseDate），请使用没有时间部分的 Date 类型。如果你只需要保留时间（StartTime，EndTime），就使用合适的时间类型。
如果不需要指定精度，则将其指定为零（“time(0)”）。
对带有时间部分的日期，有一个问题是，你必须总是截断时间部分，只显示日期，并且当你要在与数据库所在时区不同的地方显示时，要确保格式化后不会显示成昨天或明天。
当跳转到夏令时的时候，带有时间部分的日期时间加减也可能出现问题
三、约束
将无效数据排除在外，并确保数据的健壮性
非空约束
业务规则要求该属性应该始终存在，那么要毫不犹豫地将其设置为 Not Null，其他可选的信息字段可能还是可以设置为 Null
一个典型的例子是，Employee 表的 ManagerId，并不是所有员工都有经理。不要试图让 ManagerId 不为空，并为没有经理的员工插入“0”或“-1”。当我们添加外键约束时，这将导致其他问题.
唯一约束
根据业务规则，一些属性（或属性的组合）应该是惟一的，比如 Id、PinNumber、BookId 和 AuthorId、OrderNo 等。应该通过添加惟一约束来保证这些属性的惟一
主键
Not Null 和唯一约束一起构成主键
当我们想到主键时，会很快想到 Id 或 ObjectId 之类的列。但是主键也可以是复合的，比如 BookId 和 AuthorId。
通常，使用单独的 Id 列是一种更好的方法，因为它可以使连接更加清晰，还能方便地将另一列添加到惟一组合中。但是，即使有了一个单独的主键（Id），我们还是要为 BookId 和 AuthorId 列添加唯一约束
Check 约束
Check 约束允许我们定义数据的有效值 / 范围。适合 Check 约束的属性有百分比（0 到 100 之间）、状态（0、1、2）、价格、金额、总数（大于或等于 0）、PinNumber（固定长度）等。
不要尝试将业务逻辑编码到 Check 约束中
默认约束
默认约束也很重要。它们允许我们向现有表中添加新的 Not Null 列
外键约束
外键约束是关系数据库设计之王。外键与主键一起确保表之间的数据一致性
索引
原文链接（https://relinx.io/2020/09/14/old-good-database-design/）
