| I too am biased towards PG. At one of my previous gigs, I had to develop a HTML5 mobile app around a MS SQL database (though eventually we migrated to PostgreSQL). Among the problems we ran into: A) Indexes disappeared without rhyme or reason. (This might have been a "too many cooks in the kitchen" thing, where someone restored from a backup and didn't tell anyone.) B) In the default configuration provided by the php5-mssql package in Ubuntu, text fields were chopped at 255 characters. C) Our Windows Server did updates, then came back up with a "you need to renew your license" lock that prevented any I/O and cost us half a day of productivity (on top of the licensing costs). And of course, D) it screwed up the file encoding when we did the final export during the "migrate to PostgreSQL" step. Incidentally, migrating our platform to PostgreSQL and kicking the tires was one of the last projects I completed at that job, and everyone was much happier for it. |
Now, you say that you possibly had too many cooks in the kitchen. So perhaps your complaints are due to the other cooks, or maybe some of your complaints came to you second-hand. But here is my analysis of your complaints, having run SQL Server for a number of years:
A) Just doesn't happen. Index-related statements are transactional and ACID-compliant. (i.e.: you can, in a transaction, add, drop, and update triggers, indexes, entire tables, etc. along with data.) This has been the case since at least I've started using SQL Server with the 2005 release.
B) I don't know why this is the case with php5-mssql, but I would blame the authors of the package. varchar, nvarchar, text, etc fields all support > 255 characters.
C) I don't know of any version of SQL Server or Windows Server that does this. No Windows Server version "locks IO" on a license check failure (this would obviously cause huge problems with filesystem consistency). As far as I know, no SQL Server version does live license checking or phones home. I have no idea what your symptom was, but I suspect someone else broke something. A running SQL Server installation does not "stop", nor does it need the license to be renewed at any point. Cumulative and service pack updates don't do license checks either, as far as I know. In fact, an expired license doesn't affect anything, and probably even reflects a misunderstanding of how licensing works. If you purchased a license, even if you paid yearly for 2-3 years, your SQL Server license is good forever. Forever! New versions require software assurance, but you have to choose to install those manually, it's opt-in, not opt-out. Automatic updates should never break SQL Server.
D) Is it at all possible this was the migrate to PostgreSQL tool's fault? Because I've run weekly backups and restores of SQL Server databases for the past several versions for many years, and had no problem with a .bak file being corrupt.