July 17, 2009 at 8:40 pm
Comments posted to this topic are about the item SQL Server vs. JET
July 18, 2009 at 5:06 pm
In the mid '90's MSFT did an audit & found it was developing 42 different database engines, most used internally for features within each product. So the paper recommended they consolidate to just 4; a Server DBMS (SQL), a lightweight desktop DB (Access based), a streaming media server & one other I've forgotten. So over the next few years much of that consolidation took place. Hence System Centre & other products now use SQL. It is also why they invested so much work in WinFS (while this hasn't shipped in the OS, it was the basis of many of the new storage capabilities in SQL 2005/8).
Around SQL2000 timeframe it was planned to have Exchange use SQL. To that end the company re-orged & both teams reported into the same VP. But at the time there was too big a gap, SQL was relational & didn't support text really well. Exchange was highly optimised for text especially in areas of compression & splitting/storing message fragments. The result was SQL2000 was 15 times larger than the equivalent in Exchange. And one of Exchange's biggest issues was its customers where hitting database size limits.
So this work was parked while SQL improved its ability to store non-traditional data ie: Features like XML, Varchar(MAX), Integrated Full Text Search rose in priority which caused other really cool features to be pushed into the future.
In short. Using SQL within Exchange is not a new idea within Microsoft. Yes, there are things to consider; taking a dependency on another team, pricing (ie: is SQL embedded for free), is it feasible.
It should not surprise you that they review these questions from time to time. With each SQL release the gap gets smaller. So I expect that sometime in a future release this integration is likely to happen. Until then you should not infer anything about SQL's suitability for the task. There are a huge number of features Microsoft would like to put into both SQL & Exchange. Unfortunately, like every business, they have a finite dev/test capability. Doing the integration work would push other features into a future release. This feature trade-off is always unpleasant; it’s like being forced to choose which of your babies gets to live. There are some really exciting features slated for the next 2 major SQL releases, I'd hate to see any of those dropped in order to complete this integration work. But perhaps they will, I’m no longer in a position to vote.
Thanks for your interesting article.
July 19, 2009 at 8:47 am
Very interesting editorial on the Jet vs MSSQL although I think that bringing Exchange into the disscusion is a bit of a red herring. Microsoft has been trying to get ride of MSACCESS for years and yet access remains. MSACCESS could have been ported to MSSQL and yet it hasn't been.
Maybe the Jet is better than MSSQL(in some casses at least). Maybe the Jet is the one example of NON-blotware in all of Microsoft.:)
July 19, 2009 at 3:30 pm
May be worth noting that JET (Blue) used by Exchange is a very different beast to JET (Red) which is used by Access.
Both JET projects started in the late 1980's. With Blue being Transactional & Red smaller footprint. So really this original editorial had little to do with MS-Access.
But you are correct in stating that most in the SQL team & may SQL folks would prefer that Access apps used SQL as its native database. Most Office folks would see its future differently. They align its capability closer to Sharepoint. (Worth mentioning that Sharepoint uses SQL. So over time this integration may still happen. Especialy as SQL incorporates some of the ease of deployment features that Access desktop users desire.
July 19, 2009 at 7:58 pm
With Access they've tried, and you can set up essentially the Express engine for Access apps.
I think we are getting closer with Exchange, but I'd like to see the specific reasons why SQL isn't used. It would help us better understand how Exchange works, and perhaps what workloads don't work as well with SQL Server.
July 20, 2009 at 7:45 am
Very susinctly put Steve. I was a bit obtuse in my motive for bringing access into the discussion. The point is that SQL is a theory, the Jet, MSSQL, Oracle and many more are impimentations of engines to actualize the theory. The misunderstanding is obvious in the "NO SQL" debate. There is a need and a place for both Jet and MSSQL until it is demonstrated that "one ring can rule them all":-D
July 20, 2009 at 8:14 am
Could it be that the Exchange team thinks in "spreadsheets" and not sets?
I used a lot of "table" storage mechanisms over the years and could typically beat the pants off of generalized tools like SQL or Access. There were trade-offs. I got raw performance at the expense of things like ease of use. Coming from a procedural background I could see where they would want to make their light weight storage engine better and not have to re engineer the whole data laye t conform to SQL Server.
Then there is the whole licensing thing. If you let Exchange get away with embedding full SQL Server with no governors where does that put Express? I'll guess that a lot of big Exchange installs blow past Express limits without skipping a beat. The Exchange folks have got to be revolting against the "free" version having limits and then having to pay through the {insert favorite body part analogy here} when you cross a certain line in the sand.
ATBCharles Kincaid
July 20, 2009 at 8:54 am
The licensing isn't a big deal to me. You allow SQL Server as a part of any Exchange license, but only for Exchange databases. If you put something else on the box, you need another SQL license. That's an administrative/compliance issue.
July 20, 2009 at 8:57 am
I'm not sure if the JET (Exchange/blue) engine is better than SQL. Or if it tackles a different problem, but from my basic understanding of Exchange, I'm not sure why SQL Server doesn't work. There are plenty of mail add-ons, telco type applications, etc. that use SQL Server or Oracle (or DB2) and perform great. So why doesn't the Exchange mail store fit for SQL Server?
It's a knowledge issue. If there are things that JET does better, list a few of them and let the SQL team work on them.
July 20, 2009 at 9:14 am
I think it's quite ironic that Exchange - a 64-bit only product - still uses Jet, when Microsoft have explicitly stated that they are never going to release a 64-bit version of the Jet OLEDB drivers. :crazy:
http://blogs.msdn.com/sqldev/archive/2008/10/22/msjet-4-0-in-64-bit-environment.aspx
July 20, 2009 at 11:01 am
Excellent article. Didn't really know that SQL would/may not be used for Exchange. Most DBAs that I know were mentioning that SQL would be used with or within Exchange.
It's really too bad it they stay on this route. I can just think of all the excellent reports you could develop with SSRS. Also they could get away of the mail box limits if they used SQL. Need more space, just add disks!
You think they would promote SQL more now with cloud computing around.
Thanks for the information and all the great comments.
Rudy
Rudy
July 20, 2009 at 12:47 pm
It would seem reasonable that SQL, being a general purpose relational database probably carries a lot of overhead that simply is not needed in the much more tightly controlled world of Exchange. General purpose tools are great, but there are times when volume, and the ability to specify the exact operation service would make a specialized tool more suitable.
...
-- FORTRAN manual for Xerox Computers --
July 20, 2009 at 3:36 pm
On Cost: MS already makes a version of SQL (Express) with the limits removed that it embeds with other its other products. The SQL in Small Business Server version is different. It is their product they can choose to package it how they want with other products. Putting SQL in Exchange is a marketing / pricing decision that is not hard to solve.
On Jet & ODBC: These are very different things. JET (Joint Engine Technology) was a project with 3 different deliverables; JET Red, JET Blue & JET Black. JET Black died. JET BLUE (the transactional DB engine) was used by the Exchange team & has continued to evolve. JET RED (the lightweight desktop non-transactional engine) was used in many products but made famous as the engine under ACCESS & made available to 3rd party developers via MS Development Tools (ie Visual Basic / C) & ODBC API.
As an analogy, in this thread refering to JET is like using the term "The Americas" then arriving in Chile & expecting them to speak "American".
On the "SQL Shortfall": The real issue is what is the cost/benefit of doing the migration?. The Biggest cost for the Exchange team is the Oppurtunity cost. Time doing the migration is time they could spend putting in new capability that their customers desire.
The Biggest cost for the SQL team in makeing it more suitable for Exchange &/or a superset of Access (so that it can easily sit on top of SQL) is also the oppurtunity to addd other features. The Access compatability feature list was in the planning for as long as I can recall. Each release some features were implimented & some were bumped in favor of other capability. Thus the gap is closing. To understand this ask yourself how excited would existing SQL Customers be if the next major SQL release was identical to what they already had except that it had all the Access like features. It would hardly motivate an enterprise to migrate their SAP system to the latest release. Thus balancing the needs of those competing parts of the market make feature planning challenging.
July 20, 2009 at 3:48 pm
I would expect part of the challenge to be permission to add features. As it currently stands the Exchange group can add and remove features from it's DB engine as it sees fit. If Exchange were migrated, new database features would have to be approved by the SQL group, and implemented by them, on their schedule. Even if the end result was 'better', I don't think one development team would want to be that dependent on another. Any other option would have to be around 'Use the SQL Server as it is' and only add features above that layer, a compromise they don't seem to want to make, and I can't say I blame them.
Dan
July 21, 2009 at 3:05 am
While SQL is a great DBMS it's not on par with oracle and that level yet (as the price reflects). Also some of the scalability problems caused by the locking mechanisms which is partly the cause of the 2000 recommended item limit in sharepoint would suggest that it would not be wise to use SQL as an exchange engine yet. As others I think it would be great to have a "real" DBMS below exchange (oracle have been doing it for more than 6 years). I think Microsoft reason is that it would require a complete redesign of SQL and exchange to get it working, not a likely feat in these troubled times.
Anders
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply