April 13, 2014 at 10:27 pm
Comments posted to this topic are about the item SQL Server 2014 Key Features and Enhancements
April 14, 2014 at 5:00 am
In my personal view it looks like Microsoft trying hard to kill SQL Server.
Nearly 100% of the added features in recent releases are available in enterprise editions only, and 2014 is no exception. Sometimes features are in barely usable form, just to be a checker on a box or website. Many SQL and modeling features that are important outside large enterprises are restricted and thus not available to the majority of the user base. This combined with the increasingly complex and costly licencing hinders adoption of these new features. Odds are that people with many years of SQL Server experience are unable to practice anything that has been released in the last 5 years. This is not a good position to be in, let alone culture fanatically as Microsoft does.
Where I work we skipped the 2008 R2 and 2012 versions. What they now offer in the 2014 standard edition is simply not valuable enough to upgrade. Are the design problems they introduced in 2005 and 2008 resolved in 2014? I have read nothing about it and can only assume they have not been. They keep introducing sparsely accessible features, which sometimes are just half implementations and/or incompatible with existing features.
Microsoft and even some of its users typically forget that SQL Server is a foundation/enabling product that other software solutions are build upon. This means internal incompatibility issues, silly limitations and exclusion of useful functionality in lower tiered licences are costly to deal with in these depending products. No-one in their right mind is going to make software that relies on any of the features that customer systems might not support. Or invest in development of libraries that leverage such features in one project when the next project might need to run on the lesser tiered version the customer has. This reduces typical use of the database to the 2000 level (bunch of tables, views, some basic indexes and procedures). If you are lucky you find use of some features originating from 2005. Most people i meet trough work are at this 2000 usage level!
In my view Microsoft wasted almost 14 years, and they do not even realize it. That is how bad they manage one of their core products!
April 14, 2014 at 5:30 am
"Since the processing happens in in-memory only, if there is any sudden growth in the Hekaton tables, we can cache less of your other tables."
Does this mean with SQL Server 2014 you MUST use the in-memory option? I think this is insane as most of our servers don't have enough RAM to support such a thing. Even SSAS Tabular mode has an option where you can set your project to DirectQuery mode. Please don't tell me that the OLTP doesn't have this option.
Nonetheless I find the removal of the column index limitations a good thing since they were a pain with SQL Server 2012.
April 14, 2014 at 5:32 am
worth a mention (for DBAs anyway) is that backup encryption is available in 2014
---------------------------------------------------------------------
April 14, 2014 at 6:08 am
I am with you all the way on this one.
I have been saying this for years, even though I have rearly been affected by this myself. most of my work did not and still does not require the uses of any higher functionality of the sql server.
but some times a customer would ask if it is possible to do this or that,
and I have to say "well yeah it is possible but cost prohibitive in your case."
things like high availabiltiy is not only important for an enterprise class entity. there are some SBS that can and need the benefits but could not affrod the cost.
Hell, I personally know several DBAs (one is my friend and the other person I know through the mutual firend) whos company made a desicion to go with MySql instead of MSSQL simply because they could setup a high avaiabilty claster with it (even though it is not that easy)
for a lot less. and I mean a LOT less, since cost was a factor.
April 14, 2014 at 7:48 am
Vlad-207446 (4/14/2014)
........Hell, I personally know several DBAs (one is my friend and the other person I know through the mutual firend) whos company made a desicion to go with MySql instead of MSSQL simply because they could setup a high avaiabilty claster with it (even though it is not that easy)
for a lot less. and I mean a LOT less, since cost was a factor.
Its the total cost of ownership that needs to be viewed, including changes, development, DR/BCP, security .....
If you have a dumb database that the app only treats to hold records and there isnt any scaling issues then fine. Mysql, postgress etc are perfectly valid. But do remember a poor database design is still poor no matter which platform its on.
April 14, 2014 at 7:22 pm
Yet Another DBA (4/14/2014)
Vlad-207446 (4/14/2014)
........Hell, I personally know several DBAs (one is my friend and the other person I know through the mutual firend) whos company made a desicion to go with MySql instead of MSSQL simply because they could setup a high avaiabilty claster with it (even though it is not that easy)
for a lot less. and I mean a LOT less, since cost was a factor.
Its the total cost of ownership that needs to be viewed, including changes, development, DR/BCP, security .....
If you have a dumb database that the app only treats to hold records and there isnt any scaling issues then fine. Mysql, postgress etc are perfectly valid. But do remember a poor database design is still poor no matter which platform its on.
Is the cost of development, changes, DR and security with Postgresql expected to be much higher than SQL Server?
April 15, 2014 at 2:30 am
stolbovoy (4/14/2014)
Yet Another DBA (4/14/2014)
Vlad-207446 (4/14/2014)
........Hell, I personally know several DBAs (one is my friend and the other person I know through the mutual firend) whos company made a desicion to go with MySql instead of MSSQL simply because they could setup a high avaiabilty claster with it (even though it is not that easy)
for a lot less. and I mean a LOT less, since cost was a factor.
Its the total cost of ownership that needs to be viewed, including changes, development, DR/BCP, security .....
If you have a dumb database that the app only treats to hold records and there isnt any scaling issues then fine. Mysql, postgress etc are perfectly valid. But do remember a poor database design is still poor no matter which platform its on.
Is the cost of development, changes, DR and security with Postgresql expected to be much higher than SQL Server?
It depends!
If you know how to consistently write queries using some extensions which results in clearer code, less lines of code, and performs better on one platform than the other the other then the TCO reduces.
MS SQLServer is secure and does add a lot of extra security out of the box. I dont believe that postgress/mysql has TDE capability. To implement is 5 minutes, yet to add code to an app to do the same and still perform would take how long? And how long would it take to retrofit to an existing app?
I was going to say DR is easy with MS SQL. But looking at the various comments on this forum I would say some people find it hard, let a lone bolting on their own custom or using an rare feature of a bolt on for MySQL.
At the end of the day, the decision is not always a technical decision but a biased one
April 15, 2014 at 9:44 am
The added features are nice. However, most of these features are ENTERPRISE Edition only. Most of all of the installations in the world are Standard Edition and I would venture to say half of those are mostly smaller systems. So what little type new changes would the smaller footprint system see is my question? Why should those type systems upgrade except for being the latest and greatest version.
If backup encryption is there that is a very good reason.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply