数据库设计优化(一)--基础

设计遵循的基本原则

• 范式原则 【参见：> https://www.cnblogs.com/Alicia-meng/p/13493506.html】
• 命名风格--最好是模块功能的缩写 英文 首字母大写
• 自增ID--数据库自增 int/bigint型 是sqlserver的默认聚集索引 一般作为主键 可以有业务意义【但是 多库环境、不同环境的数据库容易出现id冲突】
• GUID--具有唯一性 可以避免错误join 【但是空间占用大--32位 非自增 没有聚集索引】
• 外键-- 可保证数据完整性 类的关系也比较清楚
  • 外键可进行数据校验 级联删除 Eg：表User 具有外键CompanyId 就可确保
    1. user创建时 对应指定Company也存在【不存在时--先创建Company 再创建User 在同一事务中】；
    2. 如果Company删除 则对应关联的所有User也会被删除
    
  • 一般在有严格数据关系时 使用外键
  • 缺点--导入麻烦 增删改都需要额外操作 所以一般都通过程序 建立虚拟外键来完成

  建议

  尽量少用外键 一般大型互联网项目瓶颈即数据库 所以尽量减少数据库的额外操作
• 数据库事务--多条Sql做一个整体提交 要么全部成功 要么全部失败 作为一个逻辑单元 具有以下特性
  • 原子性(atomicity)：事务作为最小工作单元 要么全成功 要么全失败 即事务的原子性
  • 一致性(consistency):从一个一致性状态 转换到另一个一致性状态 即事务执行完 数据都是正确的(事务一旦出错 整个事务都不会提交)
  • 隔离性(isolation): 一个事务修改在最终提交之前，对其他事务是不可看见的； 两个事务A B同时操作一张表时 会通过锁表使A B依次执行
  • 持久性(durability)：一旦事务提交 所做的修改就会永久保存到数据库中 即数据提交后 就固化了

  使用事务会存在一些问题

  • 比如高并发的系统 不可避免会出现死锁【死锁：多个事务在同一资源上 相互占用 请求锁住对方 1. 当多个事务尝试以不同顺序锁定资源时 可能会产生死锁； 2. 当多个事务同时锁定同一个资源时 也会产生死锁】 想尽量减少死锁 可执行一下操作
    1. 按照固定顺序操作数据
    2. 事务尽量短 事务中避免任何等待 调整锁的隔离级别【较低级别的隔离 可以执行更高的并发 同时也能降低系统的开销】