HarmonyOS 7.0学习笔记85：IT工单本地数据库表结构设计

大家好，我是杨利杰 YJlio。

工单功能开始从页面状态走向本地持久化时，第一步不是急着写建表语句，而是先弄清楚：**哪些信息属于一张工单、每个字段代表什么、哪些规则必须长期保持。**表结构一旦和业务含义脱节，后续筛选、编辑和数据迁移都会更难维护。

本文依据原始学习笔记中的Ticket类型与标题校验示例，整理本地表结构的设计检查思路。原稿没有说明实际选用的数据库组件、数据库版本、建表代码或运行结果，因此文中的持久化映射和索引部分属于设计讨论，**不代表已经在 HarmonyOS 工程中创建或验证过数据库表。**具体接口应根据工程实际 SDK 与官方文档核对。

一、先从业务模型整理字段

原稿中的工单模型包含五个字段：id、title、category、priority、status。这是应用侧的类型示例，不等同于数据库表定义；例如字段的物理类型、可空性、默认值与约束，还需要结合持久化方案补齐。

我会先把每个字段的责任写清楚，再讨论怎么保存：

这张表是整理问题的起点，不是已确认的业务规范。比如id在类型定义中是字符串，但原稿没有说明它由谁生成，也没有展示数据库侧的唯一约束；这两项要在实际工程设计时补全。不要把字段名称看起来合理，误当成字段规则已经确定。

二、区分 ArkTS 类型与持久化结构

应用里的interface能帮助编译期表达对象形状，但不会自动创建本地数据库表。持久化层还要回答几个实际问题：

1. 一个工单对应哪些持久化列，字段名称是否需要映射。
2. 每个值用什么存储类型表示，是否允许空值。
3. 哪些约束要由应用校验，哪些还要由数据层保证。
4. 新字段或旧字段调整后，已有记录要如何读取和转换。

原稿只列出了应用类型，没有给出实际数据库方案，所以本文不提供某一数据库组件的建表语句，也不把category等字段武断映射成特定存储类型。华为开发者文档把用户首选项、键值数据库和关系型数据库列为不同的数据存储形态，选型应结合数据类型、访问模式、性能、成本和扩展性；项目确定方案后，再按照对应 API 与 SDK 文档落实字段映射。

三、让校验规则在各层保持一致

原稿提供了标题校验函数：先去除首尾空白，再检查标题是否为空，最后拒绝长度超过 80 的输入。这里可以看出一条重要边界：**应用输入校验与数据库约束是相关但不同的两层规则。**即使页面挡住了空标题，数据导入、旧版本代码或其他写入路径仍可能绕过页面校验；具体要不要在持久化层重复约束，要结合所选数据库能力和项目规则决定。

下面保留原稿示例，供对照当前工程检查。它说明的是输入校验逻辑，不是数据库建表或持久化代码：

functionvalidateTitle(title:string):string|undefined{constvalue=title.trim()if(value.length===0)return'请填写工单标题'if(value.length>80)return'标题不能超过80个字符'returnundefined}

实际工程还要明确长度口径。例如代码使用运行时的string.length，UI 提示、接口校验和数据层约束要采用一致标准；如果产品需求对用户感知字符数有特殊定义，应单独验证实现是否符合要求。原稿没有给出这一口径，所以本文不扩写为项目既定规则。

四、索引从查询场景出发

原稿标题提到了“索引考虑”，但没有列出已有查询语句、数据量或性能测量结果。因此这里给出的是评估顺序：先整理列表页实际按什么条件查询，再观察使用频率和数据规模，最后衡量索引可能带来的查询收益以及写入、更新和维护成本。

category与status出现在工单模型中，可以列入查询场景评估；但字段存在并不代表就应该建索引。**在没有真实查询模式和数据表现之前，不写“索引已优化”或“性能提升了多少”。**只有在工程中确认查询路径、实现索引并进行可复现测试后，才能记录具体结论。

五、提前约定结构变化如何处理

表结构会随需求演进。新增、修改或移除字段时，应说明如何处理已有数据，以及应用升级期间如何识别并完成必要转换。原稿没有给出具体数据库版本、迁移 API 或发布策略，因此不虚构版本号和迁移脚本。

在实现之前，我会先确认：变更能否兼容旧数据、转换失败时如何处理、是否需要备份或回退，以及不同应用版本同时运行时是否会访问不兼容的数据。实际机制因项目所用存储方案而异，应以该方案的官方文档和工程代码为准。

六、用一张清单完成表结构评审

在写建表代码前，我会逐项过一遍下面的事项：

1. 字段名称和业务含义是否明确。
2. id的唯一性与生成方式是否确定。
3. 标题必填、空白和长度校验是否有统一标准。
4. priority与status的枚举是否完整，状态变化由谁控制。
5. 分类或状态的查询需求是否真实存在，是否有足够依据评估索引。
6. 结构变更时如何兼容已有记录。

图中的空框表示待确认项目，不是已经通过的检查结果。完成实际建模后，可把每项的结论、依据和代码位置补进工程笔记，避免设计文档与实现逐渐分离。

七、保存完整的问题上下文

如果建表或数据读写阶段遇到编译错误、接口签名不匹配或旧记录无法读取，我会保留 DevEco Studio 与 SDK 版本、当前数据模型、完整错误信息和触发步骤。只记录“数据库报错”通常不足以复现问题。

原稿要求实际运行后补充设备、版本、输出和截图；当前材料没有这些证据。因此这篇只提供检查项，不声称已建表、已通过编译或已在模拟器与真机上读写验证。

八、这一篇的结论

我会先从Ticket类型中整理字段语义，再区分应用模型和持久化结构，随后确认约束、查询场景以及未来结构变化的处理方式。id的唯一规则、分类的有效值、索引是否必要、数据库迁移如何落地，都需要工程需求和实际存储方案来决定。

表结构设计的质量，首先取决于字段语义和约束是否说清楚；索引和版本方案则要由实际访问模式与所选数据库能力支撑。本篇提供的是设计与验证路径，实际建表和读写结果仍待在独立练习工程中补充。

下一篇预告

下一篇将学习“IT工单数据库增删查改封装”，继续把已整理的数据模型连接到实际的本地数据读写流程。

参考资料

1. 本系列原始学习笔记：085《IT工单本地数据库表结构设计》。
2. 华为开发者文档：数据存储方案如何选择。
3. 华为开发者文档：ArkData常见问题，具体关系型数据库文件、接口与配置以当前 SDK 版本文档为准。

欢迎收藏并交流你的实践结果。本文为个人学习记录；示意图不代表真实工程界面，实际 SDK 版本、数据库方案、运行结果和截图须由作者完成练习后补充。

返回顶部