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

在當前的大型項目中，我們根據(jù)數(shù)據(jù)集的靜態(tài)程度對其進行分類，從非常靜態(tài)到較不穩(wěn)定不等。

第1級：非常靜態(tài)的數(shù)據(jù)集

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

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

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

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

第2級：很少更改的數(shù)據(jù)

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

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

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

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

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

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

第3級：不穩(wěn)定數(shù)據(jù)

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

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

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

總結

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