我们是一个小团队,支持在我们的SQL Server实例中包含数据的各种第三方应用程序。以前我们没有对在SSMS 2008下运行时编写的无数脚本进行源代码控制,但现在我们正在迁移到SSMS 2012,我希望引入TFS来控制数据库脚本。
在将SQL(非表)对象引入TFS时,我们是否应该为每个数据库创建一个单独的项目?
我们的SQL Server拥有多个数据库,通常每个第三方应用程序都有一个数据库,但它们之间存在一些功能交叉(例如,来自多个源的数据聚合)。
似乎使用TFS 项目导入数据库功能(在VS2013中)强制SQL对象进入顶级Project文件夹,而不为该特定数据库创建子文件夹。我担心的是我们在不同的数据库中使用了相同名称的Schema。
e.g。我们有数据库:" App1"," App2"," App3"每个都有各种Schema,其中一个是" Tools"模式,这存在于所有3个数据库中。
当我们将这3个数据库导入TFS时,它们都位于同一个\ SSMS根项目中,因此"工具"对象可能会发生冲突(?)。相反,我们应该为这些数据库创建一个项目吗?感谢。
答案 0 :(得分:1)
这可能更多是关于解决方案的问题,以及如何组合项目。更少关于项目本身的概念。要回答原始问题是,您需要为每个数据库创建一个项目。可能不止一个。
对于这些第三方应用程序中的每一个,我假设您指的是其他一些供应商的产品数据库。如果是这种情况,您可能希望在安装时导出每个数据库的Dacpac,而不进行自定义。有些供应商对在他们的数据库中创建新对象感到焦虑,有些供应商甚至会使保修失效,有些供应商只是在升级过程中不加选择地丢弃对象。因此,您需要一种方法将他们的工作与您的工作分开。显然,这是一个完美的世界,您可以在其中部署供应商应用程序的干净安装(也许在开发环境中),捕获Dacpac和Due模式比较以获取自定义对象并继续前进。
最终结果将是一个解决方案,其中包含一个项目,其中包含对供应商数据库的DacPac的数据库引用。您的自定义将位于供应商数据库的上方。当供应商升级他们的数据库时,抓住干净数据库的新dacpac,然后针对它测试你的代码。
如果这些是内部开发的应用程序,或者您正在修改供应商代码,那么数据库导入将正常工作。
如果需要同步的所有数据库之间共享通用工具。在同一解决方案中,您可以为公共对象创建后续项目,并将该数据库引用到主项目。这个常见的工具项目可以由其他解决方案共享而没有问题,只要构成是通用工具并且不特定于数据库模式。如果项目特定于数据库,则将其放入相应的项目中,否则将其放入公共工具数据库中。