我应该如何组织我的主DDL脚本
我目前正在为我们的数据库创建一个主ddl。从历史上看,我们曾使用备份/还原来对数据库进行版本控制,并且未维护任何ddl脚本。该架构非常大。
我目前的想法:
- 添加索引
- 添加触发器
- 添加约束
- 每个脚本将由主脚本调用。
- 我可能需要一个脚本来暂时删除约束以进行测试
- 模式中可能有孤立的表,我打算确定可疑的表。
还有其他建议吗?
编辑:另外,如果有人知道可以自动化部分过程的好的工具,那么我们正在使用MS SQL 2000(我知道是旧的)。
解决方案
回答
我们那里拥有的东西似乎还不错。有时,对于足够大的数据库,我的公司甚至将其细分,甚至分解到单个对象级别。这样,每个表/索引/ ...都有其自己的文件。可能是有用的,可能是矫kill过正。确实取决于使用方式。
@贾斯汀
按域基本上总是足够的。我同意以这种方式进行处理时需要解决一些复杂问题,但这应该很容易处理。
我认为这种方法提供了更多的分离(在大型数据库中,我们将不胜感激),同时仍然使其自身易于管理。我们还编写了Perl脚本来对这些DDL文件进行大量处理,因此这可能是处理该问题的一种好方法。
回答
请花费时间来编写通用的"删除所有约束"脚本,这样我们就不必维护它。
将光标放在以下语句上可以达到目的。
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。到目前为止,它工作正常,但是如果我们在数据库中使用CLR函数,则可能会出现一些故障。
回答
我认为基本思路很好。
首先构建所有表,然后构建所有约束的好处是,可以按任何顺序创建表。完成此操作后,每个表有一个文件,将其放在名为" Tables"的目录中,然后将一个脚本执行该目录中的所有文件。同样,我有一个用于约束脚本的文件夹(也执行外键和索引),该文件夹在表建立后执行。
我将触发器和存储过程的构建分开,然后最后运行它们。关于这些的要点是它们可以在数据库上运行和重新运行而不会影响数据。这意味着我们可以像对待普通代码一样对待它们。我们应该在每个触发器和过程脚本的开头包括"如果存在...删除"语句,以使它们可重新运行。
所以命令是
- 表格创建
- 添加索引
- 添加约束
然后
- 添加触发器
- 添加存储过程
在我当前的项目中,我们正在使用MSBuild运行脚本。我们可以获得一些扩展目标,这些扩展目标允许我们调用sql脚本。在过去,我使用过的perl也很好(还有批处理文件...我不建议这样做太有限)。
回答
如果我们正在寻找自动化工具,我经常与EMS SQLManager一起使用,它可以让我们从数据库自动生成ddl脚本。
在使数据库联机之前,可能必须在参考表中插入数据。这甚至可以视为ddl脚本的一部分。 EMS还可以为现有数据库中的数据插入生成脚本。
在ddl阶段可能无法正确估计索引需求。我们只需要为主/外键声明它们。一旦定义了视图和查询,其他索引应在以后创建
回答
有一个整洁的工具可以遍历整个sql服务器,并将所有表,视图,存储过程和UDF定义提取为SQL脚本(文本文件)到本地文件系统。我曾在2005年和2008年使用过此功能,但不确定如何在2000年使用。查看http://www.antipodeansoftware.com/Home/产品