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

Question

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

我目前的想法：

• 将脚本分成几部分（可能在单独的脚本中）：

  1. 表创建
  2. 添加索引
  3. 添加触发器
  4. 添加约束

• 每个脚本都会被主脚本调用。

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

还有其他建议吗？

编辑：此外，如果有人知道自动化部分过程的好工具，我们正在使用MS SQL 2000（旧的，我知道）。

Answer 1

我认为基本的想法是好的。

首先构建所有表然后构建所有约束的好处是可以按任何顺序创建表。 当我这样做时，每个表有一个文件，我把它放在一个名为“Tables”的目录中，然后是一个执行该目录中所有文件的脚本。 同样，我有一个约束脚本的文件夹（它也做了外键和索引），它们是在构建表之后执行的。

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

所以订单就是

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

然后

4. 添加触发器
5. 添加存储过程

在我当前的项目中，我们使用MSBuild来运行脚本。 您可以获得一些扩展目标 ，允许您调用sql脚本。 在过去我使用的perl也很好（和批处理文件......我不推荐 - 太有限了）。

Answer 2

有一个巧妙的工具将遍历整个sql服务器并将所有表，视图，存储的进程和UDF定义作为SQL脚本（文本文件）提取到本地文件系统。 我在2005年和2008年使用过它，不知道它如何与2000一起使用。 查看http://www.antipodeansoftware.com/Home/Products

Answer 3

你在那里的东西似乎很不错。 我的公司有时会为足够大的数据库进一步细分，可能是针对单个对象级别。 这样每个table / index / ...都有自己的文件。 可以有用，可能有点矫枉过正。 真的取决于你如何使用它。

@Justin

通过域名大多总是足够的。 我同意以这种方式处理时有一些复杂的问题，但这应该很容易处理。

我认为这种方法提供了更多的分离（在大型数据库中你会得到欣赏），同时仍然使自己非常易于管理。 我们还编写Perl脚本来处理这些DDL文件的大量处理，因此这可能是一种处理它的好方法。

Answer 4

花时间写一个通用的“删除所有约束”脚本，这样你就不必维护它了。

对以下语句的游标就可以了。

Select * From Information_Schema.Table_Constraints 

Select * From Information_Schema.Referential_Constraints

Answer 5

@亚当

或者仅仅通过域 - 在同一个文件中对相关表进行有用的分组，但与其他表分开？

唯一的问题是，如果某些域（在这个有点遗留系统中）是紧密耦合的。 此外，您必须维护不同子脚本之间的依赖关系。

Answer 6

如果您正在寻找自动化工具，我经常使用EMS SQLManager，它允许您从数据库自动生成ddl脚本。

在将数据库联机之前，可能必须在参考表中插入数据。 这甚至可以被视为ddl脚本的一部分。 EMS还可以为现有数据库中的数据插入生成脚本。

在ddl阶段可能无法正确估计对索引的需求。 您只需要为主键/外键声明它们。 一旦定义了视图和查询，就应该在以后创建其他索引

Answer 7

我以前组织了我的DDL代码，每个实体由一个文件组织，并制作了一个工具，将其组合成一个DDL脚本。

我的前雇主使用了一个方案，其中所有表DDL都在一个文件中（以oracle语法存储），在另一个文件中有标记，在第三个中有约束，在第四个中有静态数据。 更改脚本与此保持并行（再次在Oracle中）。 转换为SQL是手动的。 这是一团糟。 我实际上写了一个方便的工具，它将Oracle DDL转换为SQL Server（它在99.9％的时间内工作）。

我最近转而使用Visual Studio Team System for Database专业人员 。 到目前为止，它工作正常，但如果您在数据库中使用CLR函数，则会出现一些问题。