我在我的项目中使用带有联合的 Azure SQL DB，并希望将 sql 脚本保留在解决方案中。在我尝试使用 federation 关键字编辑 sql 代码之前，它从未引起问题。我发现无法将 db 项目与 azure federations 集成。这是一个问题。我只想在我的解决方案中保留 db 模式，但要正确，而不是像只包含 txt 文件。
有什么想法吗？
问问题
118 次
2 回答
2
有一年多的博客文章http://blogs.msdn.com/b/ssdt/archive/2012/01/06/ssdt-does-not-support-sql-azure-federations.aspx谈论 SQL Server不支持联邦的数据工具，如果那是你所追求的。
不完全回答您的问题，但我最终在 VS 2012 中创建了 SQL Server 数据库项目，例如
联合表在 Database.Federated 项目中，每个表都有自己的 .table.sql 文件，但我没有将 FEDERATED ON (cid=CustomerId) 放在该文件中。
相反，我有另一个单个 SQL 文件 (CreateFederatedTables.sql)，其中所有表定义为 FEDERATED ON (cid=CustomerId)，我在 Sql Azure 上手动运行 CreateFederatedTables.sql，我仍然可以使用“发布”选项发布到用于测试的本地 sql。
我已禁用“扩展 Transact-SQL 验证”，因此编译器不会抱怨。
有一些重复，但想不出另一种方法来处理它。
于 2013-11-07T21:22:10.470 回答
1
想提供另一种方法。正如 pateketu 指出的，SSDT 目前不支持这一点，但我仍然发现 SSDT 在联合环境中非常有用，非常值得在 VS 中创建和维护数据库项目。
首先，我为根数据库和每个联合维护单独的数据库项目。根数据库的项目当然与您曾经使用过的任何其他项目一样，因此无需解释。
每个联邦项目都包含我在联邦中需要的所有联邦表、引用表、存储过程和其他对象。要记住的重要部分是，所有联合表都需要首先在您的 federations 中手动创建，而不是从 SSDT 发布（当然不能这样做）。您只需复制和粘贴每个表脚本以及 FEDERATED ON 子句即可轻松完成此操作。（您可以在运行脚本之前添加该子句，或者我直接将它们包含在 SSDT 的脚本中 - 它不会抱怨或删除它们，如果您尝试发布它只会将它们剥离。）
一旦创建了联合表，就可以维护（更改）它们以及所有其他对象类型，并且您可以通过直接连接到每个联合成员数据库来比较和发布更改。数据库具有随机名称，但 Azure 门户应该有助于确定哪些数据库属于哪些联合。
在开发过程中，这一切都非常易于管理，因为我通常每个联邦只有一个成员，当然除了在应用程序中测试联邦逻辑和进行性能测试时。但通常在测试联盟之后，我会剥离到一个成员。
一旦您在生产环境中工作，它仍然非常有用。与任何一个联合成员的目标进行模式比较。而不是发布它，只需生成发布脚本。去掉顶部的所有 SQLCMD 内容（可能是包括 USE [$(DatabaseName)] 命令在内的所有内容），将 FEDERATED ON 子句添加到联合表的任何 CREATE TABLE 命令中（只有在您已经添加了联合表），并且您有基本的模式更新脚本。然后，您可以为每个成员复制并粘贴一次该脚本的全部内容，在每个副本之前使用适用于该成员的 USE FEDERATION 命令。现在您有了一个可以针对您的生产数据库运行的脚本。（希望您有一个独立的开发数据库来反映您的生产数据库的模式，您可以像往常一样首先对其进行测试。）这将在相当短的时间内更新所有成员中的模式，具体取决于有多少成员和你的变化有多极端。与您在生产中用于联合模式更改的任何其他方法一样，无法保证事情在一段时间内不会不同步，从而导致错误。您的应用程序应始终包含重试逻辑。一段时间内不同步，造成错误。您的应用程序应始终包含重试逻辑。一段时间内不同步，造成错误。您的应用程序应始终包含重试逻辑。
显然，这并不像 SSDT 确实支持联邦那样顺利。我试图为可能遇到此问题的任何其他人提出的一点是，即使使用联合，SSDT 在模式开发和生成更新脚本方面仍然有很多提供，与尝试创建的替代方案相比并手动维护模式更新脚本。
（我应该注意，我使用的是 VS 2013 附带的 SSDT，我无法验证我所说的所有内容是否适用于 VS 2012 的 SSDT。）
于 2014-02-09T01:01:29.497 回答