I just want to add the author of the article, i.e. Hal Berenson, is one of the key architect behind SQL Server 7.0 which is a rewrite from the legacy Sybase code. More information can be found at: http://www.microsoft.com/about/technicalrecognition/SQL-Serv...
I think it is nice, but what surprised me was that There was no notion of the impact on testing.
If I were to buy a database server for Unix, I would expect that it would have been tested on that platform (including hard-to-test things such as power failures at inconvenient times, running out of disk space, rinning out of swap, less common filesystems, etc). I guess a minimal test would eat man-years.
This was really fascinating. It just goes to show you that there is a whole lot more than just code with something like this. My gut tells me that a unix SQLServer would have been a the poor stepchild of the family if they had gone this route. That said, it would be very nice if MS made genuine, supported drivers for SQLServer on unix. I know about FreeTDS, but that just doesn't cut it for something mission critical.
> What is the negative business impact on with entire Windows platform associated with making a key member of the server product family available on nix?
I suspect this is close to the heart of the matter. Building a flagship application for a competing OS hurts Microsoft's interest as an OS vendor. Without a really compelling business reason to take on the technical hassle of porting, this danger becomes a deal-breaker.
The discussion of admin tools is somewhat interesting - SQL Server's have been abysmal until recently. Seriously, if they couldn't have ported it to unix, at least offering some decent admin tools would have been nice.
I had a recent job where a very old NT4 box with SQL Server 6.5 was still installed. Getting the data off it to a modern platform involved the following upgrade version chaining.
So, 5 conversions, as there wasn't a simple "dump to text" tool. The silly thing is that database was under 100MB in size. (we did try dumping it into Access but certain saved procedures and other stuff in the DB wouldn't come over)
Then, after all that trouble, we realized that the client program was 16-bit, so they have to do a rewrite to run on x64 platforms (or run VM's, great...). And nobody has the code as the guy who wrote it fell off the planet.
9 comments
[ 3.4 ms ] story [ 28.6 ms ] threadIf I were to buy a database server for Unix, I would expect that it would have been tested on that platform (including hard-to-test things such as power failures at inconvenient times, running out of disk space, rinning out of swap, less common filesystems, etc). I guess a minimal test would eat man-years.
I suspect this is close to the heart of the matter. Building a flagship application for a competing OS hurts Microsoft's interest as an OS vendor. Without a really compelling business reason to take on the technical hassle of porting, this danger becomes a deal-breaker.
I had a recent job where a very old NT4 box with SQL Server 6.5 was still installed. Getting the data off it to a modern platform involved the following upgrade version chaining.
6.5 -> 2000 -> 2005 32-bit -> 2005 64-bit -> 2008 R2.
So, 5 conversions, as there wasn't a simple "dump to text" tool. The silly thing is that database was under 100MB in size. (we did try dumping it into Access but certain saved procedures and other stuff in the DB wouldn't come over)
Then, after all that trouble, we realized that the client program was 16-bit, so they have to do a rewrite to run on x64 platforms (or run VM's, great...). And nobody has the code as the guy who wrote it fell off the planet.