数据库设计

时间 2020-10-22

标签 android 数据库 cookie 数据库设计性能编码 spa 设计 netty orm 栏目 SQL 繁體版

原文原文链接

1、规范化android

　　数据库规范化有一些规则。每一条规则都被称为“规范形式”。若是遵照第一条规则，则称数据库处于“第一范式”。
若是遵照前三条规则，则认为数据库处于“第三范式”。尽管能够进行其余级别的规范化，但第三种范式被认为是大多数应用程序所必需的最高级别。
下面的描述包括一些示例。数据库

第一范式cookie

　　上述记录中的字段Class一、Class2和Class3表示设计问题数据库设计

第二范式性能

　　上述表中每一个学生的多个类值。Class#在功能上不依赖于Student（主键），拆表设计编码

第三范式spa

规范化示例表设计

（源文连接：https://docs.microsoft.com/en-us/office/troubleshoot/access/database-normalization-description）netty

2、数据类型orm

定义适当的属性类型.能够提升数据库的性能，还能在存储数据前验证数据

咱们应该在“integer”、“numeric”字段中保存数值数据；在“timestamp”、“timestamptz”字段中保存时间戳；在“bit”、“char(1)”或“boolean”字段中保存布尔值等等。

日期值得特别注意。若是 Date 属性假设只有日期部分（OrderDate，ReleaseDate），请使用没有时间部分的 Date 类型。若是你只须要保留时间（StartTime，EndTime），就使用合适的时间类型。

若是不须要指定精度，则将其指定为零（“time(0)”）。

对带有时间部分的日期，有一个问题是，你必须老是截断时间部分，只显示日期，而且当你要在与数据库所在时区不一样的地方显示时，要确保格式化后不会显示成昨天或明天。

当跳转到夏令时的时候，带有时间部分的日期时间加减也可能出现问题

3、约束

将无效数据排除在外，并确保数据的健壮性

非空约束

业务规则要求该属性应该始终存在，那么要坚决果断地将其设置为 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、一、2）、价格、金额、总数（大于或等于 0）、PinNumber（固定长度）等。

不要尝试将业务逻辑编码到 Check 约束中

默认约束

默认约束也很重要。它们容许咱们向现有表中添加新的 Not Null 列

外键约束

外键约束是关系数据库设计之王。外键与主键一块儿确保表之间的数据一致性

索引