用于实用行项目表单的父子数据模型

为什么一个记录不够\n\n报价、订单、报销申请或清单很少只描述一件事。大多数这类表单在顶部有一个主记录，下面跟着许多小条目。如果强行把所有内容塞进一个记录，表单会变得难以阅读、难以编辑，也容易出错。\n\n一开始看似更简单的长文本字段很快就会带来麻烦。用户无法干净地添加单个条目、无法在不影响其它行的情况下修正一行，也无法自信地删除过时信息。校验也变得薄弱，因为系统只看到一段文本而不是清晰独立的条目。\n\n想想销售报价。一个客户请求可能包含五种产品，每种都需要各自的数量、单价、折扣和备注。报销申请也是同样道理。一次提交属于一个员工，但每笔费用都有自己的日期、类别、金额和凭证状态。\n\n这就是父子模型派上用场的地方。父记录存放整张表单共享的细节，比如申请人、日期、部门或审批状态。子记录存放行项目。每一行都可以单独添加、编辑或删除，而不会损坏主记录。\n\n这种分离让表单对用户更友好，也让团队更容易信任。如果某行金额错误或缺失字段，你可以单独修复那一行，其余记录保持完好。\n\n同样的模式也适用于可编辑清单。清单可能有一个负责人和截止日期，而每个任务有自己的标签、负责人、备注和完成状态。共享细节放在一处，条目细节放在各自位置。\n\n## 父记录和子记录如何协作\n\n当你将表单拆成两部分：一个主记录和多个相关的条目记录时，行项目表单最容易管理。\n\n父记录保存只应出现一次的信息。在报价中，这可能是客户、报价日期、销售负责人和当前状态。在报销申请中，可能是员工姓名、部门、提交日期和审批阶段。\n\n每个子记录存一条可编辑的行并与父记录关联。在报价中，一个子记录可能代表一行产品或服务。在清单中，一个子记录可能是一项任务。在报销表单中，每个子记录通常是一笔费用，包含类别、金额、发生日期和收据备注等字段。\n\n最简单的思路是：\n\n- 父：整张表单的共享细节\n- 子：一行、一项、一种动作\n- 关联：子记录中指向父记录的字段\n\n这个结构很重要，因为总计和汇总应该来自子行，而不是父记录中手工输入的数字。当有人添加、删除或修改一项时，总计应从真实数据更新。这样能减少错误并让审批更可信。\n\n它也让校验更精确。你可以要求数量、拒绝负金额，或标记某一行缺失日期，而不会冻结整个表单。\n\n## 日常工作中的常见用途\n\n任何需要在一条记录下有许多可编辑行的地方都会看到这种模式。\n\n报价是一个明确的例子。销售人员创建一张报价，然后为每种产品或服务添加一行。每行可能需要自己的项目名称、数量、单价、折扣、税费或备注，而父记录保留客户、日期和审批状态。\n\n订单也采用相同思路，但行内通常包含更多的运营细节。一张订单可能包含多个商品，每行可能需要库存状态、仓库说明、发货信息或履行日期。行项目驱动着订单下达后的后续工作。\n\n报销工作流是另一个常见场景。一笔请求属于一个员工和一个报告期，但可能包含多笔费用。每笔费用行通常需要日期、金额、类别、供应商和凭证参考。经理往往逐行审核这些费用，而不是把整个请求当作一个简单的通过或否决。\n\n清单也符合同一模型，即便看起来更简单。父记录可能是入职计划、现场检查或每周回顾。每个子行成为一项任务，拥有自己的完成状态、备注、负责人或截止日期。\n\n一个简单的测试是：表单是否有一个表头和许多需要添加、编辑或删除的行？如果是，父子结构通常是更清晰的选择。\n\n## 在构建前规划结构\n\n好的表单通常从一个问题开始：什么属于整张记录，什么属于每一行？\n\n先回答这个问题，很多后续问题就不存在了。你可以避免重复字段、混乱的总计以及难以管理的行。\n\n对于父记录，只保留描述整份文件的字段。在报价中，这可能包括客户名、报价日期、币种、销售代表和总体审批状态。对于报销请求，可能是员工姓名、部门、提交日期和最终决定。\n\n对于子记录，保留属于每一行的字段。比如项目名称、数量、单价、发生日期、类别、凭证类型、任务标签或行备注。如果一个值在每一行都可能不同，通常就属于子记录。\n\n一个有用的测试是：如果你删除一行，该值是否应该随之消失？如果答案是肯定的，这个字段很可能属于子记录。\n\n每行还应有自己的唯一 ID。不要只依赖行位置（如第一、第二或第三）。行 ID 可以更方便地编辑特定费用、恢复已删除项或追踪更改记录。\n\n在构建前，决定用户将如何与行交互。他们能否添加新行、复制一行、移除、重新排序或筛选长列表？还要决定总计和状态何时更新。有些团队希望在行更改时立即刷新总计，另一些则更愿意在记录保存或提交时才更新。两种方式都可行，但规则必须保持一致。\n\n状态规则也很重要。如果一笔费用被拒绝，整笔请求是回到草稿、保持待审核，还是变为部分批准？在用户开始依赖表单之前尽早回答这些问题要比事后处理容易得多。\n\n## 让编辑对用户更简单\n\n当用户能同时看到父记录细节和条目行时，行项目表单效果最佳。把主记录放在顶部，然后在下方直接展示可编辑的表格。如果有人在创建报价，他们应能在开始添加产品前确认客户、日期和状态。\n\n这种简单布局能减少错误，因为用户不必在不同屏幕间来回切换以确认正在编辑的内容。\n\n### 把整个任务控制在一块屏幕内\n\n添加新行应该感觉快速。表格上方或下方一个清晰的“添加条目”按钮通常就够了。点击时打开一个空白行或小的行内表单，而不是跳转到另一个页面。\n\n这在较长的表单上尤其重要。如果有人要输入十笔费用，每一次额外点击都会拖慢速度并增加出错概率。\n\n最常用的行操作通常是最简单的那些：添加、复制、删除，有时还有移动。复制在多行相似时特别有用，比如重复的酒店夜数或仅有小幅差别的清单项。\n\n### 在出错处显示错误信息\n\n长表单应自动保存部分工作，或至少允许用户保存草稿。因为标签页关闭导致二十分钟的行编辑丢失，是让表单被认为不可靠的最快方式之一。\n\n校验也应同样清晰。如果某一行缺少金额或数量无效，在那一行和具体字段上显示错误。不要让用户去全表搜寻模糊的警告。\n\n如果七行费用正确而一行缺少凭证编号，仅标记那一行。保持请求其余部分完整，让用户在原处修复问题。\n\n## 示例：包含多笔费用的报销请求\n\n报销请求清楚地说明了这种模型为何有效。一笔请求作为父记录，每笔费用成为子行。\n\n父记录保存适用于整个申报的细节：员工姓名、申报期间、经理和总体状态。总体状态可能从 草稿 变为 提交，然后变为 部分批准 或 批准。\n\n每笔费用行存放只属于该项的细节。一行可能记录出租车的商家、消费日期、金额、类别和已附收据。另一行可能记录酒店账单的相同字段。\n\n一个简单的请求可能包括三行：\n\n- City Taxi，5 月 3 日，$28，差旅，已附收据\n- Grand Hotel，5 月 4 日，$180，住宿，已附收据\n- Corner Cafe，5 月 4 日，$14，餐饮，未附收据\n\n这个结构之所以重要，是因为经理通常逐行审核报销。出租车和酒店可能被批准，而餐饮可能被拒绝并附上简短原因，例如“缺失收据”或“餐饮超出每日限额”。\n\n一行被拒绝不应毁掉整笔请求。员工仍应获得被批准项的报销，而被拒绝的行应保持可见并附上理由。这样流程更易理解，也便于日后审计。\n\n总计应来自子行，而不是父记录中手工输入的数字。许多团队保留两个总计：基于所有包含行的提交总计，以及仅基于被接受行的批准总计。这样能清楚说明为何实际支付可能低于原始请求。\n\n## 总计、审批与状态变更\n\n当数字与状态在恰当时机更新时，行项目表单开始让人觉得可靠。\n\n如果用户更改了某个数量、价格或费用金额，总计应基于该更改重新计算。等到最终提交才更新往往会造成混乱，特别是在存在折扣、税费或审批限额时。在大多数情况下，父记录的总计应由计算得来，而不是可编辑。\n\n审批规则也需要同样的清晰度。一旦记录完全被批准，就要决定是否锁定行。如果批准后的行仍可编辑，数据可能会偏离经理实际审批时的内容。\n\n有时审批是逐行进行而非一次性完成。报销就是典型例子。差旅可能被批准，餐饮部分被拒绝，另一笔费用被发回说明。在这种情况下，每个子行需要自己的状态，而父记录保留总体状态。\n\n一组简短的总体状态通常就足够了：\n\n- 草稿\n- 待审核\n- 部分批准\n- 批准\n- 拒绝\n\n这种划分让表单状态清晰。父记录告诉你请求的整体进度，子行则解释每项发生了什么。\n\n同时，针对关键字段（如金额、状态、审批人或总计）保留简单的变更历史也很有帮助。你不必在第一天就建立完整审计系统，但需要足够的历史以解释关键更改。\n\n已删除的行也需要规则。在审核前，彻底删除可能没问题。审核开始后，归档通常比完全移除更安全，这样历史总计和审批决定仍然合情合理。\n\n## 会削弱信任的错误做法\n\n当屏幕上看起来干净但底层存储的数据混乱时，信任会迅速下降。\n\n最常见的错误之一是将父字段和项目字段混在一个扁平表中。报价、订单或报销请求有些细节属于整份记录（如申请人、日期或审批状态），有些属于行（如项目名称、金额、数量或凭证日期）。当这些混在一起时，编辑变得混乱，报表难以使用，重复数据会迅速蔓延。\n\n另一个常见问题是让用户手动输入总计，而系统本应计算它们。如果有人输入了三行费用然后另行手动输入总额，数字可能不一致。一旦这种情况发生几次，审阅者就会开始不信任表单。\n\n大型自由文本框也会带来类似麻烦。虽然要求用户把所有项目粘贴到一个字段看似更快，但非结构化文本难以校验、排序、筛选或审批。结构化的行需要更多规划，但后续更易管理。\n\n行级校验也常被忽视。空行、无效日期、重复条目、负金额和半完成项应在表单进入下一步前被捕捉到。大多数实际错误发生在子行，而不是表头。\n\n删除操作也是薄弱环节。如果用户可以一键删除行而不需确认，重要数据可能被误删。更糟的是若没有记录是谁做了更改。\n\n更安全的做法很简单：确认行删除、锁定计算字段并记录用户所做的关键更改。\n\n## 发布前的检查\n\n在发布含重复行的表单前，请按真实用户的使用方式测试它。\n\n从基础做起。确保用户可以添加、编辑、复制和删除行而不会丢失其他数据。检查表单在十行、五十行甚至一百行时的表现。错误应出现在需要关注的那一行，而不是只显示在页面顶部。\n\n然后测试变更后的行为。更新数量、删除一行、复制一个项目并更改状态。每次操作后，确认父记录仍显示正确的总计、计数和摘要状态。\n\n还要测试通常会暴露薄弱点的边缘情况：删除所有行、在多条有效行中有一条无效、重复条目、零金额、超长备注以及提交后再编辑。\n\n当表单在正常使用下保持清晰，并在混乱的日常情况下仍能表现可预测时，它就算准备好了。\n\n## 在无代码应用中构建\n\n如果你在无代码应用中构建，从团队已经熟悉的流程入手，例如报销或报价。先建立数据结构，然后添加将父记录与子行连接的规则，最后再优化布局。\n\n使用真实样本数据比完美的测试数据更有帮助。输入重复项、缺失备注、更正后的金额和不完整行。这些情况会显示表单在哪些地方变得令人困惑以及信任何时开始流失。\n\nAppMaster 非常适合这类构建，因为父子结构可以自然映射到独立的数据模型、相关表单和业务逻辑中。如果流程以后扩展，AppMaster 还能把相同核心模型变成后端、Web 与原生移动应用，而无需从零重建工作流。\n\n无论你用哪种工具，主要目标始终如一：保持父记录整洁，使每行可以独立编辑，并让总计与状态来源于真实数据。当这部分做好后，行项目表单会更易用，也更值得信赖。