在設計應用程序時，一個常見的挑戰是根據數據變化的頻率來確定最合適的實現方式。是否應該將狀態存儲在表格中以便擴展工作流？是否應該將國家名單列表存儲在表格中，以便擴展工作流？是嵌入代碼中還是存儲在表格中？是否應該根據目標平臺調整線程池大小？

在當前的大型項目中，我們根據數據集的靜態程度對其進行分類，從非常靜態到較不穩定不等。

第 1 級：非常靜態的數據集

這些類型的數據更改總是涉及業務規則并影響代碼。一個典型的例子是工作流中的狀態列表（已開始、進行中、等待、完成等）。這種數據集的指示性大小通常在 2 到 20 個條目之間。

從技術角度來看，它通常以枚舉的形式實現（例如 PostgreSQL 中的枚舉類型、Java 中的枚舉或 TypeScript 中的枚舉）。另外，它也可以作為常量或常量列表來管理。

您可以使用以下試金石：代碼中的“IF”語句是否需要包含此列表中的任何項目？

更改這類數據需要發布新版本或更改數據定義語言（DDL），而且不易管理。  

第 2 級：很少更改的數據

可以把數據集想象成國家/州列表或貨幣列表。這些數據集很少超過幾十個條目。我們將其稱為 "術語"。

從技術角度看，可以使用配置文件（JSON/YAML/CSV/屬性等）或數據庫（使用 PostgreSQL 等關系數據庫的表，使用 MongoDB 等 NoSQL 文檔數據庫的文檔或文檔列表等）來管理它們。

如果預算允許，提供一個可以添加、更改或刪除此類條目的管理圖形的用戶界面通常是個好主意。  

即使以后數據可能會發生變化，啟動應用程序時通常也需要這些列表。因此，建議在首次使用應用程序之前將其與最小數據集打包在一起。例如，Liquibase 配置可以與應用程序一起發布，以便在數據庫中創建最小的國家集（如果還不存在的話）。不過，要謹慎使用 "CREATE IF NOT EXIST "方案，以避免與已有數據發生沖突。

根據所使用的打包和技術，這類數據的更改可能需要也可能不需要新版本。如果您的應用程序包含嵌入最小數據集的機制（如配置文件或自動執行的 Liquibase 或 SQL 腳本），則可能需要發布新版本。雖然這最初可能會被視為一種限制，但它能確保您的應用程序自成一體，并且從部署開始就始終處于運行狀態，這通常是值得的。

 在數據庫中存儲術語時，常見的策略是為每個術語創建一個表（如貨幣表、國家表）。如果像我們一樣，您的應用程序需要更靈活的方法，您可以為每個微服務使用單個 NOMENCLATURE 表，并使用簡單的列（如 NOMENCLATURE 名稱）來區分術語。然后，所有術語都會合并到一個技術表中，使用術語名稱上的 WHERE 子句就可以直接檢索特定術語。如果要保持排序，可以為每個術語條目分配一個序號值，從而進一步改進這種方法。   

第 3 級：不穩定數據

大多數應用程序都會持久保存大量數據，我們稱之為 "易失性數據"。這類數據可能涉及由應用程序管理數量不限的記錄，如用戶配置文件、地址或聊天討論。

這類數據集中記錄的更改、添加或刪除永遠不需要發布新版本（盡管備份仍然是必要的）。代碼的設計通常是以通用的方式而不是以個案的方式來處理此類變更。

這類數據通常無法通過修改代碼進行管理，而是通過常規的前臺/后臺圖形用戶界面或批處理程序進行管理。   

總結 

選擇適當的靜態級別對于確保應用程序的可維護性和可修改性至關重要，并有助于避免潛在的隱患。使用不正確的解決方案來處理特定的靜態級別，可能會導致不必要的集成和發布任務，或降低應用程序的可維護性。

原文標題：Datasets Staticity Levels

原文作者：Bertrand Florat