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