个人主页杨利杰YJlio❄️个人专栏《Windows 疑难杂症与工单复盘案例库》 《Sysinternals实战教程》《WINDOWS教程》 《Windows PowerShell 实战》 《IOS插件分析测试》《超简单用Python让Excel飞起来》让复杂的事情更简单让重复的工作自动化HarmonyOS 7.0学习笔记85IT工单本地数据库表结构设计文章目录HarmonyOS 7.0学习笔记85IT工单本地数据库表结构设计一、先从业务模型整理字段二、区分 ArkTS 类型与持久化结构三、让校验规则在各层保持一致四、索引从查询场景出发五、提前约定结构变化如何处理六、用一张清单完成表结构评审七、保存完整的问题上下文八、这一篇的结论下一篇预告参考资料大家好我是杨利杰 YJlio。工单功能开始从页面状态走向本地持久化时第一步不是急着写建表语句而是先弄清楚**哪些信息属于一张工单、每个字段代表什么、哪些规则必须长期保持。**表结构一旦和业务含义脱节后续筛选、编辑和数据迁移都会更难维护。本文依据原始学习笔记中的Ticket类型与标题校验示例整理本地表结构的设计检查思路。原稿没有说明实际选用的数据库组件、数据库版本、建表代码或运行结果因此文中的持久化映射和索引部分属于设计讨论**不代表已经在 HarmonyOS 工程中创建或验证过数据库表。**具体接口应根据工程实际 SDK 与官方文档核对。一、先从业务模型整理字段原稿中的工单模型包含五个字段id、title、category、priority、status。这是应用侧的类型示例不等同于数据库表定义例如字段的物理类型、可空性、默认值与约束还需要结合持久化方案补齐。我会先把每个字段的责任写清楚再讨论怎么保存字段原稿中的类型或取值设计时要确认的事项idstring如何生成、如何保证记录唯一以及更新和删除时如何定位titlestring是否必填、长度规则、是否需要按标题搜索categorystring分类来源、允许值是否固定、分类调整如何兼容旧数据prioritylow、normal、high枚举值是否完整、排序规则由谁定义statusnew、processing、resolved状态流转边界、旧值兼容和展示文案如何对应这张表是整理问题的起点不是已确认的业务规范。比如id在类型定义中是字符串但原稿没有说明它由谁生成也没有展示数据库侧的唯一约束这两项要在实际工程设计时补全。不要把字段名称看起来合理误当成字段规则已经确定。二、区分 ArkTS 类型与持久化结构应用里的interface能帮助编译期表达对象形状但不会自动创建本地数据库表。持久化层还要回答几个实际问题一个工单对应哪些持久化列字段名称是否需要映射。每个值用什么存储类型表示是否允许空值。哪些约束要由应用校验哪些还要由数据层保证。新字段或旧字段调整后已有记录要如何读取和转换。原稿只列出了应用类型没有给出实际数据库方案所以本文不提供某一数据库组件的建表语句也不把category等字段武断映射成特定存储类型。华为开发者文档把用户首选项、键值数据库和关系型数据库列为不同的数据存储形态选型应结合数据类型、访问模式、性能、成本和扩展性项目确定方案后再按照对应 API 与 SDK 文档落实字段映射。三、让校验规则在各层保持一致原稿提供了标题校验函数先去除首尾空白再检查标题是否为空最后拒绝长度超过 80 的输入。这里可以看出一条重要边界**应用输入校验与数据库约束是相关但不同的两层规则。**即使页面挡住了空标题数据导入、旧版本代码或其他写入路径仍可能绕过页面校验具体要不要在持久化层重复约束要结合所选数据库能力和项目规则决定。下面保留原稿示例供对照当前工程检查。它说明的是输入校验逻辑不是数据库建表或持久化代码functionvalidateTitle(title:string):string|undefined{constvaluetitle.trim()if(value.length0)return请填写工单标题if(value.length80)return标题不能超过80个字符returnundefined}实际工程还要明确长度口径。例如代码使用运行时的string.lengthUI 提示、接口校验和数据层约束要采用一致标准如果产品需求对用户感知字符数有特殊定义应单独验证实现是否符合要求。原稿没有给出这一口径所以本文不扩写为项目既定规则。四、索引从查询场景出发原稿标题提到了“索引考虑”但没有列出已有查询语句、数据量或性能测量结果。因此这里给出的是评估顺序先整理列表页实际按什么条件查询再观察使用频率和数据规模最后衡量索引可能带来的查询收益以及写入、更新和维护成本。category与status出现在工单模型中可以列入查询场景评估但字段存在并不代表就应该建索引。**在没有真实查询模式和数据表现之前不写“索引已优化”或“性能提升了多少”。**只有在工程中确认查询路径、实现索引并进行可复现测试后才能记录具体结论。五、提前约定结构变化如何处理表结构会随需求演进。新增、修改或移除字段时应说明如何处理已有数据以及应用升级期间如何识别并完成必要转换。原稿没有给出具体数据库版本、迁移 API 或发布策略因此不虚构版本号和迁移脚本。在实现之前我会先确认变更能否兼容旧数据、转换失败时如何处理、是否需要备份或回退以及不同应用版本同时运行时是否会访问不兼容的数据。实际机制因项目所用存储方案而异应以该方案的官方文档和工程代码为准。六、用一张清单完成表结构评审在写建表代码前我会逐项过一遍下面的事项字段名称和业务含义是否明确。id的唯一性与生成方式是否确定。标题必填、空白和长度校验是否有统一标准。priority与status的枚举是否完整状态变化由谁控制。分类或状态的查询需求是否真实存在是否有足够依据评估索引。结构变更时如何兼容已有记录。图中的空框表示待确认项目不是已经通过的检查结果。完成实际建模后可把每项的结论、依据和代码位置补进工程笔记避免设计文档与实现逐渐分离。七、保存完整的问题上下文如果建表或数据读写阶段遇到编译错误、接口签名不匹配或旧记录无法读取我会保留 DevEco Studio 与 SDK 版本、当前数据模型、完整错误信息和触发步骤。只记录“数据库报错”通常不足以复现问题。原稿要求实际运行后补充设备、版本、输出和截图当前材料没有这些证据。因此这篇只提供检查项不声称已建表、已通过编译或已在模拟器与真机上读写验证。八、这一篇的结论我会先从Ticket类型中整理字段语义再区分应用模型和持久化结构随后确认约束、查询场景以及未来结构变化的处理方式。id的唯一规则、分类的有效值、索引是否必要、数据库迁移如何落地都需要工程需求和实际存储方案来决定。表结构设计的质量首先取决于字段语义和约束是否说清楚索引和版本方案则要由实际访问模式与所选数据库能力支撑。本篇提供的是设计与验证路径实际建表和读写结果仍待在独立练习工程中补充。下一篇预告下一篇将学习“IT工单数据库增删查改封装”继续把已整理的数据模型连接到实际的本地数据读写流程。参考资料本系列原始学习笔记085《IT工单本地数据库表结构设计》。华为开发者文档数据存储方案如何选择。华为开发者文档ArkData常见问题具体关系型数据库文件、接口与配置以当前 SDK 版本文档为准。欢迎收藏并交流你的实践结果。本文为个人学习记录示意图不代表真实工程界面实际 SDK 版本、数据库方案、运行结果和截图须由作者完成练习后补充。返回顶部
