jwiseh (3/3/2015)
I have had jobs working with SQL Server and MySQL, so I can't really speak much to the Oracle front.To expand on sql-lover's comment, support is a huge issue. When your MySQL database on your Linux server is supplying data to your PHP website on your Apache web server, and something breaks, everyone points the finger at someone else. "The MySQL database is fine, it must be a problem with your Apache web server," etc. When you run Microsoft SQL Server on a Microsoft Windows 2008 R2 OS to supply data to your Microsoft C# / ASP.NET website on your Microsoft IIS web server, Microsoft can only point the finger at themselves, since they own all four. You'll get a lot less of "it's the other guy's fault" when you try to get support.
My experience with MySQL as opposed to T-SQL syntax is that in most cases (but not all), T-SQL has an advantage in available commands, functions, data types, etc. For example, MySQL has a INSERT...ON DUPLICATE UPDATE syntax that is similar in functionality to a T-SQL MERGE statement, but MERGE also handles DELETEs in addition to INSERTs and UPDATEs. The Windowing functions like RANK() OVER, recursive CTE's, etc. are also a little more advanced, in my opinion. MySQL has a few advantages (they came up with LIMIT before Microsoft came up with OFFSET...FETCH, for example), but I think T-SQL holds the advantage here.
Where SQL Server really shines is in the other programs outside of the DB Engine. SSIS, SSAS, and SSRS are prime examples. I've known DBA's who work in non-Microsoft shops that still will run one instance of SQL Server just to get their hands on SSIS for moving data around. It's so versatile, you don't even have to stop in SQL Server first; you can move data straight from MySQL into Oracle if you want. It's an extremely powerful tool.
Ultimately, MySQL does give great basic database functionality for less cost, but you get what you pay for.
"You'll get a lot less of "it's the other guy's fault" when you try to get support." I have had this happen to me when contacting MS. SQL Server issue, no that sounds like a Server 2008 issue. Better open a ticket for server support. It is the nature of the beast, most people want to pass the buck to somebody else regardless of MS/OSS/Apple affiliation.
You are somewhat correct about issues in a LAMP environment, but you left out a few things: There is a massive online presence that can assist with LAMP questions/issues, issues with LAMP entities are generally (from experience) easier to track down, troubleshoot and fix than in a MS environment.
That being said, no system is perfect and all systems have issues regardless of vendor/OS.
Use what is best for your customers and easiest to support.
Not to drag this into a mud slinging match, but I will disagree with the wonderfulness of tools like SSIS. Being forced to use a wysiwyg tool that also requires you to write c# code (at least in my workflow that requires heavy auditing -- really, what the point of wysiwyg if you have to constantly write code) AND suffers from cache memory issues (where you make a schema change in SQL SERVER and SSIS/SSDT, but the SSIS/SSDT program refuses to acknowledge the change and continues to use the cached schema) is in no way an optimal thing. The cache issue alone is enough for me to recommend that SSIS never be used as this can cause very bad data issues and you may never know about it unless you are auditing your data vigorously. BTW, the cache issue has been around since 2005.
Having written ETL processes for years, I find that building the SSIS package takes far longer than writing the process in PowerShell/stored procedures and has more support issues.
I would write a screed about how slow SSRS is, how bloated the report files are and how painful the report builder/bids tools are to use, but then you can compare SSRS to Crystal and realize that they both blow chunks.