Database 为什么不建议按程序更改表结构？

通常，应用程序用户不应该拥有DDL权限。 我在寻找原因，但什么也找不到

我可以理解这种设计可能会有锁定问题，但我想了解更多关于这方面的细节

有人能解释一下或给我指一下这方面的文章吗

非常感谢

通常，应用程序用户不应该拥有DDL权限。我在寻找原因，但什么也找不到

创建/更改表不是即时完成的。您只需创建一次，并且仅通过应用程序（使用PL/SQL存储对象）操作数据。数据库设计不应频繁更改，即应用程序用户不应添加/更改/删除数据库对象。应该由数据库用户（具有所需的权限/角色）而不是应用程序用户执行

应用程序只能执行DML，而不能执行DDL。应用程序用户应该只能操作数据，而不应该操作存储数据的对象本身

假设一个数据库有多个用户，每个用户在其他用户不知情/不同意的情况下执行DDL操作。其他用户将如何工作？基于数据库设计的功能如何？基于数据库设计的应用程序逻辑是什么？每个生产系统都有一个用于此类更改的发布日历，这是不应该经常做的事情。

“不要在业务逻辑中使用DDL”-这是Oracle的经验法则

• DDL不可伸缩
• DDL需要独占锁，并且可能在DDL执行超时时死亡
• 无法回滚DDL（不支持事务）
• DDL使执行计划无效
• DDL可能需要重新编译PL/SQL代码

---

您通常不希望这种情况在工作时间发生。

IMHO，应用程序甚至不应该执行DML；所有这些都应该通过应用程序帐户具有运行所需权限的存储过程来完成。这样，如果需要进行DDL（例如，截断GTT或动态创建外部表——这很少见，但有时是必要的），则是拥有对象的模式完成了这项工作，并且它应该已经拥有必要的特权。同时，在现实世界中*{；-）啊！当我说应用程序应该只做DML时，我应该说得更清楚，我实际上是指通过PL/SQL对象的应用程序。但是，我也见过一些应用程序，其中架构师决定将业务逻辑与数据分开，因此数据库只包含数据，而不涉及PL/SQL编程。是的，我也见过这样的情况虽然他们认为您可以如何将所有业务逻辑从数据库层分离出来，但我不明白。毕竟，约束是业务逻辑的一部分。除非，我认为，他们不关心数据的有效性，在这种情况下，我建议使用指向/dev/null…*{；-）的数据库