我该如何组织我的主ddl脚本

Jus*_*ard 14 sql sql-server schema ddl

我目前正在为我们的数据库创建一个主ddl.从历史上看,我们使用备份/恢复来对数据库进行版本控制,而不是维护任何ddl脚本.架构非常大.

我目前的想法:

  • 将脚本分成几部分(可能在单独的脚本中):

    1. 表创建
    2. 添加索引
    3. 添加触发器
    4. 添加约束
  • 每个脚本都会被主脚本调用.

  • 我可能需要一个脚本暂时删除约束以进行测试
  • 架构中可能存在孤立表,我计划识别可疑表.

还有其他建议吗?

编辑:此外,如果有人知道自动化部分过程的好工具,我们正在使用MS SQL 2000(旧的,我知道).

Mat*_*rts 5

我认为基本思路很好。

首先构建所有表然后构建所有约束的好处是,可以按任何顺序创建表。完成此操作后,每个表有一个文件,将其放在名为“ Tables”的目录中,然后将一个脚本执行该目录中的所有文件。同样,我有一个用于约束脚本的文件夹(也执行外键和索引),该文件夹在表建立后执行。

我将触发器和存储过程的构建分开,然后最后运行它们。关于这些的要点是它们可以在数据库上运行和重新运行而不会影响数据。这意味着您可以像对待普通代码一样对待它们。您应该在每个触发器和过程脚本的开头包括“如果存在...删除”语句,以使它们可重新运行。

所以命令是

  1. 表创建
  2. 添加索引
  3. 添加约束

然后

  1. 添加触发器
  2. 添加存储过程

在我当前的项目中,我们正在使用MSBuild运行脚本。您可以获得一些扩展目标,这些扩展目标允许您调用sql脚本。过去我也使用过perl,它也很好(还有批处理文件...我不建议这样做-太有限了)。


Ada*_*man 1

你那里的东西看起来不错。我的公司有时,对于足够大的数据库,可能会进一步分解到单个对象级别。这样每个表/索引/...都有自己的文件。可能有用,也可能多余。实际上取决于你如何使用它。

@贾斯汀

按域通常就足够了。我同意这样做会有些复杂,但应该很容易处理。

我认为这种方法提供了更多的分离(在大型数据库中您会欣赏到这一点),同时仍然使其本身非常易于管理。我们还编写 Perl 脚本来对这些 DDL 文件进行大量处理,因此这可能是处理该问题的一个好方法。