Emulate/Simulate SQL Azure Locally?

2019-07-09 20:44发布

问题:

Slightly OT from regular MS development stuff.

I would like to write my next .NET 4.0 app using MSSQL 2008 as the DB, but configure the store and access methodologies in such a way as to be "Azure ready", so when the new fiscal year starts in the summer we can conceivably do something low impact like just change a connection string (I know there would be more to it than that) and we can just use SQL Azure.

I did see the stuff at http://www.microsoft.com/en-us/sqlazure/videos.aspx

Have any gurus seen advice/pointers on how to do that?

Thanks.

回答1:

Azure has local simulators already in the SDK, you can just use those.

As for switching from SQL 2k8 to Azure SQL, keep in mind that you will lose a LOT of functionality. Azure allows no user defined types, no full text searches, and also drops a lot of system functions.

Azure SQL is limited to 10 GB per database, no exceptions. And you cannot do cross database queries.

SQL Server Features not Supported in Azure: http://msdn.microsoft.com/en-us/library/ff394115.aspx

T-SQL Features not supported in Azure: http://msdn.microsoft.com/en-us/library/ee336250.aspx



回答2:

You might want to look at the SQL Azure vs. SQL Server comparison info page here. This will help you avoid some features that aren't yet found in SQL Azure. You can then build for SQL Azure while using SQL Server locally. Some common things to look out for when targeting SQL Azure:

  • Certain sys tables aren't present
  • There's no distributed transactions
  • You can't connect from one database server to another
  • Each table needs a clustered index

You can also check out the SQL Azure Migration Wizard. This tool will perform a compatibility analysis for you and migrate your schema to SQL Azure.



回答3:

Personally I wouldn't bother.

I just use an SQL Azure Database for dev and testing. That way you can be sure it will work.

David Makogon is correct with the list of what is not there. When I migrated a large application to azure I found the biggest pain to be the lack of SELECT INTO which I had used to populate temp tables in a number of stored procs.

For 7GBP a month you can develop against a real azure database and be 100% certain it will work when you migrate.

Cheers



回答4:

If you'd prefer to develop on-premise, you can use Red Gate's SQL Compare and Data Compare to push up the changes. As long as you do this regularly, you'll find out whether your on-premise SQL is SQL-Azure compatible so you won't risk using unsupported syntax or object types.