Local Data Storage
DDJ: Let's say someone is working on something like Microsoft Money, which doesn't need to sync to any central server. You don't need to do anything more than back it up. What makes SQL Server Everywhere Edition a good engine to pick for strictly the local data storage scenario?
SL: There are a couple great questions there to think about. The first question is, "What functionality do I need?" If all I care about is local storage and I don't need to sync something like a product catalog, then you might look at your engine and ask, "Is it small? Can I put it in my application?" In many cases it's the application that's central, not the database that you've chosen for storage. You might also ask, "Does it impact the installation or runtime experience of my overall app?" SQL Server Everywhere Edition being small, lightweight, and in proc, makes it a great fit for that. Once you get beyond that, you have to look at its core features. For example, "Does the engine have a query processor?" Absolutely. "Will it be able to handle additional loads?" When you only had 10 products, you might have been able to use XML or a text file, but once you get to hundreds or thousands of products, you may run into issues that you never had before. That's where having a query processor helps in two ways. First, it lets you get a subset of the data in an efficient way. Second, how do you bring just the information that you're querying into memory? With XML, you can query an XML document for certain elements, but often you've had to pull the whole XML file into memory to do that query.
Transactions also become important. Say I want to make an update, do a delete, or do an insert. If something fails because I lost power, dropped the device, or violated a business rule, how do I ensure that things are committed in an all-or-nothing boundary? In many places, people say that if you just give them a query processor and transactions, that's all they need.
There are a couple products that currently meet that bar. Then, you need to look down the road two or three years, and look at where Microsoft is going to be making future investments. As new scenarios become important, for example XML as a database data type, or new hardware architectures evolve, you have to ask if the database engine is going to continue to be enhanced. Will the engine run natively on 64 bit, for example? In the long run you have to look at where Microsoft is strategically investing. Microsoft is saying, very publicly, that SQL Server Everywhere Edition is a very important strategic investment. From a tooling perspective, Visual Studio will be doing a lot of work to make sure that SQL Server Everywhere Edition is a primary focus in our development experience.
DDJ: You've mentioned that you'll be shipping Version 3.1 before Visual Studio "Orcas", and Version 3.5 with Orcas. You've also mentioned that, even though it's called SQL Server Everywhere Edition, there really is no "Server" to install, it's just several DLLs. So I'm guessing that in the future, one application could be running against Version 3.1, and you could drop a new application on the same machine that's using Version SQL Server Everywhere Edition 3.5, and both database engines can just run side-by-side. Is that correct?
SL: That's a fundamental principal of what we're trying to do here. If I have App 1 installed and working, and I install App 2, I want to make sure that App 1 doesn't break. We will absolutely support side-by-side installations of SQL Server Everywhere Edition. There are pros and cons to that, but for most of our customers, they see side-by-side as a pro. If App 1 is running against Version 3.1, and Version 3.5 comes out, App 1 keeps running against Version 3.1 until the development team for App 1 decides that they want to move it to 3.5.
