I have been looking into SQL Federation since the first release. Database sharding is out of the box. You can split your database to multiple smaller databases when it grows. Federated databases maintain throughput thus your application can serve data without degradation.
Million dollar question: Is SQL Federation good for existing systems?
I am in the same boat as most of the other colleagues. I love SQL Federation. Without thinking twice I will embrace it for Greenfield projects in future.
Reasons -
SQL Federation requires radical change in existing database schema structure. It doesn't support IDENTITY column. Developers have to generate their own. Every table structure must have Clustered Index or else data insertion fails :( Our product line has more than 50 tables. Change in those tables means changes in data access layer. In addition, there is no support for MERGE command yet.
What solution do we have now?
Rather than using SQL Federation, existing systems will use just SQL Azure database. Perhaps each database for each customer just for the sake of argument.Although this architecture suffers from 'Connection Pool Fragemention', migration to Windows Azure platform would be easier with less modifications to existing codebase and database re-architecture.
'Connection Pool Fragmentation' issue is explained clearly by Cihan in his blog here
Cheers,
Milan Gurung
No comments:
Post a Comment