我正在寻找有关如何在我的项目目录中最好地组织新 Oracle 模式和依赖文件的建议 - 包括序列、触发器、DDL 等。我一直在使用一个名为 schema.sql 的整体文件。时间，但我想知道是否有最佳实践？有点像...
database/
tables/
person.sql
group.sql
sequences/
person.sequence
group.sequence
triggers/
new_person.trigger
感谢您的想法或我可能错过的 URL！
谢谢！
【问题讨论】：
按对象类型存储 DDL 是一种合理的方法——任何东西都可能比单一的 SQL 脚本更容易导航。不过，就个人而言，我更愿意按功能组织 DDL。例如，如果您正在构建一个会计系统，您可能有一系列对象来管理应付账款和一组单独的对象来管理应收账款以及一些用于管理总帐科目的核心对象。这将导致类似于
database/
general_ledger/
tables/
packages/
sequences/
accounts_receivable/
tables/
packages/
sequences/
accounts_payable/
tables/
packages/
sequences
随着系统变得越来越复杂，随着时间的推移，这种层次结构自然会变得更深。这种方法更自然地反映了非数据库代码在源代码控制中的存储方式。像
这样的目录结构中不会有一个 Java 类目录middle_tier/
java/
Foo.java
Bar.java
您可以将实现相同业务逻辑的类组织在一起，并与实现不同业务逻辑的类分开。
【讨论】：
需要考虑的一项是那些可以充当“仅最新”脚本的 SQL。其中包括 CREATE OR REPLACE PROCEDURE/FUNCTION/TRIGGER 等。您运行最新版本，您不必担心数据库中以前可能存在的内容。
另一方面，随着模式的变化，您可以从一个 CREATE TABLE 开始，然后是几个 ALTER TABLE。如果您正在进行升级，您可能需要应用几个 ALTER TABLE 脚本（最好按顺序）。
我会反对“功能分组”，除非划线的位置真的很明显。您可能不希望处于这样一个位置：一个组中有一个 USERS 表，另一个中有一个 USER_AUTHORITIES，第三个中有一个 AUTHORITY 组。
如果您确实有适当的分离，那么它们可能位于不同的架构中，并且您确实希望保持架构不同（因为您可以在不同的架构中拥有相同的对象名称）。
【讨论】：
按对象类型划分，在数据库目录下方添加一个“模式”目录对我来说效果很好。
我使用过具有附加功能划分层的源代码控制系统 - 如果有很多对象，如果您尝试将源代码控制文件与您看到的对象交叉引用，它会添加额外的搜索在通常按类型对对象进行分组的数据库 GUI 导航器中。对象应该如何以这种方式分类也并不总是很清楚。
考虑为该架构对其他架构或角色的授权添加一个“grants”目录，每个被授权者一个文件。如果您有“基于规则的”授权，例如“APPLICATION_USER 角色总是在所有模式 X 的表上获得 SELECT”，那么编写一个 PL/SQL 匿名块来执行此操作。 （您可能想在授权通过某种特殊方法到位后对其进行逆向工程，但是当向应用程序添加新表或视图时很容易错过一些东西）。
标准化所有脚本的分隔符，如果您开始通过 Ant 等构建实用程序进行部署，您的工作将变得更轻松。使用“/”（相对于“;”）适用于 SQL 语句以及 PL/SQL 匿名块。
【讨论】：
在我们的项目中，我们使用了某种组合的方法：我们将程序的核心作为根目录，并将其他功能放在子文件夹中：
root/
plugins/
auth/
mail/
report/
等等
在所有这些文件夹中，我们都有 DDL 和 DML 脚本，几乎所有这些脚本都可以多次运行，例如所有包都定义为create or replace...，所有数据插入脚本检查数据是否已经存在等等。这让我们有机会 rus 几乎所有的脚本，而无需考虑我们可能会崩溃。
显然这种情况不适用于create table 和类似的语句。对于这些脚本，我们手动编写了小型 bash 脚本，它可以提取指定文件并运行它们而不会因特定 ORA 错误而失败，例如：ORA-00955: name is already used by an existing object。
所有文件都混合在目录中，但扩展名不同：.seq 用于序列，.tbl 用于表，.pkg 用于包接口，.bdy 用于包主体，.trg 用于用于触发等...
我们还有一个命名约定来表示我们所有文件的前缀：我们可以有cl_oper.tbl 表和cl_oper.seq 和cl_oper.trg 序列和触发器，以及cl_oper_processing.pkg 和cl_oper_processing.bdy 以及提到的对象的逻辑。使用文件管理器中的这种命名约定，很容易看到与我们项目的某些逻辑单元相关的所有文件（虽然按对象类型在目录中分组不提供此功能）。
希望这些信息对您有所帮助。如果您有任何问题，请留下 cmets。
【讨论】：