Why should i go for MS-SQL server not for Oracle and MySQL ?

  • Hi ALL,

    I would like your valuable input for why should i use MS-SQL Server not oracle or MySQL ?

    what are strong advantages about MS-SQL Server compare to Oracle and MySQL ?

    I appreciate you time.

    Thank You.

  • Well on the MySQL Front, it's free and the general rule of thumb applies, every dollar you save in software costs you pay for in development time and maintenance.

    As for MS SQL vs Oracle, this is probably not the least biased forum to ask, of course neither would be an oracle forum. As far as functionality and they're both solid platforms but SQL Server will just integrate better in a windows environment compared to Oracle. And oracle licensing is more costly for debatably not many technical benefits.

  • hcip.77 (3/3/2015)


    Hi ALL,

    I would like your valuable input for why should i use MS-SQL Server not oracle or MySQL ?

    what are strong advantages about MS-SQL Server compare to Oracle and MySQL ?

    I appreciate you time.

    Thank You.

    Should I commute on a Mercedes or a Mazda? 🙂 ...

    Yours is not black or white question. It is, in my opinion, impossible to answer without knowing your application requirements, budget, experience, etc.

    I've worked a bit with MySQL, have tons of friend who are Oracle DBAs, and I'm a SQL DBA myself. But if I would like to summarize everything in one single line: support.

    Support, for Enterprise level, is key when picking a relational engine, in my opinion.

    Right now, SQL2012 and SQL2014 have little to nothing to envy to Oracle. Very robust product with lot of support.

    MySQL is nice for some websites and web apps where you need to keep stuff in memory. It has an optimized engine that allows you to put tables in memory and reads are really fast. But there are some issues too (with not experienced MySQL developers) that can make you vulnerable to SQL injection; not saying you can't get such problems in Oracle or SQL, but it's a bit harder.

    MySQL runs on Linux and Windows. SQL server runs only on Windows. Oracle can run on Windows, but if you want to maximize Oracle's potential, you should run on Unix/Linux environment.

    Oracle RAC (equivalent to MS Cluster) can write to both nodes without corruption. One node only on a given MS Cluster can write to a database, no more. If more than one happens, called split brain, the database will get corrupted.

    I've seen more mission critical databases and websites running on Oracle and less on MS SQL. But you can run "crappy" applications on Oracle too, for instance, gov. health care (Obama care) So at the end, it goes back to the same principles, hiring someone who knows the product really well and the product fills your needs.

  • Thank You Both for valuable input.

    I just asked because we have new project now both Oracle and MS-SQL server teams are trying to prove their point.

    I am 100% sure You both know that how some company works.

    so i just wanted some valuable input from outside so we can make correct decision

    Much appreciated.

  • 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.

  • It might be worth adding that Facebook runs on MySQL and PHP with in excess of 50 million transactions per second (as of a couple of years ago anyway).

  • theboyholty (3/4/2015)


    It might be worth adding that Facebook runs on MySQL and PHP with in excess of 50 million transactions per second (as of a couple of years ago anyway).

    ... and they have serious ACID problems (due massive transactions because millions of users) ... and its not actually the same MySQL you and I run, at least, not the same implementation, is a customized one, and very customized and complex by the way.

    They are trying to get out of MySQL but they can't, its not so easy, plus it will cost much more to move to Oracle or MSSQL due license requirements. MySQL is GPL.

  • Having worked with all three databases as a developer/junior DBA/leader/architect, I'll throw in my 2 cents.

    I would recommend using SQL Server only when you are stuck on a Microsoft only project.

    Having spent much of the past 6 years in the MS world with SQL Server I will say that SQL Server is a decent database that is seriously hampered by the OS that it must sit on. SQL Server is reasonably powerful and easy to use but is limited by the tools available. My bias is showing as I come from the Unix/Linux world and have trouble with the very limited options (mostly pointy/clicky stuff) available in the MS world. Again, the database itself is strong, but it is let down by the tools needed to use the database.

    MS Support can be great and can also be beyond frustrating. Must be VERY careful with any/all updates. Enterprise licensing (requiring MS server/MS database and usually requiring AD and other MS upsell products) is virtually on par with Oracle level pricing. IMHO, searching for SQL Server related problems/issues online is very frustrating as the online presence seems to be much smaller (or at least much less helpful) than what you would find for MySQL and Oracle. Can pretty much find a SQL Server DBA anywhere, but ability varies WIDELY.

    MySQL is an excellent choice. It is a very inexpensive database that will work in most applications. Excellent on the web or as a general purpose backend. Can get Enterprise support, limited support or no support. So, the database price can fit most budgets. Can run on Windows/Unix/Linux, with (in my experience) Unix/Linux being more stable/usable.

    Owned by Oracle, so you may see support price increases or upsell to Oracle database. Vast online repository of answers/experiences to virtually any question you may have. MySQL is not as full featured as either SQL Server or Oracle. Harder to find a DBA as compared to SQL Server. Again, ability can vary widely.

    Oracle can be a great choice. Enterprise Oracle is not cheap. It can be the backend for anything you can think of. It runs on Windows/Unix/Linux (IMHO, it runs better and with less issues on Unix/Linux). Oracle is the 64 pound gorilla of databases. I have used it on very large size databases, as a mission critical backend receiving thousand of 'hits'/second and on systems that required five 9's uptime and Oracle could handle it all.

    Oracle Enterprise licensing is NOT cheap. Oracle has a history or not fixing security issues, better now but the history is still there. DBA's can be difficult to find and are pricey. Oracle can be a beast to tune, but if tuned correctly is hard to beat for a extremely reliable database. Like SQL Server, it does use some proprietary tools which can/will annoy.

  • podmate (3/4/2015)My bias is showing as I come from the Unix/Linux world and have trouble with the very limited options (mostly pointy/clicky stuff) available in the MS world. Again, the database itself is strong, but it is let down by the tools needed to use the database.

    I would say I partially agree with this.

    And after using Linux for a few years(at home, not at work) I can say that I feel your pain but ... things changed after Windows2008R2. Windows2012 and SQL2012/SQL2014 can now take full advantage of PowerShell. Not all SQL DBAs know this or are using PowerShell as they should (including myself) but this certainly changes the dynamic of Windows a lot. With PowerShell you can perform most UNIX/LINUX type of tasks that you were not able to perform before. Still not as powerful and integrated as LINUX/UNIX , but a step in the right direction.

    Also, you need to remember that Windows is NOT UNIX. In other words, Windows is a GUI based Os. So the GUI will always be there. Its just that the command line interface and commands need to develop at same pace with the GUI counterpart. This is a blessing and a curse. A blessing for some managers and companies because let's face it, finding good Oracle/Linux DBAs is harder and more expensive than finding good SQL/Windows DBAs. Managing a relation engine without any graphical interface or with a limited one is way harder than using a GUI.

  • sql-lover (3/4/2015)


    podmate (3/4/2015)My bias is showing as I come from the Unix/Linux world and have trouble with the very limited options (mostly pointy/clicky stuff) available in the MS world. Again, the database itself is strong, but it is let down by the tools needed to use the database.

    I would say I partially agree with this.

    And after using Linux for a few years(at home, not at work) I can say that I feel your pain but ... things changed after Windows2008R2. Windows2012 and SQL2012/SQL2014 can now take full advantage of PowerShell. Not all SQL DBAs know this or are using PowerShell as they should (including myself) but this certainly changes the dynamic of Windows a lot. With PowerShell you can perform most UNIX/LINUX type of tasks that you were not able to perform before. Still not as powerful and integrated as LINUX/UNIX , but a step in the right direction.

    Also, you need to remember that Windows is NOT UNIX. In other words, Windows is a GUI based Os. So the GUI will always be there. Its just that the command line interface and commands need to develop at same pace with the GUI counterpart. This is a blessing and a curse. A blessing for some managers and companies because let's face it, finding good Oracle/Linux DBAs is harder and more expensive than finding good SQL/Windows DBAs. Managing a relation engine without any graphical interface or with a limited one is way harder than using a GUI.

    Can't say that I totally disagree with you.

    I have been using PowerShell for the past year (with 2008R2 and 2012) and have found it to be both powerful and impotent. It can do some things very well, but you can reach its limits fairly quickly. I have a lot of hope for PowerShell and I really want MS to continue development of it.

    I guess the biggest issue that I have with a total GUI environment is how little the coder knows/understands (in my experience) of the system/project. I have worked with too many MS only DBA's/Developers who were smart people, but just could not see the entire picture because they were so abstracted from the project/database/system.

  • While I totally understand the value of knowing what's going on behind the scenes why anyone willingly subjects themselves to a command line interface unless given absolutely no other choice is beyond me. I'll pass on working with a linux/mysql setup again.

  • 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.

  • ZZartin (3/4/2015)


    While I totally understand the value of knowing what's going on behind the scenes why anyone willingly subjects themselves to a command line interface unless given absolutely no other choice is beyond me. I'll pass on working with a linux/mysql setup again.

    'cause you look more geeky, 😀

  • theboyholty (3/4/2015)


    It might be worth adding that Facebook runs on MySQL and PHP with in excess of 50 million transactions per second (as of a couple of years ago anyway).

    But only after some ingenious help because MySQL wasn't up to it.

    https://www.facebook.com/notes/mark-callaghan/max-concurrent-connections-queries-and-transactions/10150245619365933

    Of course, the ability to modify the guts of MySQL is one of it's stronger selling points.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • podmate (3/4/2015)


    ...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.

    Which is why MS Access is my go-to tool for developing reporting systems against SQL Server. I've used, and loathed, Crystal since it was bundled with SQL Server 4.21 in the '90s. Fortunately, as far as I know, they don't have CR at my current gig.

    -----
    [font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]

Viewing 15 posts - 1 through 15 (of 20 total)

You must be logged in to reply to this topic. Login to reply