1.开发流程
在开发接口之前，通常需要先熟悉一下后端开发的流程，如下：
- 需求分析(基于原型和PRD)
- 开发计划(工期评估)
- 表结构设计(基于原型和PRD)
- 接口设计(基于原型和PRD)
- 功能实现(基于接口设计+原型+PRD)
- 前后端联调
- 测试提bug
- 前后端优化，再联调
- 测试回归bug
- 功能验收
2.如何设计表
2.1 E-R图
E-R图也称实体-联系图(Entity Relationship Diagram)，提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。
例如：
画图工具推荐：飞书在线文档、processOn(www.processon.com/)、draw.io(h…
2.2 详细设计
2.2.1命名规则
参考阿里开发手册（见名知意）
2.2.2 数据类型
基本准则
- 可靠性：考虑字段存储的内容长度，尽可能的合适
- name 30-50
- 存储空间：在考虑可靠性的前提下，再考虑存储空间
2.2.3 主键（必须存在）
-
自增
-
UUID
-
雪花算法
2.2.4 冗余字段
创建时间、修改时间、创建人、修改人、备注...
要结合具体的业务情况，再去设计冗余字段（为了提高性能，减少多表查询）
3. zzyl
3.1 初始表结构设计
如果将老人家属(elder_family)、老人表(elder)、入住表(check_in)、签约办理表(contract)设计的话，其中check_in表的字段就会非常多，有很多的弊端：
- 性能下降，字段越多，数据库在执行查询时需要处理的数据量就越大，插入和更新尤为明显
- 维护困难：字段过多会使得表结构复杂，导致难以理解和维护，同时修改表结构也会变得更加复杂和耗时。
- 存储空间增加：每个额外的字段，即使大多数情况下为空或数据很少，也会占用额外存储空间，并可能导致数据库备份和恢复操作耗时增加。
- 可扩展性差：当表结构变得过于复杂时，添加新功能或进行其他类型的扩展可能会变得更加困难。
为了缓解这些问题，可以有以下这些策略：
- 归档旧数据：将不经常访问的旧数据归档到单独的表中或数据库中。
- 优化数据类型：确保使用适当的数据类型来存储数据，以减少存储空间的浪费并提高性能。
- 垂直分割：将表垂直分割成多个较小的表，每个表包含相关的字段集。
3.2 垂直分割
垂直分割表就是数据库管理中常用的一种优化技术，它通过将一个大表中的列分割成多个小表，每个小表包含原始表的一部分列，以达到优化数据存储的访问效率的目的。
优点：
- 提高查询性能：通过减少表的宽度，可以加快查询速度，特别是在涉及大量列的表中。当查询只需要访问部分列时，数据库系统只需扫描包含这些列的小表，减少了不必要的数据扫描量。
- 减少I/O操作：在读取数据时，数据库系统可以只读取需要的列，而无需扫描整个表，从而减少了I/O操作的次数和数据传输量。
缺点：
- 增加复杂性：垂直分割表会增加数据库结构的复杂性，需要更多的管理和维护工作。例如，需要修改应用程序中的查询和更新操作，以适应新的表结构。
- 事务处理复杂：垂直分割表后，事务的处理可能会变得更加复杂。因为事务可能需要跨越多个子表，这增加了事务管理的难度和开销。
- 表连接操作增加：由于数据被分散到多个子表中，因此在查询时可能需要更多的表连接操作，这可能会增加CPU的开销和查询的响应时间。
在设计数据库表时，引入冗余字段是一种常见的优化手段，主要目的：
冗余字段减少查询时的表连接操作，降低查询复杂性和执行时间
冗余字段简化查询逻辑，是查询语句更简洁易懂，易于维护和减少出错概率。
3.3 最终表结构
其废弃了老人家属表，由于老人家属信息主要用于回显展示，可以以json格式存储到入住表中的remark字段中。
将外键约束改为逻辑关联，主要出于以下考虑：
性能优化：外键约束可能会影响增删改效率，甚至引发死锁问题。逻辑关联则能避免这些性能瓶颈。
设计灵活性：外键约束限制了数据库结构调整的自由度。逻辑关联则更加灵活，易于适应数据库结构的变化和多种关系模型。
