No flying cars, no SQL back-end
Comedian/Actor Lewis Black hit the nail on the head in one of his earlier bits when he recalled all the futurists of the past (try bending your head around that one) who gave him a false view of the 21st century. He waxes poetic about how dinner is not in pill form yet, he has no jetpack, and worst of all, in his now-immortal comparison between the 20th and 21st centuries, “No flying cars, no flying cars!”
Many Exchange Engineers are beginning to feel the same way about if we’re ever going to see a Microsoft SQL back-end for Exchange Server. Since the first rumblings of the Titanium Project – which eventually became Exchange Server 2003 – we have been salivating at the chance to have a true industry-standard formatted database on the back end of the Exchange system. It would open up new architecture possibilities, allow for more scalability and allow for more 3rd party integration.
However, the release of 2003 came and went with the ESE database still in place. So, we took it in stride and moved forward, living on the promise that in the next version we would see a SQL back-end, our very own flying car paradigm.
Then, early betas of Exchange 12 came out. Lo and behold, no SQL database. The EDB was still there, though they did finally get rid of the STM. Various reasons for this have made the round of the net, blogs, newsgroups, RSS feeds, etc. The two prevailing theories are that it just couldn’t be done with the architecture still structured the way Exchange needs, and that using a SQL back end could compromise security of the overall Exchange platform. Both very legitimate reasons to hold off, but it had been 4 years since the release of 2003, and Exchange 2007 changed the game so much that a new database structure wouldn’t have been shunned. As for security, a real concern, but one that probably could have been overcome with proper configuration and coding.
So, we have Exchange 2007 – an incredible product that changes the game when it comes to enterprise messaging and collaboration. But we still have no SQL database back-end.
Then and now, to paraphrase Mr. Black, “No SQL back end, no SQL back end!”
Many Exchange Engineers are beginning to feel the same way about if we’re ever going to see a Microsoft SQL back-end for Exchange Server. Since the first rumblings of the Titanium Project – which eventually became Exchange Server 2003 – we have been salivating at the chance to have a true industry-standard formatted database on the back end of the Exchange system. It would open up new architecture possibilities, allow for more scalability and allow for more 3rd party integration.
However, the release of 2003 came and went with the ESE database still in place. So, we took it in stride and moved forward, living on the promise that in the next version we would see a SQL back-end, our very own flying car paradigm.
Then, early betas of Exchange 12 came out. Lo and behold, no SQL database. The EDB was still there, though they did finally get rid of the STM. Various reasons for this have made the round of the net, blogs, newsgroups, RSS feeds, etc. The two prevailing theories are that it just couldn’t be done with the architecture still structured the way Exchange needs, and that using a SQL back end could compromise security of the overall Exchange platform. Both very legitimate reasons to hold off, but it had been 4 years since the release of 2003, and Exchange 2007 changed the game so much that a new database structure wouldn’t have been shunned. As for security, a real concern, but one that probably could have been overcome with proper configuration and coding.
So, we have Exchange 2007 – an incredible product that changes the game when it comes to enterprise messaging and collaboration. But we still have no SQL database back-end.
Then and now, to paraphrase Mr. Black, “No SQL back end, no SQL back end!”
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home