database - 按应用程序主题组织 SQL 文件值得头疼吗？

Question

在我的公司，我们将每个数据库对象（存储过程、视图等）保存为单独的 SQL 文件，并以这种方式将它们置于源代码控制之下。

到目前为止，我们的版本化文件结构中有一个非常扁平的存储模型：

• DatabaseProject
  • Functions
    • （这里的所有功能；没有进一步的嵌套）
  • StoredProcedures
    • （所有存储的过程都在这里；没有进一步的嵌套）
  • Views
    • （同上）

对于一个大的新项目，我想到了另一个想法：为什么不按主题存储这些文件，而不是在这些预制平面列表中？

例如：

• DatabaseProject
  • Reports
    • （个人存储过程、视图等）
    • SpecificReport
      • （这里有更多对象，必要时进一步嵌套）
  • SpecificApplication
    • （所有类型的 DB 对象，任意深度嵌套）
  • 等等....

明显的缺陷是这种文件夹结构没有对数据库对象施加任何类型的命名空间层次结构。它仅用于组织。因此，很容易引入具有重复名称的对象。您需要某种构建工具来调查数据库项目并死于命名冲突。

我想知道的是：有没有人尝试过这种按应用程序主题在其版本化文件结构中组织 SQL 文件的方法？它值得吗？您是否创建了一个构建工具来监督我所描述的项目？

Answer 1

您应该为您的数据库对象定义一个命名方案，以便清楚使用视图或 SP 的位置。

这可以是描述应用程序模块的前缀，也可以是模块/功能的单独架构名称。

无需嵌套，VCS 中的名称显示与数据库中相同，并根据命名方案正确排序。

Answer 2

我喜欢按主题而不是按名称组织我的 SQL 脚本。通常，我什至将相关项目分组到单个文件中。这样做的主要优点是：

• 您不会将文件系统/IDE 与文件混在一起（其中许多文件只有几行）。
• 整体数据库结构显示更直观。

另一方面，可能更难找到与特定对象相关的源代码......

至于重复名称：它永远不会发生，因为您显然有自动脚本来构建您的数据库。依靠您的文件系统来解决这个问题正在寻找麻烦......

作为结论，我想说的是，您当前的规则总比没有规则要好得多。

Answer 3

我们将 SQL 文件保存在每个项目的“SQL”解决方案文件夹中。这样，每个项目都是单独“安装”的。