https://stackoverflow.com/questions/19818358
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianWanted to offer another approach. As pateketu pointed out, SSDT does not currently support this, but I've still found SSDT to be very useful in a federated environment, and well worth creating and maintaining database projects in VS.
First, I maintain separate db projects for the root database, and for each federation. The project for the root database is of course like any other you've ever used, so no explanation necessary.
Each federation project contains all of the federated tables, reference tables, stored procs, and other objects I need in the federation. The important part to remember is that all federated tables need to be manually created first in your federations, rather than published from SSDT (which of course cannot be done). You can do this pretty easily just by copying and pasting each table script, along with the FEDERATED ON clause. (You can add the clause before running the scripts, or I just go ahead and include them in the scripts in SSDT - it doesn't complain or remove them, it just strips them off if you try to publish.)
Once the federated tables have been created, they can be maintained (altered), along with all of your other object types, and you can compare and publish changes by connecting directly to each of the federation member databases. The databases have random names, but the Azure portal should help with figuring out which databases belong to which federations.
During development, this is all pretty manageable, because I normally only have one member per federation, except of course when testing the federation logic in the app and doing performance testing. But then normally after testing the federations, I'll strip back down to a single member.
Once you're working against a production environment, it can still be very useful. Do a schema compare against a target of any one of your federation members. Instead of publishing it, just generate the publish script. Strip out all of the SQLCMD stuff at the top (will probably be everything up to and including the USE [$(DatabaseName)] command), add the FEDERATED ON clause to any CREATE TABLE commands of federated tables (which will only be there if you've added federated tables), and you have your basic schema update script. Then you can copy and paste the entire contents of that script once for each member, preceding each copy with the USE FEDERATION command appropriate for that member. Now you have a script you can run against your production database. (Hopefully you have a separate development database that mirrors the schema of your production database, which you can test it on first, as always.) This will update schema in all members in a fairly short period of time, depending on how many members and how extreme your changes are. As with any other method you use for federation schema changes in production, there's no guarantee that things won't be out of sync for a period of time, causing errors. Your app as always should include retry logic.
Obviously, this is not as smooth as if SSDT did support federations. The point I've tried to make for any others that may come across this, is that even when using federations, SSDT does still have a lot to offer in terms of schema development and generating update scripts, compared to the alternative of trying to create and maintain schema update scripts by hand.
(I should note that I'm using SSDT that comes with VS 2013, I can't verify that everything I've said is true of the SSDT available for VS 2012.)
