嗨，菲利普，

感谢您的反应。 但是我对我们的案子有不同的看法。

如果您将列设为强制（将其设置为NOT NULL）并且该列中存在NULL值，则数据将以PD的方式丢失（INSERT-SELECT语句在Oracle中将失败，并且没有数据将被复制到 新表格版本）。 而且，当然，由于相同的原因，ALTER TABLE方法将无法修改列（但数据将保留在原始表中）。

在我们的系统中，我们有最大的表，具有1亿条记录，接近100GB的空间，几乎是连接索引使用的空间的两倍。 如果我们删除这些索引和引用，复制数据，然后再次创建索引和引用，我们将浪费很多时间（我们的客户以24/7模式运行）。 这种方法对我们来说是完全不可接受的。

如果PD将生成简单的ALTER TABLE，我们可以在DBMS \ Script \ Objects \ Column \ ModifyColnNull脚本中"捕获"此事件，并运行我们的自定义操作以修复列值（使表中的所有行它们都不为NULL）， 至此，我们知道了表和列的名称。 这种方法比重新创建表更快，更安全。 在那种情况下，我们真的不会丢失任何数据。

在其他情况下（重新创建表），我们不知道将要更改的原始列名。 我对表和列对象的DBMS脚本进行了一些调查，但没有找到可能会生成INSERT-SELECT命令的任何节点。 因此，我们无法修改此行为（将列值固定为NOT NULL）。 我们需要自动修改此行为，因为我们计划在自动部署过程中使用PD，在该过程中将自动生成数据库模型修改脚本（我们会将客户的当前模型与将要安装的新模型进行比较）。 并且，如果将简单的" ALTER TABLE表的MODIFY列NOT NULL"命令拆分为一系列放置约束，索引和引用，然后创建表并复制数据，然后在约束，索引和引用之后重新创建； 我们只是无法自动化。 还有更多的修改（一些新的引用，表，索引），不仅是alter列中的修改。 然后将它们全部混合在一起（通过依赖关系逻辑，先删除等等）。 因此，当生成最终脚本时，我们将无法解析和更改它，因为我们不知道哪个DROP/CREATE是作为常规操作（从我们的角度来看为" valid"）生成的，以及哪个是ALTER TABLE的结果 "分裂"。 因此，在我们的案例中，我们确实需要这个简单的ALTER TABLE命令。

从这个角度来看，我看不出如何解决我们的问题。 目前对我们来说是排行榜。 因此，如果您有任何建议，我将不胜感激。

最后。 这种行为是真的硬编码在PD内核中，还是受PDM的DBMS影响？ 我仍然在想这种方式，因为例如在Postgre SQL 9.x中，它无法生成ALTER TABLE命令来将列更改为允许NULL。 在Oracle 11g，12c和SQL Server 2014（我已经测试过）中，这种相反的方法是可行的。 因此，也许对DMBS xdb文件进行一些"肮脏"的修改将导致两种方式都使用ALTER TABLE命令。 但这只是我的愿望和推测。