4D 架构设计：完整指南

4D 架构设计是构建 4D 数据库（其表、字段、关系、索引和访问级别）的过程，以便应用程序在增长时保持快速、可维护和安全。精心规划的 4D 模式通常涉及五个核心决策：表粒度、关系策略、主键类型、索引位置以及数据与界面逻辑的分离。从一开始就做好这一点将有助于您避免将来进行成本高昂的迁移。

要点

• 4D 架构设计分离三个关注点：数据模型（表、字段、关系）、业务逻辑层（方法、类、触发器）和表示层（表单、列表框、对话框）。
• 关系类型比表数量更重要：多对多链接需要联结表，而一对多链接使用外键字段加关系。
• 索引读取速度快，但写入速度慢 - 索引外键和查询 WHERE 子句中使用的任何字段，而不是每个字段。
• 4D 的 ORDA（对象关系数据访问）层改变了您对模式的看法：命名良好的表和字段成为代码中可读的数据类和属性名称。
• 客户端-服务器与单用户部署是一个架构决策，而不是事后的部署 - 它会影响锁定、缓存以及编写查询的方式。
• 从第一天起就一致应用的命名约定比任何其他单一习惯节省更多的重构时间。

“4D 架构”在数据库环境中意味着什么

4D架构设计是指构建在4D平台（4th Dimension）上的应用程序的结构设计，4D平台是关系数据库和低代码开发环境，最初由Laurent Ribardière团队于1984年发布，现在由4D SAS维护。与纯 SQL 数据库不同，4D 将数据引擎、编程语言、表单设计器和 Web/REST 服务器捆绑到一个产品中 - 因此这里的“架构”涵盖模式和位于其之上的应用程序层。

该术语有时与建筑可视化（4D BIM，时间作为建筑设计的第四维度）相混淆。本指南涵盖软件意义：如何布局 4D 数据库及其应用程序层。如果您是来寻找建筑设计的，那么以下概念将不适用。

4D 应用程序的三层

4D 架构设计项目受益于明确的分层模型。职责划分可以防止不断增长的应用程序变成混乱的表单脚本。

第 1 层 — 数据模型

数据模型是存储在 4D 结构文件中的表、字段、关系和索引的集合。该层不应包含任何用户界面代码，也不应包含可能存在于其他地方的业务规则。字段类型（文本、整数、实数、日期、时间、布尔值、blob、对象、图片）和字段长度在此处固定，稍后在实时数据库中更改它们需要小心。

第 2 层 — 业务逻辑

业务逻辑存在于项目方法、类和表触发器中。在现代 4D 中，类（随 4D v18 R3 引入并自此扩展）可让您编写可重用、可测试的代码，而不是在表单方法中分散逻辑。表上的触发器在创建、保存和删除时触发 - 对于审计跟踪很有用，但调用用户界面的触发器将在无头服务器上下文中中断。

Related: Airtable — A spreadsheet-simple interface sitting on top of a real relational database, with automations, views, and shareable interfaces..

第 3 层 — 演示

演示层涵盖表单、列表框、输入对话框和任何 Web 或 REST 输出。 4D 表单 直接绑定到字段和变量，这很方便，但鼓励将逻辑放入表单中。保持表单方法的精简（调用类方法并显示结果）是大多数 4D 项目中最大的可维护性优势。

设计数据模型：表、关系和键

4D 架构设计中的数据建模决策遵循关系原则，并具有分层的 4D 特定机制。

选择表粒度

表应该代表一种实体类型。当客户可以有多个地址时，将“客户”表拆分为“客户”和“客户地址”是有意义的；当每个客户只有一个地址且无法重复使用时，合并它们是有意义的。过度标准化为许多小表会增加关系和联接的数量，这会降低列表视图的性能。

If you are shopping: Zoho Creator — A low-code app builder that plugs into the wider Zoho suite and prices per user rather than per app..

关系类型

4D 支持在结构编辑器中定义的自动关系和在代码中创建的手动关系。常见模式：

关系	4D 实施	典型用途
一对多	“多”方的外键字段加一个关系	发票 → 发票行
多对多	具有两个外键的中间表	产品 ↔ 供应商
一对一	共享主键或唯一外键	用户 → 用户个人资料
自引用	外键指向同一张表	员工→经理

主键策略

4D 提供自动递增 longint 主键和 UUID（文本）主键。 Longint 键紧凑且索引速度快； UUID 是全球唯一的，这在合并来自多个站点的数据或与外部系统同步时很重要。常见的妥协是使用 longint 内部密钥加上单独的唯一“外部参考”文本字段。

索引和查询性能

索引是 4D 架构设计中最有效的性能优化手段，也是最容易过度应用的。

索引什么

对用作关系外键的任何字段、查询搜索条件中经常使用的任何字段以及用于在大型列表框中排序的任何字段建立索引。 4D支持标准B树索引、基于单词的文本搜索的关键字索引以及覆盖多个字段的复合索引。

什么不应该索引

每个索引都会增加写入成本和存储空间。用两个可能的值对布尔字段建立索引很少有帮助。对仅作为完整记录显示的一部分读取的字段建立索引会增加开销，但不会带来任何好处。在应用程序具有实际使用模式后查看索引，而不是预先猜测。

查询策略

对于新代码，ORDA 查询（ds.Invoice.query("Status = :1"; "Open")）通常比经典 QUERY 命令更可取，因为它们返回可以排序、过滤并在方法之间传递的实体选择，而无需重新查询。对于非常大的表，在应用非索引过滤器之前使用索引条件限制查询可以保持响应时间可预测。

Related: Knack — A no-code database builder aimed at portals, directories, and internal tools — with flat-rate pricing instead of per-user fees..

ORDA 和现代 4D 架构

ORDA（对象关系数据访问）是 4D 的面向对象数据访问层，在 4D v17 中引入。它将表公开为数据类，将记录公开为实体，因此名为“Invoice”的表变为“ds.Invoice”，名为“TotalNet”的字段变为“$invoice.TotalNet”。

这对 4d 架构设计产生了架构影响：表和字段名称现在是公共 API 的一部分。重命名字段会以编译时可见的方式破坏代码，但不一致的命名会使 ORDA 代码难以阅读。采用约定——单数表名、PascalCase 字段、无缩写——立即获得回报。

ORDA 还支持仅部分加载的客户端实体选择，这会改变列表屏幕的性能特性。假设其后面的查询已建立索引，绑定到实体选择的列表框可以显示数千行，而无需加载每条记录。

Our pick: Claris FileMaker Pro — The long-running relational database platform for teams that need custom apps on desktop, web, and mobile from a single file..

客户端-服务器、单用户和 Web 部署

部署拓扑对 4d 架构设计的影响超出了许多开发人员的预期。

单用户应用程序在一个进程中运行数据引擎和界面。锁定是微不足道的；性能调整主要是关于本地磁盘速度。

客户端-服务器 将 4D 服务器（数据引擎）与 4D 客户端（接口）分开。记录被锁定在服务器上，每次查询的网络往返成本变得很大。每个屏幕发出许多小查询的架构在这里表现不佳；批处理查询和使用实体选择可以减少往返次数。

Web 和 REST 部署通过 4D 的 REST 服务器或通过编译的 Web 方法公开相同的数据模型。安全性变得至关重要：表和字段访问必须通过角色和权限进行限制，并且仅以表单方法强制执行的任何业务规则对于 Web 客户端来说实际上是不强制执行的。

命名约定和文档

一致的命名虽然不起眼，但对于 4D 架构设计来说却是决定性的。 4D 的可行约定：

• 表：单数名词、PascalCase（“Customer”、“InvoiceLine”）。
• 字段：PascalCase，没有类型前缀（“InvoiceDate”，而不是“dInvDate”）。
• 关系：根据目标表（“Customer_Invoices”）命名。
• 方法：动词优先（“CreateInvoice”、“RecalculateTotals”）。
• 类：名词优先（“InvoiceService”、“TaxCalculator”）。

记录架构 - 即使作为列出每个表、其用途及其关键关系的单个 Markdown 文件 - 使入门和未来的迁移变得更加容易。 4D 的结构编辑器以图形方式显示关系，但它没有解释“为什么”表存在。

常见的 4D 架构设计错误

将业务逻辑放入表单方法中。 表单方法无法从 Web 上下文或计划任务中调用，因此被困在那里的逻辑必须是重复的。

**在整个新代码中使用基于选择的经典命令。**经典选择受进程限制，并且在进程之间不能很好地传播； ORDA实体选择更加灵活。

跳过联结表。 在单个文本字段中存储多个值（逗号分隔的 ID）会破坏索引并使报告变得痛苦。

对所有内容建立索引。 写入性能会下降，而且很少能实现其好处。

在部署之前忽略权限。 将安全模型改造到已完成的应用程序上比沿着架构进行设计要困难得多。

如何决定：实用清单

在构建 4D 架构设计之前，请解决以下问题：

1. 有多少并发用户，他们将通过 LAN、WAN 还是网络进行连接？
2. 哪些实体具有天然的一对多关系，哪些需要联结表？
3. 哪些字段将出现在大型表的搜索条件或排序顺序中？
4. 无论入口点（表单、Web、导入）如何，都必须遵守哪些业务规则？
5. 数据是否会与另一个系统合并，需要 UUID 密钥？
6. 谁在两年内维护这个，这个命名对他们有意义吗？

这六个问题的答案决定了 4D 项目中的大部分结构决策。

进一步阅读

developer.4d.com 上的官方 4D 文档详细介绍了 ORDA、类、权限和部署。有关适用于任何平台的关系建模基础知识，请参阅有关数据库规范化的维基百科文章。对于低代码和快速应用程序开发平台的更广泛背景，低代码开发平台的维基百科条目是一个合理的起点。 4D SAS 还发布了发行说明和迁移指南，描述了何时引入 ORDA、类和其他 4d 架构设计功能。

常见问题

什么是 4D 架构设计？

4D 架构设计是规划 4D (4th Dimension)应用程序结构的过程：表、字段、关系、索引、业务逻辑层和表示层。它决定了应用程序的性能表现、更改的难易程度以及部署到桌面、客户端服务器或 Web 客户端的安全程度。

4D 架构与 4D BIM 相同吗？

不是。 4D BIM 将时间作为第四个维度添加到用于施工调度的建筑信息模型中。软件意义上的4D架构是指在4D数据库平台上设计应用程序。这两个字段共享一个缩写，但没有其他内容。

我应该使用 ORDA 还是经典 4D 命令？

ORDA 是新开发的最佳选择。它返回可以在方法之间传递、排序和过滤的实体选择，无需再次查询，并将表和字段公开为可读对象的属性。经典的基于选择的命令在遗留代码和某些特殊情况下仍然有用。

4D 表应该有多少个索引？

没有固定的数字。索引外键、通用搜索条件中使用的字段以及用于对大型列表进行排序的字段。避免对基数较低的字段建立索引，例如布尔值或具有两个或三个值的状态字段，因为写入成本通常超过读取收益。

在 4D 中我应该选择什么主键类型？

自动递增 longint 键紧凑且快速，适合单站点应用程序。 UUID 文本键较大，但全局唯一，这在合并来自多个站点的数据或与外部系统集成时很重要。许多项目在内部使用 longint 键以及唯一的外部引用字段。

部署后可以更改 4D 数据模型吗？

是的，但要小心。添加表、字段和索引通常很简单。更改字段类型、重命名 ORDA 代码使用的字段或重组实时数据库上的关系需要有计划的迁移，最好首先在生产数据的副本上进行测试。