Skip to main content

设计规范

David LiuAbout 5 min

设计规范

保证数据规范性

模型设计规范

概念模型 -> 逻辑模型 -> 物理模型

将抽象需求沉淀为具体模型，完成数据建模。数据建模过程中须沉淀数据结构、数据流程图等模型定义与描述信息。其中数据流程图应完整反映数据在系统中的流动、处理与存储情况。

  • 概念模型
    • 最高层次的数据模型
    • 业务系统核心与边界
    • 核心业务主体与主体间业务关系
  • 逻辑模型
    • 概念模型进一步细化
    • 业务规则概念模型具体化
    • 至少遵循第三范式，描述实体属性关系
  • 物理模型
    • 概念实体系统物理实现
    • 列属性进行明确定义

创建修改规范

必备字段

  1. 创建时间
  2. 更新时间
  3. 逻辑删除标志
  4. 测试数据标志

设计维护

  1. 注释：表和字段必须有 COMMENT，注释信息应清晰易懂，禁止添加预留字段。

  2. 主键：物理主键和业务主键。

    1. 物理主键必须使用整型、不允许重复、设置自增属性。
    2. 业务主键应有明确的业务含义，从业务层面反映数据记录的唯一性。

  3. 枚举字段：

    必须通过码表形式在数据库中进行独立存储和管理，保码表数据为最新状态。

    码表结构至少包含枚举类型、枚举名称、枚举编码、枚举描述信息。同含义的枚举字段的枚举值及枚举描述应该统一数据标准，保持一致。

  4. 删除表/字段：

  5. 修改表/字段：

  6. 数据安全相关：

MySQL 枚举类型

MySQL ENUM 的缺点

更改枚举成员需要使用 ALTER TABLE 语句重建整个表，这在资源和时间方面是昂贵的。

获取完整的枚举列表很复杂，因为需要访问 information_schema 数据库：

SELECT
column_type
FROM
information_schema.COLUMNS
WHERE
TABLE_NAME = 'tickets'
AND COLUMN_NAME = 'priority';
  • 迁移到其他 RDBMS 可能是一个问题，因为 ENUM 不是 SQL 标准的，并且数据库系统不支持它。
  • 向枚举列表添加更多属性是不可能的。假设您要为每个优先级添加服务协议，例如 High(24h)，Medium(1-2 天)，Low(1 周)，则不可以使用 ENUM 类型的。 在这种情况下，需要有一个单独的表来存储优先级列表，例如 priority(id，name，sort_order，description)，并且通过引用了 priority 表的 id 字段的 priority_id 来替换 tickets 表中的 priority 字段。
  • 与查找表(priorities)相比，枚举列表不可重用。 例如，如果要创建一个名为 tasks 并且要重用优先级列表的新表，则是不可能的。

norm 范式

数据库范式是一种规范化数据库设计的方法，它通过将数据分解成更小的、更规范化的表来减少数据冗余和提高数据一致性。常见的数据库范式有以下几种：

  1. 第一范式（1NF）：确保每个表中的每个列都是原子的，即不可再分的。这可以通过将多值属性拆分成单值属性来实现。

  2. 第二范式（2NF）：确保每个表中的每个非主键列都完全依赖于主键。如果一个表中有多个主键，那么每个非主键列都应该依赖于所有主键。

  3. 第三范式（3NF）：确保每个表中的每个非主键列都不传递依赖于主键。如果一个非主键列依赖于另一个非主键列，那么应该将其拆分成一个单独的表。

除了上述三种范式，还有更高级别的范式，如巴斯-科德范式（BCNF）和第四范式（4NF）。但是，过度规范化可能会导致性能下降，因此在设计数据库时需要权衡规范化和性能之间的关系。

BC 范式（BCNF）是 Boyce-Codd 范式的缩写，其定义是：在关系模式中每一个决定因素都包含候选键，也就是说，只要属性或属性组 A 能够决定任何一个属性 B，则 A 的子集中必须有候选键。BCNF 范式排除了任何属性(不光是非主属性，2NF 和 3NF 所限制的都是非主属性)对候选键的传递依赖与部分依赖。

约束

索引

  1. 建表规范
  • 数据库名、表名，全部使用小写字母,使用"_"下划线连接且长度小于 12,做到见名知意

  1. 建议使用 innodb 引擎,这也是 MySQL 的默认引擎

  2. 字段类型选择

  • 建议所有的表都有一个自增 id ,可以经常作为主键

  • 存储非负数用 unsigned,因为对于同样的字节数,存储范围更大

  • 整型定义中不加长度,直接使用 int, 而不是 in(n).

  • 字符集选择 utf-8

  • timestamp 和 datetime 都是精确到毫秒,优先选择 timestamp,因为前者只占用 4 个字节,而后者占用 8 个字节

  • 如果可以,所有字段最好都用 not null, 因为 null 字段被索引,需要额外的 1 个字节;使索引丶索引统计丶值的比较变得更加复杂.如果是索引字段,一定要定义为 not null , null 值 可用 '0'来代替.

  1. 建立索引注意事项

  • 索引名称必须使用小写

  • 单张表的索引数量控制在 5 个以内,因为 innoDB 使用 b+tree(B+树结构)存储,在 update, delete, insert 时需要对 b+tree 进行调整,过多的索引会减慢更新的速度

  • 唯一索引不和主键重复

  • 经常作为 where 条件的字段最好添加索引

https://blog.csdn.net/weixin_50966947/article/details/126766449open in new window

David's Blog
Copyright © 2024 David Liu