我目前正在为我们的数据库创建一个主 ddl。从历史上看，我们使用备份/恢复来对我们的数据库进行版本控制，并且没有维护任何 ddl 脚本。架构很大。
我目前的想法：
将脚本分成几部分（可能在单独的脚本中）：
每个脚本都会被主脚本调用。
还有其他建议吗？
编辑：另外，如果有人知道自动化部分流程的好工具，我们正在使用 MS SQL 2000（旧的，我知道）。
【问题讨论】：
标签： sql sql-server schema ddl
你那里的东西似乎很不错。对于足够大的数据库，我的公司有时会将其进一步细分，可能会细分到单个对象级别。这样每个表/索引/...都有自己的文件。可能有用，也可能矫枉过正。真的取决于你如何使用它。
@贾斯汀
按域通常就足够了。我同意这样做有一些复杂性需要处理，但这应该很容易处理。
我认为这种方法提供了更多的分离（在大型数据库中您会意识到这一点），同时仍然使自己非常易于管理。我们还编写了对这些 DDL 文件进行大量处理的 Perl 脚本，因此这可能是一种很好的处理方式。
【讨论】：
花时间编写一个通用的“删除所有约束”脚本，这样您就不必维护它了。
将光标悬停在以下语句上即可。
Select * From Information_Schema.Table_Constraints
Select * From Information_Schema.Referential_Constraints
【讨论】：
@亚当
或者仅按域如何——在同一个文件中对相关表进行有用的分组，但与其他表分开？
唯一的问题是某些域（在这个有些遗留系统中）是否紧密耦合。另外，您必须维护不同子脚本之间的依赖关系。
【讨论】：
我之前按每个实体一个文件组织了我的 DDL 代码，并制作了一个将其组合成单个 DDL 脚本的工具。
我的前雇主使用了一种方案，其中所有表 DDL 都在一个文件中（以 oracle 语法存储），索引在另一个文件中，约束在第三个文件中，静态数据在第四个文件中。更改脚本与此并行保存（同样在 Oracle 中）。到 SQL 的转换是手动的。这是一团糟。我实际上编写了一个方便的工具，可以将 Oracle DDL 转换为 SQL Server（它在 99.9% 的时间里都有效）。
我最近改用Visual Studio Team System for Database professionals。到目前为止，它运行良好，但如果您在数据库中使用 CLR 函数，则会出现一些故障。
【讨论】：
我认为基本的想法是好的。
首先构建所有表然后构建所有约束的好处是可以按任何顺序创建表。完成此操作后，每个表都有一个文件，我将其放入名为“Tables”的目录中，然后是执行该目录中所有文件的脚本。同样，我有一个用于约束脚本的文件夹（也包含外键和索引），这些脚本在构建表后执行。
我会将触发器和存储过程的构建分开，并在最后运行它们。关于这些的要点是它们可以在数据库上运行和重新运行而不会影响数据。这意味着您可以像对待普通代码一样对待它们。您应该在每个触发器和过程脚本的开头包含“if exists...drop”语句，以使其可重新运行。
所以顺序是
然后
在我当前的项目中，我们使用 MSBuild 来运行脚本。您可以获得一些extension targets，它允许您调用 sql 脚本。过去我使用过 perl，这也很好（还有批处理文件......我不推荐 - 这太有限了）。
【讨论】：
如果您正在寻找自动化工具，我经常使用 EMS SQLManager，它允许您从数据库自动生成 ddl 脚本。
在将数据库上线之前，可能必须在引用表中插入数据。这甚至可以被视为 ddl 脚本的一部分。 EMS 还可以为现有数据库中的数据插入生成脚本。
在 ddl 阶段可能无法正确估计对索引的需求。您只需要为主键/外键声明它们。一旦定义了视图和查询，其他索引应该稍后创建
【讨论】：
有一个简洁的工具可以遍历整个 sql server 并将所有表、视图、存储过程和 UDF 定义提取到本地文件系统作为 SQL 脚本（文本文件）。我已经在 2005 和 2008 中使用过它，但不确定它如何与 2000 一起使用。查看http://www.antipodeansoftware.com/Home/Products
【讨论】：