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 引入並自此擴充功能）可讓您編寫可重複使用、可測試的程式碼，而不是在表單方法中分散邏輯。表上的觸發器在建立、儲存和刪除時觸發 - 對於審計追蹤很有用，但呼叫使用者介面的觸發器將在無頭伺服器上下文中中斷。

相關： Airtable — 位於真實關係資料庫之上的電子表格簡單介面，具有自動化、視圖和可共享介面。.

第 3 層 — 呈現層

呈現層涵蓋表單、列錶框、輸入對話方塊和任何 Web 或 REST 輸出。 4D 表單 直接綁定到欄位和變數，這很方便，但鼓勵將邏輯放入表單中。保持表單方法的精簡（呼叫類別方法並顯示結果）是大多數 4D 專案中最大的可維護性優勢。

設計資料模型：表格、關係和鍵

4D 架構設計中的資料建模決策遵循關係原則，並具有分層的 4D 特定機制。

選擇表粒度

表應該代表一種實體類型。當客戶可以有多個地址時，將「客戶」表拆分為「客戶」和「客戶地址」是有意義的；當每個客戶只有一個地址且無法重複使用時，合併它們是有意義的。過度標準化為許多小表會增加關係和連接的數量，這會降低清單視圖的效能。

如果您正在購物： Zoho Creator — 低程式碼應用程式建立器，可插入更廣泛的 Zoho 套件，並按使用者而不是按應用程式定價。.

關係類型

4D 支援在結構編輯器中定義的自動關係和在程式碼中建立的手動關係。常見模式：

關係	4D 實作	典型用途
一對多	「多」方的外鍵欄位加上一個關係	發票 → 發票行
多對多	具有兩個外鍵的連接表	產品 ↔ 供應商
一對一	分享主鍵或唯一外鍵	使用者 → 使用者個人資料
自引用	外鍵指向同一張表	員工→經理

主鍵策略

4D 提供自動遞增 longint 主鍵和 UUID（文字）主鍵。 Longint 鍵緊湊且索引速度快； UUID 是全球唯一的，這在合併來自多個站點的資料或與外部系統同步時很重要。常見的妥協是使用 longint 內部金鑰加上單獨的唯一「外部參考」文字欄位。

索引和查詢效能

索引是 4D 架構設計中槓桿率最高的效能槓桿，也是最容易過度應用的。

索引什麼

對用作關係外鍵的任何欄位、查詢搜尋條件中經常使用的任何欄位以及用於在大型列錶框中排序的任何欄位建立索引。 4D支援標準B樹索引、基於單字的文字搜尋的關鍵字索引以及覆蓋多個欄位的複合索引。

什麼不應該索引

每個索引都會增加寫入成本和儲存空間。用兩個可能的值對布林欄位建立索引很少有幫助。對僅作為完整記錄顯示的一部分讀取的欄位建立索引會增加開銷，但不會帶來任何好處。在應用程式具有實際使用模式後查看索引，而不是預先猜測。

查詢策略

對於新程式碼，ORDA 查詢（ds.Invoice.query("Status = :1"; "Open")）通常比經典 QUERY 命令更可取，因為它們傳回可以排序、過濾並在方法之間傳遞的實體選擇，而無需重新查詢。對於非常大的表，在應用非索引過濾器之前使用索引條件限制查詢可以保持回應時間可預測。

相關： Knack — 一個針對入口網站、目錄和內部工具的無程式碼資料庫建構器 - 採用統一費率定價而不是按使用者付費。.

ORDA 和現代 4D 架構

ORDA（物件關係資料存取）是 4D 的物件導向資料存取層，在 4D v17 中引入。它將表公開為資料類，將記錄公開為實體，因此名為“Invoice”的表變為“ds.Invoice”，名為“TotalNet”的欄位變為“$invoice.TotalNet”。

這對 4d 架構設計產生了架構影響：表和欄位名稱現在是公共 API 的一部分。重新命名欄位會以編譯時可見的方式破壞程式碼，但不一致的命名會使 ORDA 程式碼難以閱讀。採用約定——單數表名、PascalCase 欄位、無縮寫——立即獲得回報。

ORDA 還支援僅部分載入的用戶端實體選擇，這會改變清單畫面的效能設定檔。假設其後面的查詢已建立索引，綁定到實體選擇的列錶框可以顯示數千行，而無需載入每筆記錄。

我們的選擇： Claris FileMaker Pro — 長期運行的關係資料庫平台，適用於需要透過單一文件在桌面、Web 和行動裝置上自訂應用程式的團隊。.

客戶端伺服器、單一使用者和 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（第四維度）應用程式結構的過程：表格、欄位、關係、索引、業務邏輯層和表示層。它決定了應用程式的執行方式、更改的難易程度以及部署到桌面、客戶端伺服器或 Web 用戶端的安全程度。

4D 建築與 4D BIM 相同嗎？

不是。 4D BIM 將時間作為第四個維度添加到用於施工調度的建築資訊模型中。軟體意義上的4D架構是指在4D資料庫平台上設計應用程式。這兩個欄位共用一個縮寫，但沒有其他內容。

我應該使用 ORDA 還是經典 4D 指令？

ORDA 是新開發的最佳選擇。它傳回可以在方法之間傳遞、排序和過濾的實體選擇，無需再次查詢，並將表格和欄位公開為可讀物件的屬性。經典的基於選擇的命令在遺留代碼和某些特殊情況下仍然有用。

4D 表應該有多少個索引？

沒有固定的數字。索引外鍵、通用搜尋條件中使用的欄位以及用於對大型清單進行排序的欄位。避免對基數較低的字段建立索引，例如布林值或具有兩個或三個值的狀態字段，因為寫入成本通常超過讀取收益。

在 4D 中我應該選擇什麼主鍵類型？

自動遞增 longint 鍵緊湊且快速，適合單站點應用程式。 UUID 文字鍵較大，但全域唯一，這在合併來自多個網站的資料或與外部系統整合時很重要。許多項目在內部使用 longint 鍵以及唯一的外部引用欄位。

部署後可以更改 4D 資料模型嗎？

是的，但要小心。新增表格、欄位和索引通常很簡單。更改欄位類型、重新命名 ORDA 程式碼使用的欄位或重組正式環境資料庫上的關係需要有計劃的遷移，最好先在生產資料的副本上進行測試。