在无代码应用中用数据库约束做表单验证

为什么坏的表单数据会迅速蔓延

坏数据很少只停留在一个地方。表单里输入的一个错误值，可能会被复制、引用，并被应用中接触它的每个部分当作真实数据使用。

通常一开始看起来很小：有人在邮箱后面多打了个空格、选错了客户，或者因为字段允许而输入了负数。表单接受了它，系统就把它当作真实值。

接着，波及效果会很快显现。报表显示了错误的汇总，自动化在错误记录上运行，客户信息里拉出的字段变得混乱、不专业。团队于是创建私有表格等变通方案，结果造成更多的不一致。更糟的是，同一个错误值经常会在后续再次出现，因为它出现在可选项里或被复制到新记录。

事后修复数据既慢又有风险，因为清理很少是一处编辑就能完成的事。你必须找到坏值传播的每个地方，更新相关记录，并重新检查依赖项。一次“简单”的修正可能会破坏工作流、触发重复通知或弄乱审计记录。

在表单验证中采用数据库约束的目的是在第一步就阻止这种连锁反应。当数据库拒绝不可能或不一致的数据时，你就能阻止沉默的失败，并在界面上向用户展示明确的反馈时机。

想象一个用无代码工具（比如 AppMaster）做的内部订单表单。如果订单被保存时缺少客户关联或使用了重复的订单号，就可能污染发票、发货任务和收入报表。在提交时捕获问题可以保持下游清洁并避免日后的痛苦清理。

用通俗话解释数据库约束

数据库约束是存放在数据库里的简单规则。每次保存数据时它们都会生效——不管数据来自哪里：网页表单、移动端界面、导入或 API 调用。如果违反了某条规则，数据库就拒绝保存。

这就是与仅在 UI 做校验的主要差别。表单可以在点击保存前检查字段，但这类检查容易被忽略或绕过。另一个界面可能忘记了同样的规则，某个自动化可能直接写入数据库。很快你就会看到某处看起来没问题的数据在别处破坏报表。

人们谈论在表单验证中使用数据库约束时的意思是：让数据库做最后裁决，UI 的作用是引导用户，尽量避免触到那道墙。

大多数真实应用可以通过三类基础约束覆盖大量问题：

• Unique（唯一）："这个值必须独一无二。" 例如：email、员工编号、发票号。
• Check（检查）："这个条件必须为真。" 例如：quantity > 0、start_date <= end_date。
• Foreign key（外键）："这必须指向另一个表中真实存在的记录。" 例如：每个订单必须关联一个存在的客户。

在无代码应用中，约束更重要，因为通常存在多种创建或更新数据的方式。你可能有用于管理员的 Web 应用、给现场人员的移动应用，以及后台写记录的自动化流程。约束能让所有这些路径保持一致。

它们还可以让错误信息更清晰。如果你为约束设计了友好的映射，就能在坏数据尝试进入时显示像“该发票号已存在”或“请选择有效的客户”之类的聚焦提示，从第一天起就保持数据库干净。

从约束到清晰的用户错误信息

约束擅长阻止坏数据，但原始的数据库错误通常写给开发者看，而不是填写表单的人。目标很简单：把规则保留在数据库中，然后将失败翻译成解释发生了什么以及下一步该怎么做的消息。

把每条约束当作一个小的“错误契约”，包含两部分：出了什么问题，以及如何修复。UI 可以保持友好，同时不削弱数据规则。

一些合适的翻译示例：

• 坏例子："Unique constraint violation on users_email_key"

• 好例子："该邮箱已被占用。请尝试登录或使用其他邮箱。"

• 坏例子："Check constraint failed: order_total_positive"

• 好例子："总额必须大于 0。请至少添加一件商品或调整数量。"

• 坏例子："Foreign key violation on customer_id"

• 好例子："请选择有效的客户。如果是新客户，请先创建该客户。"

在哪里展示消息和用词一样重要。把单字段错误放在对应字段旁边。对于跨字段规则（比如“结束日期必须晚于开始日期”），表单级别的横幅通常更清晰。

保持消息样式简单：大多数问题用内联字段提示，跨字段问题用小横幅，简短确认用吐司提示（不用于详细修复）。

还要在 Web 与移动端保持用词一致。如果你的 Web 表单写着“请选择有效的客户”，移动端不应写成“Invalid FK”。用相同的短动词（“选择”、“输入”、“移除”）和相同的语气，让用户知道该期待什么。

如果你在 AppMaster 中构建，这种映射是可以有意设计的：数据库保持严格，UI 逻辑把失败变成冷静、具体的引导。

逐步实践：先建规则，再做表单

如果先设计表单，你会永远追逐边缘情况；如果先设计数据规则，UI 会更简单，因为它反映的是数据库里已经存在的规则。

一个实用的构建顺序：

1. 列出真正重要的字段。 用简单的语言定义“有效”的含义。例如：“邮箱必须唯一”、“数量至少为 1”、“每个订单必须有一个客户”。
2. 建模表和关系。 在画界面之前先决定哪些属于哪个表。
3. 为不可妥协的规则添加约束。 对于重复用唯一约束，对于必须为真的规则用检查约束，对于关系用外键。
4. 构建与约束匹配的 UI。 标注必填字段，使用合适的输入类型，添加简单提示。UI 应引导用户，但数据库仍然是最后的闸门。
5. 刻意破坏它进行测试。 粘贴脏数据、尝试重复、选择缺失的关联记录。然后改进标签和错误提示，直到修复路径清晰。

快速示例

比如你在做一个内部的“新订单”表单。你可以让用户按客户姓名搜索，但数据库应该只接受真实的 Customer ID（外键）。在 UI 上，这表现为一个可搜索的选择器。如果用户提交时没有选客户，提示可以简单地说“请选择客户”，而不是在保存时抛出令人困惑的错误。

这让规则在 Web 与移动端之间保持一致，而不需要在每个地方重复脆弱的逻辑。

防止用户实际创建重复的唯一约束

唯一约束是阻止“同一事物不同写法”堆积的最简单方法。即便表单漏掉了检查，它也会让数据库拒绝重复值。

对人们容易无意重复输入的值使用唯一约束：邮箱、用户名、发票号、资产标签、员工编号或从表格粘贴过来的工单号。

第一个决策是作用范围。有些值必须在整个系统内唯一（用户名）。有些值只需在父级范围内唯一（每个组织内的发票号，或每个仓库内的资产标签）。有目的地选择作用范围，以免阻止业务上的合法数据。

一种实用划分：

• 全局唯一：整个系统内唯一（用户名、公共 handle）
• 按组织唯一：在公司/团队内唯一（invoice_number + org_id）
• 按地点唯一：在站点内唯一（asset_tag + location_id）

冲突处理方式与规则同等重要。唯一约束失败时，不要只说“已存在”。说明发生冲突的对象和用户下一步可以怎么做。例如：“发票号 1047 已为 Acme Co. 使用。试试 1047-2，或打开已存在的发票。”如果界面可以安全地引用现有记录，显示创建日期或所有者等小提示可以帮助用户在不暴露敏感信息的前提下恢复。

编辑操作需要特别小心。常见错误是把更新当成新建来处理，从而把自己与自己判定为“重复”。确保保存逻辑能识别当前记录，不要把该行与自身比较时触发冲突。

在 AppMaster 中，先在 Data Designer 里定义唯一规则，然后在表单里用友好消息镜像它。数据库依然是最终守门人，UI 的诚实在于解释真实存在的规则。

对于必须始终为真的规则使用检查约束

检查约束（check）是在每行、每次保存时生效的规则。如果有人输入了违反规则的值，保存会失败。对于不论数据来自哪个屏幕、导入或自动化都必须被保证的规则，这正是你想要的行为。

最好的检查是简单且可预测的。如果用户猜不到规则，他们会不断遇到错误并抱怨，所以把检查聚焦在事实而不是复杂策略上。

常见且回报高的检查约束示例：

• 范围：quantity 在 1 到 1000 之间，age 在 13 到 120 之间
• 允许的状态：status 必须是 Draft、Submitted、Approved 或 Rejected
• 正数：amount > 0，折扣在 0 到 100 之间
• 日期顺序：end_date >= start_date
• 简单逻辑：如果 status = Approved 则 approved_at 不为空

让检查更友好的诀窍在于如何措辞 UI 消息。不要原样照搬约束名，告诉用户该更改什么。

好的示例：

• “数量必须在 1 到 1000 之间。”
• “请选择状态：Draft、Submitted、Approved 或 Rejected。”
• “结束日期必须等于或晚于开始日期。”
• “金额必须大于 0。”

在像 AppMaster 这样的无代码构建器中，在表单中镜像相同的检查以提供即时反馈是可以的，但仍然保留数据库的 check 约束作为最终护栏。这样当以后增加新界面时，规则依然成立。

让外键保持关系的真实

外键（FK）强制执行一个简单承诺：如果某个字段表示它引用另一条记录，那么那条记录必须存在。如果 Order 有一个 CustomerId，数据库会拒绝任何引用不存在客户的订单。

这很重要，因为关系字段是“几乎正确”的数据会出现的地方。有人可能把客户名拼错、粘贴了旧 ID，或选择了昨天被删除的记录。没有外键，这些错误在报表、开票或支持工作中才会暴露出来。

UI 模式很直接：用安全的选择替代自由文本。不要把“客户”字段做成文本输入，用下拉、搜索或自动完成，后台写入的是客户的 ID 而不是标签。在无代码构建器中（例如使用与模型绑定的 AppMaster UI 组件），通常意味着绑定一个下拉或搜索列表到 Customers 表并保存所选记录的引用。

当被引用的记录缺失或已删除时，提前决定好行为。多数团队会选择以下之一：

• 在存在相关记录时阻止删除（常用于客户、产品、部门）
• 归档而非删除（保留历史记录而不破坏关系）
• 仅在绝对安全时级联删除（对业务数据而言很少）
• 当关系可选时，把引用设为空

还要设计“创建关联记录”的流程。表单不应强制用户离开去别处创建客户，然后再回来重填。一个实用的方法是提供“新客户”操作，先创建客户，返回新 ID 并自动选中。

如果外键失败，不要展示原始数据库信息。用通俗语言说明发生了什么：“请选择已存在的客户（所选客户已不存在）。” 这句话就能避免破坏性关系的传播。

在 UI 流程中处理约束失败

好的表单会早早捕捉错误，但它们不应假装自己是最终判决者。UI 的作用是让用户更快完成操作；数据库保证没有坏数据被保存。

客户端校验用于明显的问题：必填字段为空、邮箱缺少 @、数字明显超出范围。立即显示这些可以让表单更有响应感并减少失败提交。

服务端校验才是约束发挥作用的地方。即使 UI 漏检了某些情况（或两人同时提交），数据库也会阻止重复、无效值和断链关系。

当约束错误从服务器返回时，让响应可预测：

• 保留表单中所有用户输入，不要清空页面。
• 高亮导致问题的字段，并在旁边添加简短消息。
• 若问题涉及多个字段，显示顶部信息并同时标出最匹配的字段。
• 提供安全的下一步操作：编辑该值或在合适情况下打开已存在的记录。

最后，记录发生了什么以便改进表单。捕获约束名、表/字段以及触发它的用户操作。如果某个约束频繁失败，在 UI 中添加小提示或额外的客户端校验。突增也可能表明界面设计混淆或集成出问题。

示例：一个长期保持干净的内部订单表单

考虑一个销售和支持使用的简单内部工具：“创建订单”表单。看起来无害，但它触及数据库中最重要的表。如果表单曾接收过一次坏输入，这些错误会扩散到发票、发货、退款和报表中。

正确的做法是让数据库规则主导 UI。表单成为对规则的友好前端，这些规则即便有人导入数据或在别处编辑记录也能持续生效。

Order 表可以强制以下规则：

• 唯一订单号：每个 order_number 必须不同。
• 始终为真的检查：quantity > 0、unit_price >= 0，可能还有 unit_price <= 100000。
• 指向 Customer 的外键：每个订单必须指向真实的客户记录。

再看实际使用场景。

一名销售代表凭记忆输入订单号，结果不小心重复了。保存因唯一约束失败。界面不应只是模糊地显示“保存失败”，而应该显示：“订单号已存在。使用下一个可用编号或搜索现有订单。”

后来某客户记录被合并或删除，而有人仍然打开着旧表单并提交。外键会阻止保存。好的 UI 响应是：“该客户不再可用。请刷新客户列表并选择其他客户。” 然后重新加载客户下拉并保留表单的其他内容，避免用户丢失工作。

随着时间推移，这种模式能让订单保持一致，而无需指望每个人每天都小心谨慎。

导致混乱错误和脏数据的常见错误

导致数据混乱的最快方法是只依赖 UI 规则。表单里的必填项有帮助，但它不能保护导入、集成、管理员编辑或另一个写同一张表的界面。如果数据库接受坏值，它们会在其他地方暴露出来。

另一个常见错误是把约束写得比真实情况更严格。某个检查在第一天看起来正确，但一周后会阻止正常使用场景，比如退款、部分发货或来自其他国家的电话号码。一个好的原则是：约束应限制那些必须为真的事情，而不是通常为真的事情。

更新操作常被忽视。编辑时出现的唯一冲突很常见：用户打开一条记录，修改与唯一字段无关的项，保存时却因为别处的“唯一”值发生了变化而失败。状态转换也是陷阱。如果记录能从 Draft 变为 Approved 再变为 Cancelled，确保检查允许完整路径，而不是只允许最终状态。

外键失败的最可避免原因是让人输入 ID。如果 UI 允许对关联记录手工输入 ID，你会得到断链关系。优先使用绑定到现有记录的选择器，并在数据库中保留外键作为最后一道防线。

最后，原始数据库错误会制造恐慌和支持工单。你可以保持严格约束，同时展示易懂的人类化消息。

一个简短的修复清单：

• 让约束作为事实来源，而不仅仅是表单规则
• 围绕真实工作流设计检查，包括例外情况
• 处理编辑和状态转换，而不仅仅是“创建”
• 对关系使用选择器，而不是手动输入标识符
• 把约束失败映射为友好、字段级的消息

无代码团队的快速清单和下一步

在发布表单前，假设用户会匆忙、在糟糕状态下使用，并且常常粘贴数据。最安全的方法是在表单验证中使用数据库约束，这样即使 UI 漏检，数据库也能强制真实。

发布前的快速检查

在每个写入数据库的表单上做以下检查：

• 重复：找出必须唯一的字段（邮箱、订单号、外部 ID）并确认存在唯一规则
• 缺失的关系：确认每个必需的关系都被强制（例如订单必须有客户）
• 无效范围：为必须在界限内的值添加检查（quantity > 0、折扣在 0 到 100 之间）
• 必填字段：确保“必须有”的数据在数据库层面被强制，而不仅仅是 UI 的必填标识
• 安全默认值：决定哪些字段应该自动填充（例如 status = "Draft"），避免用户猜测

然后像真实用户那样测试：做一次完整且干净的提交，然后故意尝试用重复、缺失关系、超范围数字、空必填字段和错误类型输入去破坏它。

在 AppMaster 中的下一步

如果你在 AppMaster（appmaster.io）上构建，先在 Data Designer 中建模规则（unique、check、foreign keys），然后在 Web 或移动 UI 构建器中做表单，并在 Business Process Editor 中连接保存逻辑。当约束失败时捕获错误并把它映射到一个明确的操作：要修改什么以及在哪里修改。

保持错误文本一致且冷静。避免指责性的措辞。优先使用“请使用唯一的邮箱地址”而不是“邮箱无效”。如果可能，展示冲突值或要求范围，让修复步骤一目了然。

选一个真实的表单（例如“创建客户”或“新订单”），端到端构建后，用你团队日常工作中会遇到的脏数据去验证它。