我们有一个 IT 部门的客户坚持在升级之前以脚本形式获取数据库更新（他们希望在实施更新之前“读取”更新）。
作为 Flyway 的狂热用户，这让我想到了一种根据更新从 Flyway 生成脚本并将该脚本发送给 IT 的方法。如果版本表不存在，该脚本至少需要创建版本表，检查版本并应用所需的更新。它当然是数据库供应商专有的（在我的例子中是 Oracle）。
这将使我们能够在开发环境中自动使用 Flyway 运行更新，并创建用于测试和生产的手动脚本。
有人知道以前曾考虑过或尝试过类似的事情吗？这是一件微不足道的任务还是一项重大的任务？
当我在一家咨询公司（Intelliware）工作时，我们就遇到了这个问题，所以那里的开发人员整理了一些代码并将其推送到 GitHub。
我们尝试将其包含到 Flyway 核心存储库中，但没有成功。
-- V<YourFlywayVersion>__create_parameters_and_insert_values.sql
-- Creating new parameters
INSERT INTO SYS_PARM_TYPE (PARM_TYPE_NAM, PARM_TYPE_DESC) VALUES ('PERF POC BATCH PARTNER ID', 'Description for PERF POC BATCH PARTNER ID');
INSERT INTO SYS_PARM_TYPE (PARM_TYPE_NAM, PARM_TYPE_DESC) VALUES ('PERF POC BATCH PRCSSR ID', 'Description for PERF POC BATCH PRCSSR ID');
INSERT INTO SYS_PARM_TYPE (PARM_TYPE_NAM, PARM_TYPE_DESC) VALUES ('PERF POC BATCH ACT NUM', 'Description for PERF POC BATCH ACT NUM');
INSERT INTO SYS_PARM_TYPE(PARM_TYPE_NAM, PARM_TYPE_DESC) VALUES('PERF POC BATCH MAX ACS TRANSACTION COUNT', 'Description for PERF POC BATCH MAX ACS TRANSACTION COUNT');
INSERT INTO SYS_PARM_TYPE(PARM_TYPE_NAM, PARM_TYPE_DESC) VALUES( 'PERF POC BATCH SNGL DUAL MSG CD', 'Description for PERF POC BATCH SNGL DUAL MSG CD');
COMMIT;
-- Inserting data into the SYS_PARM table
DECLARE
BEGIN
INSERT INTO SYS_PARM (PARM_TYPE_NAM, PARM_NAM, PARM_VAL) VALUES ('PERF POC BATCH PARTNER ID', '123,456,8831', '120');
INSERT INTO SYS_PARM (PARM_TYPE_NAM, PARM_NAM, PARM_VAL) VALUES ('PERF POC BATCH PRCSSR ID', '90000022922', '986');
INSERT INTO SYS_PARM (PARM_TYPE_NAM, PARM_NAM, PARM_VAL) VALUES ('PERF POC BATCH ACT NUM', '541311313131331', '10');
INSERT INTO SYS_PARM (PARM_TYPE_NAM, PARM_NAM, PARM_VAL) VALUES ('PERF POC BATCH MAX ACS TRANSACTION COUNT', '10', NULL);
INSERT INTO SYS_PARM (PARM_TYPE_NAM, PARM_NAM, PARM_VAL) VALUES ('PERF POC BATCH SNGL DUAL MSG CD', 'SINGLE', NULL);
COMMIT;
EXCEPTION
WHEN OTHERS THEN
ROLLBACK;
RAISE;
END;
/
n many database environments, tables such as the SYS_PARM_TYPE are used for maintaining reference data or metadata - it's known as a lookup table or a reference table.
In your particular context, the SYS_PARM_TYPE table seems to be used to store the list of possible types that a parameter can have in the SYS_PARM table.
The PARM_TYPE_NAM column would contain the name of the parameter type, and the PARM_TYPE_DESC column would contain a description of what that type represents. This way, when you enter a parameter into the SYS_PARM table, and you specify the PARM_TYPE_NAM, you could look up into the SYS_PARM_TYPE table to understand what that parameter type means.
It provides a standardized way to organize types of parameters and is a good practice from a data management perspective, providing data integrity and ease of understanding and use. However, the actual use could be different based on the real business logic or the application's requirements.