从历史上看，当项目或团队需要创建、更新或删除数据库资源时，他们将使用特定模板创建一个 sql 文件，其中包含实现团队目标所需的 DML 或 DDL。这些 SQL 文件由项目/功能团队提交到源代码控制中的单个存储库，此时 DBA 将挑选它们、评估它们并将其部署到 TEST 和 PROD 数据库，作为计划发布周期的一部分。
我们目前正在重新发明发布流程，作为一个更大项目的一部分，以实现数据库现代化并迁移到云中。作为该项目的一部分，我们希望进行任何可以提供帮助的流程改进。对于 DML/DDL 更新，我们在 Github Actions 中自动化该过程。这就是我们遇到的语义/命名问题。这些文件长期以来被称为“db patch”。这一直让 DBA 感到沮丧，他们觉得将这些文件称为“补丁”是对应该为安全或其他 RDS 引擎修补保留的术语的过度使用。
我们都同意，在下一代系统中，我们不会将 DML/DDL 文件称为“补丁”，但我们正在努力想出一个更好、更准确的描述性术语。 “Migrations”或“Schema Migrations”已被广泛使用，但由于其拗口而不受人们喜爱，并且也可能与我们当前使用的AWS“数据库迁移服务”和“架构转换”相混淆。用于将我们的数据库转换、迁移和同步到 AWS 的工具。
谷歌搜索这个问题似乎只会出现“什么是 DDL 与 DML”类型的页面和文章。我希望听到社区的声音，您正在使用什么条款！谢谢。
TL;DR：您如何称呼源代码管理中更新数据库的文件？
为源代码管理中更新数据库的文件选择正确的术语对于团队和组织内的清晰度和一致性至关重要。以下是您可能会考虑的“数据库补丁”或“迁移”的一些替代方案：
数据库脚本：这是一个简单的术语，包含修改数据库的 DDL 和 DML 脚本。
数据库更新：该术语很明确，表示文件包含数据库架构和数据的更新。
数据库更改：该术语涵盖对数据库所做的任何更改，包括架构更改和数据修改。
SQL 更新：这是一个简洁的术语，意味着文件包含用于更改数据库的 SQL 语句。
最终，术语的选择应符合团队的偏好和惯例，并且对于参与该过程的每个人都应该清晰且具有描述性