/

数据库设计经验小结

实习将近一个月了，第一次参与实际项目的数据库设计，总结一下自己的经验，随时回顾。

设计表时，尽量都有这几个通用字段

  1. id：主键，一个表必须得有主键，必须
  2. create_time：创建时间，必须
  3. update_time：修改时间，必须，更新记录时，就更新它
  4. update_by：修改人，非必须
  5. create_by：创建人，非必须

每个字段都要注释，尤其涉及到枚举时

命名规范：选择合适的字段类型，尽可能选择存储空间小的字段类型

  1. 数字类型的，从 tinyint、smallint、int、bigint 依次选择
  2. 小数类型如金额，则选择 decimal，不可使用 float 和 double
  3. 如果存储的字符串长度几乎相等，使用char定长字符串类型
  4. varchar是可变长字符串，不预先分配存储空间，长度不要超过 5000
  5. 如果存储的值太大，建议字段类型修改为 text，同时抽出单独一张表，用主键与之对应
  6. 同一表中，所有varchar字段的长度加起来，不能大于 65535，如果有这样的需求，请使用TEXT类型

主键设计

  1. 通常推荐使用无业务含义的字段（如自增 ID 或 UUID）作为数据库的主键，而将业务相关的字段（如身份证号、邮箱地址等）作为唯一约束，确保数据的唯一性，但不直接用作主键。这样可以提高系统的可维护性、安全性和性能
  2. 身份证号和邮箱地址虽然在某些场景下能唯一标识一个用户，但它们可能会发生变化。例如，用户可能更换邮箱地址或者出现身份证号错误的情况。如果它们作为主键，一旦发生变化，会导致数据库中的数据不一致，维护和更新就会变得复杂
  3. 数据隐私和安全问题：身份证号和邮箱地址涉及到个人隐私，将这些信息作为主键暴露出来可能会带来数据泄露的风险
  4. 性能问题：主键通常是数据库索引的一部分，涉及业务的字段（如身份证号、邮箱地址等）一般会较长，或者包含特殊字符，这可能影响数据库的查询性能。而采用无业务含义的自增 ID 或 UUID 作为主键，能够减少索引的大小，提升查询性能
  5. 设计的灵活性和可维护性：如果业务含义字段被当作主键，那么系统对这些字段的修改（比如用户更换邮箱、身份证号错误修正）可能会比较困难

合适的字段长度，字段长度一般设计为 2 的幂次方

优先考虑逻辑删除，而不是物理删除

一张的表的字段不宜过多

一般 20 个左右。若数据过多，可分为两张表，一张作为条件查询，一张作为记录查询。

尽可能使用 not null 定义字段

  1. 首先，not null 可以防止出现空指针问题
  2. 其次 null 值存储也需要额外的空间的，它也会导致比较运算更为复杂，使优化器难以优化 sql
  3. null 值有可能导致索引失效

设计表时，评估那些字段需要添加索引

  1. 尽量不超过5个
  2. 区分度不高的，不需要添加索引，例如，性别
  3. 创建完索引，不要使用内置 mysql 内置函数，会导致索引失效

避免使用 mysql 保留字

感谢 chatGPT 提供的诸多参考OTZ