数据集静态水平分类

在设计应用程序时，一个常见的挑战是根据数据变化的频率来确定最合适的实现方式。是否应该将状态存储在表格中以便扩展工作流？是否应该将国家名单列表存储在表格中，以便扩展工作流？是嵌入代码中还是存储在表格中？是否应该根据目标平台调整线程池大小？

在当前的大型项目中，我们根据数据集的静态程度对其进行分类，从非常静态到较不稳定不等。

第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级：不稳定数据

大多数应用程序都会持久保存大量数据，我们称之为 "易失性数据"。这类数据可能涉及由应用程序管理数量不限的记录，如用户配置文件、地址或聊天讨论。

这类数据集中记录的更改、添加或删除永远不需要发布新版本（尽管备份仍然是必要的）。代码的设计通常是以通用的方式而不是以个案的方式来处理此类变更。

这类数据通常无法通过修改代码进行管理，而是通过常规的前台/后台图形用户界面或批处理程序进行管理。

总结

选择适当的静态级别对于确保应用程序的可维护性和可修改性至关重要，并有助于避免潜在的隐患。使用不正确的解决方案来处理特定的静态级别，可能会导致不必要的集成和发布任务，或降低应用程序的可维护性。