With the release of SQL Server Everywhere Edition looming on the horizon, Scott Swigart was able to sit down with Mark Jewett, Senior Product Manager of the SQL Server Team, and Steve Lasker, Program Manager and Technical Lead, to find out what's what with the new database engine.
DDJ: Microsoft is coming out with SQL Server Everywhere Edition. What is it and why do we need yet another database?
MJ: SQL Server Everywhere Edition is, very simply, a database designed for a client environment, for client applications. First, it's only about 1.5 MB and when you compare that to other SQL Server products, it's a very small footprint, which also makes it easy to download. Second, it runs in-process. The end user of the application doesn't even need to be aware that there's a database. It just operates seamlessly within that application. Third, everything developers know about SQL Server today is applicable knowledge; in other words, the T-SQL and objects that you are familiar with if you use SQL Server today. You have many of those same things with SQL Server Everywhere Edition.
SL: When we started to go public with what we're doing with SQL Server Everywhere Edition, people said, "Oh, great, that's exactly what I wanted," and then often the very next question was, "How do I synchronize with the data store?" Everyone wants one big database that stores everything, but that never happens. Most companies can't even consolidate where they have their list of phone numbers, much less consolidate all the data. Once you accept that you're going to have many databases within an organization, the question is, how do you get those disparate data islands to communicate? That goes back to the synchronization strategies we're working on with SQL Server Everywhere Edition.
DDJ: There are some applications that are never going to synchronize with SQL Server, but there are a lot of applications that want to work offline and sync, or just want to cache local data for performance. What are some of the SQL Server Everywhere Edition features that support those scenarios?
SL: When using SQL Server Everywhere Edition, it's focused on having the proper subset of the SQL Server product features. From day one, it's used a subset of the T-SQL language. The technologies that developers may need to deal with are growing at an exponential rate. The number of technologies that we deal with inside of Microsoft is growing exponentially. Developers can't keep up with 15 ways to do the same task. But, if you can use the same skills when you start with the client, and move to the server, that helps keep developers productive. That's where SQL Server Everywhere Edition takes off. It uses the T-SQL syntax and the ADO.NET programming model. It's a subset of the SQL Server feature set.
Now, when data gets spread out in the field, how do you roll it up in the central store? If you have data in the central store, how do you push it out to the field? How do we make that easy? One part of the answer is that SQL Server Everywhere Edition has a subset of the SQL Server data types. So we don't have the data conversion issues that you would have with Jet or other local database options. For example, we have nchar and nvarchar. SQL Server has data types like XML, which SQL Server Everywhere Edition doesn't yet support, and in that case, we convert it to NTEXT. We don't lose any of the data, we just don't have the XQuery functionality in SQL Server Everywhere Edition that you have with SQL Server 2005.
Once we get past what we're doing with our 3.1 release, we'll build on that in our 3.5 release with a new set of synchronization components. The synchronization components will also have a better together story with SQL Server, even though they will let you sync with other back ends. You'll be able to leverage your existing ADO.NET knowledge, and extend that with a component model that does synchronization. We're referring to that as our "synchronization framework." If you think about ADO.NET DataAdapters, we'll be shipping SyncAdapters which let you compose together a synchronization infrastructure between a server and the client.
