前言
前后端开发外加数据库设计,特别是数据库是前后端的桥梁,对此需要注意很多点,在此处项目中感悟犹大
推荐阅读:
1. 选型
对于数据库选型无非是关系型还是非关系型数据库
通常取决于项目的需求、性能要求、数据结构以及团队的熟悉程度。
以下是在选择数据库类型时应考虑的一些因素:
概念 | 数据模型和结构 | 性能需求 | 数据一致性要求 | 管理复杂度 | 数据规模和复杂性 | 团队熟悉度 | 支持生态系统 | 云服务支持 |
---|---|---|---|---|---|---|---|---|
关系型数据库(如MySQL) | 1.适用于需要复杂事务和强一致性的应用,支持 SQL 查询语言 2.数据表之间可以建立关联,保持数据的结构化 | 1.在复杂查询和事务处理方面通常表现较好 2.适用于需要 ACID(原子性、一致性、隔离性、持久性)属性的应用 | 提供强一致性,适用于要求数据严格一致的场景 | 通常有成熟的管理工具和广泛的支持,但可能需要更复杂的维护 | 适用于数据结构相对稳定、规模不会迅速增长的应用 | 很多开发人员对关系型数据库有丰富的经验 | 具有丰富的生态系统和工具支持 | 在主流云服务商上有广泛支持 |
非关系型数据库(NoSQL,如MongoDB) | 1.适用于需要横向扩展和处理大量非结构化数据的应用 2.不同文档可以有不同的字段,更灵活 | 1.在读写速度和横向扩展方面通常更具优势 2.适用于数据量大、写入频繁的场景 | 提供最终一致性,适用于更宽松的一致性要求 | 一些非关系型数据库提供了更简化的数据管理和水平扩展 | 更适合处理半结构化和非结构化数据,适用于数据规模可能会快速增长的应用 | 对于特定的场景,可能需要学习新的查询语言和数据模型 | 可能具有不同类型的生态系统和工具,具体取决于选择的非关系型数据库 | 云服务商也提供了非关系型数据库的支持,但选择可能有所限制 |
对应的示例选择:
- 如果项目需要复杂事务、强一致性、数据结构相对稳定,且团队熟悉SQL:
选择关系型数据库,如MySQL。 - 如果项目需要横向扩展、处理大量非结构化数据、写入频繁,且对一致性要求较低:
考虑非关系型数据库,如MongoDB。 - 如果项目需要灵活的数据模型、较高的性能和横向扩展,且对一致性要求相对宽松:
考虑选择适合场景的非关系型数据库,如Cassandra、Redis等。
总体而言,数据库选择应该根据具体的项目需求和技术背景来做出,不同的数据库类型都有其适用的场景。
如果是非关系型数据库推荐阅读:Redis框架从入门到学精(全)
2. 表设计
-
数据类型选择:
选择合适的数据类型,以节省存储空间并提高查询性能
避免使用过大的数据类型,确保适当地匹配存储需求(例如,使用INT而不是VARCHAR存储整数) -
主键设计:
每个表应该有一个主键,通常使用自增主键。
主键应该是唯一的,避免使用可能重复的字段作为主键。 -
索引设计:
使用索引以加速查询,但不要过度索引。
考虑选择合适的列作为索引,例如,经常用于查询的列或连接条件的列 -
规范化:
使用规范化来减少冗余数据,并确保数据的一致性。
但要注意,过度规范化可能导致查询性能下降,因此需要权衡 -
表关系:
明确定义表之间的关系,使用外键来保持引用完整性
考虑使用联合索引来优化与关联表的查询 -
避免使用保留字:
避免使用MySQL的保留字作为表名、列名等标识符 -
NULL和默认值:
谨慎使用NULL值,确保只在需要时使用
为列定义适当的默认值,以确保插入数据时不会违反约束 -
性能考虑:
考虑分区表、分表、缓存等技术来提高性能
定期优化表,包括重新构建索引和分析表 -
安全性:
使用合适的权限控制,确保每个用户只能访问他们需要的数据
考虑加密敏感信息,如密码等 -
注释:
为表、列和索引添加注释,以便后续开发者能够理解表结构的用途和设计考虑
对于上述的基本知识还有以下几点实战补充:
当设计MySQL表时,命名规范、字段类型、主键、字段长度、逻辑删除、通用字段、表的字段个数和索引都是非常重要的方面。
-
命名规范: 注意前后端通信的字段名
使用有意义的、描述性的名字,避免使用缩写
采用一致的命名规范,可以选择驼峰式命名(例如,employeeId)或下划线分隔命名(例如,employee_id)。 -
字段类型:
选择合适的数据类型,如INT、VARCHAR、DATE等,以减小存储空间并提高查询性能
对于文本字段,选择合适的字符集和校对规则 -
主键:主要保证一个唯一性
使用适当的主键,通常是自增主键(INT AUTO_INCREMENT)。
主键应该是唯一的,确保数据的唯一性。
考虑使用复合主键,但要小心其可能引发的性能问题。 -
字段长度:如果统一设置255肯定合适,但是作为架构来说要有所考虑
确保字段长度足够,但不要过大,以避免浪费存储空间。
对于字符串类型,根据实际需求选择合适的长度,不要过度分配空间。 -
逻辑删除:推荐阅读:详细讲解MybatisPlus实现逻辑删除
对于需要软删除的数据,考虑使用逻辑删除而不是物理删除。
可以添加一个表示删除状态的字段,如is_deleted,用于标识是否被删除。 -
通用字段:
在需要的情况下,添加一些通用字段,如created_at(记录创建时间)和updated_at(记录最后更新时间)。
还可以考虑添加created_by和updated_by等字段,用于记录创建和更新操作的用户。 -
表的字段个数:
控制表的字段个数,避免过于臃肿,以提高查询性能和可维护性。
根据业务需求,合理组织字段,将相关的信息放在一起。
彩蛋
对于数据库设计好之后,一定要定时备份!
数据库难免会有脏数据或者损坏啥的,后续不好清空或者复查,所以一定要备份和恢复
备份和恢复 实施定期的备份和恢复策略,以防止数据丢失或损坏
备份和恢复 实施定期的备份和恢复策略,以防止数据丢失或损坏
备份和恢复 实施定期的备份和恢复策略,以防止数据丢失或损坏
而且也需要审计跟踪:针对敏感操作启用审计跟踪,以记录对数据库的重要更改
以上是一些设计MySQL表时需要注意的方面,具体的设计取决于应用的需求和数据库的使用场景。在设计之前,最好对数据模型进行仔细的分析和规划