The future of SQL Server Express?

  • Thread starter Thread starter Mitchell S. Honnert
  • Start date Start date
M

Mitchell S. Honnert

In the early days of .NET development, I could react to user's hesitancy to
download the Framework with reassurance that it would eventually be included
in a future service pack. I also pointed out that once the Framework was
installed, later .NET applications could be installed without another hefty
download. I knew that any pushback I'd get would be moot in a few months
when the Framework was integrated into Windows.

I'm wondering if I'll be able to give similar types of reassurances for SQL
Server Express. Does anyone know if Microsoft has any plans on including
SSE in...

....a future service pack for XP?

... as part of the installation of an MS application? (As in, maybe MS will
"eat its own dog food" and use SSE as the back-end to Outlook or another of
its applications.)

....in Vista?

I know there are larger (i.e. legal) issues at play here, but from a
programmers standpoint, it'd be fantastic to know that the primary OS of my
target users already included an available local database engine.

Thanks,

- Mitchell S. Honnert

PS: As a bit of background, I'm using SSE as the back-end of a standalone
"audio file manager" application. I use SSE to cache the MP3 tag metadata
in a user's audio file collection. I used to use MS Access, but when SQL
Server Express became available, I jumped at the chance to use a "real"
database. But I'm starting to rethink that decision to switch databases. I
may have had to implement some semi-kludgy workarounds to get Access to do
what I wanted, but I didn't require my end users to have to download and
install a component that dwarfed my own application. But even more
importantly, with MS Access I just had to include a template database file,
whereas with SSE, I now require my users to install a service that keeps on
running in the background even when they're not using my application.
 
SQL Express would never be integrated into windows... just like what it
really is (MSSQL Desktop edition) has never been.. SQL Express is not a part
of .NET nor is it a runtime, it is a database server... therefore it is a
seperate applicaiton from windows not an extension of it like .NET was
 
I understand that SSE is not part of the .NET Framework. But just because
it's not, it doesn't necessarilly follow that it would never be integrated
into Windows. One could argue that both the Framework and SSE extend the
functionality of Windows, so both are legitimate inclusions to the OS.

Your point about MSDE never being included in Windows is well taken though.
I guess my hope would be that with the switch from MSDE to SSE, there might
be a corresponding change-of-heart about treating database functionality as
just another feature of the operating system.

Microsoft got away with selling the web browser as part of the OS. Why not
a database engine that would be available to any program that wanted to use
it? I'd think a local database engine would be an easier sell than a web
browser.

- Mitchell S. Honnert
 
database engines like SQL Express use up a LOT of memory and resources..
they are just designed as a trainer for people that are starting to use SQL
servers or developing an app that will move eventually to a dedicated
server... the are not really designed for home use
 
database engines like SQL Express use up a LOT of memory and resources..
OK. The concern over this overhead is, in part, what prompted my initial
question.
they are just designed as a trainer for people that are starting to use
SQL servers or developing an app that will move eventually to a dedicated
server... the are not really designed for home use
Click to expand...
I'm not sure I agree. If you need a local database and MSDE or SSE meets
the requirements, why would you pay for the full version of SQL Server?
Besides, even if you were to find an official declaration from Microsoft
that they only intend SSE to be used as a "trainer", this would be all but
meaningless. People are going to use the tools available to maximize use
and minimize cost. MS Access itself wasn't designed to be used as a
replacement for SQL Server, but regardless of what Microsoft or a company's
DBAs think, sometimes it is.

As for how this affects the chances of SSE ever getting integrated into the
OS, I still hold on to the opinion that it would be a good thing to
eventually have this functionality built into the OS. In fact, the original
question was prompted by a memory of reading something about some
database-like features making it into the next version of Windows. (Might
have been WinFS, but I can't remember.)

- Mitchell S. Honnert
 
I understand that SSE is not part of the .NET Framework. But just because
it's not, it doesn't necessarilly follow that it would never be integrated
into Windows. ...
Click to expand...

It would be illogical to integrate it into Windows. One might as well
integrate MS Works or MS Office as SQL Server.
 
From a practical standpoint, I didn't think it was very likely that SSE
would be integrated into the Windows. I wasn't holding my breath waiting
for this, but I did think it was worth a shot to see if anyone heard any
news on this front.

But from a purely logical standpoint, my view is that it *would* be logical
for MS to integrate SSE into Windows. One of the key distinctions that I
see between MS Works (one of your examples) and SQL Server Express is the
target audience. SSE is most likely going to be used by developers, whereas
MS Works is targeted at end-users. So, from a logical standpoint, MS could
make the case that they would be adding a new component to Windows to make
it easier for developers to create new applications. The same could be said
for .NET itself. Logically .NET and SSE fit into this same category.

Besides, as I mentioned in another thread of this discussion, MS got away
with selling Internet Explorer as a integral part of Windows. They were
able to blur the lines between "application" and operating system "feature".
If they can do this, albeit with a lot of legal hassles, then why not with
SSE, something that is arguably more a extension of the natural functions of
an operating system?

One other issue: my question also related to the possibility of MS using SSE
as the back-end for one of their own products. If for example, MS decided
to use SSE to store local Outlook data or some other Office application's
data, it would go a long way to making SSE more of a "standard" component.
"You use Office '09? Great. Then you are already running SSE and don't have
to download it to run our app."

- Mitchell S. Honnert
 
....
But from a purely logical standpoint, my view is that it *would* be
logical for MS to integrate SSE into Windows.
Click to expand...
....

To me that's like insisting on supplying a pool with every house - even in
Northern Michigan.
 
To me that's like insisting on supplying a pool with every house - even in
Northern Michigan.
Click to expand...
Yep. A similar argument was made with Internet Explorer. Many people said,
"Hey, wait. I don't want a web browser in my OS. I don't want to have to
pay for something I'm not using." But the way that Microsoft played it was
that they had already integrated the "feature" into the OS and that it would
be more trouble than it was worth to remove it now. (Whether that's true or
not is a matter for another thread or even another ng.)

To use your analogy, it would be like a nationwide-chain home builder
telling you that they gain economies-of-scale by building homes to a cookie
cutter design. "You live in Northern Michigan? That's nice, pal, but our
builders are trained to slap up a house based on a standard design. If you
want it changed, then you gotta pay extra. A *lot* extra."

It's the same principle with SSE. I know we're getting into more of an
academic discussion here, but it wouldn't surprise me in the least if
Microsoft chose to tie some Windows functionality to SSE, even if it were a
just pretext to slip SSE in. For example, what if MS were to install SSE as
part of Vista to store Windows events? You could access the event log using
the normal API's or you could just run a standard SQL query on a table or
public view. I'm not saying this is going to happen; just that there are a
host of functions in Windows that could naturally and logically take
advantage of a normalized, local database engine.

And like many other Windows features, you'd have to pay for it regardless of
whether you used it or not. (MS has to add new features to justify their
upgrade charges, right?) It would be cost-prohibitive to take the feature
out. So, even though you don't plan on using the pool, if you buy the
house, you'd get the pool.

Again, I find this to be an interesting discussion, but I don't think MS is
going to integrate a local database engine into the OS any time soon. But I
personally think this has more to do with the fact that MS is focused on
larger issues and less on the practicality of doing so.

- Mitchell S. Honnert
 
Back
Top