September 26, 2014 at 1:50 pm
I'm trying to think of the features that weren't in SQL2000 that I actually used in the later versions.
1. Partitioning
2. Mirroring
3. SQLCLR (very limited)
4. Some language extensions but not many
5. Schemas
SSIS is still a product I have a love/hate relationship with. I just loved DTS.
Haven't uses SSRS or SSAS
The rest are feature improvements from a usability perspective.
What would I be interested in?
1. New engines accessible using SQL or closely related abstraction language. Engines being Graph and Document based.
2. Distributed SQL capable of being deployed in the cloud as per Apache Spark and SparkSQL
3. Improved tooling including cross DB support.
4. Powershell and SMO enhanced
Licencing designed for people who don't have a law degree and who have very little time read oceans of waffle.
Licencing written by someone who genuinely wants a fair and equitable solution for all concerned.
MySQL 5.6 is notably better than the earlier 5.x releases so is a reasonable alternative for most RDBMS use cases. In the hands of a competent DBA I'd say it isn't too far off SQL2000 or even SQL2005 standard.
SQL Server is to server software what Office/Excel are to desktop software. What's left to add?
September 26, 2014 at 1:58 pm
David.Poole (9/26/2014)
I'm trying to think of the features that weren't in SQL2000 that I actually used in the later versions.1. Partitioning
2. Mirroring
3. SQLCLR (very limited)
4. Some language extensions but not many
5. Schemas
SSIS is still a product I have a love/hate relationship with. I just loved DTS.
Haven't uses SSRS or SSAS
The rest are feature improvements from a usability perspective.
What would I be interested in?
1. New engines accessible using SQL or closely related abstraction language. Engines being Graph and Document based.
2. Distributed SQL capable of being deployed in the cloud as per Apache Spark and SparkSQL
3. Improved tooling including cross DB support.
4. Powershell and SMO enhanced
Licencing designed for people who don't have a law degree and who have very little time read oceans of waffle.
Licencing written by someone who genuinely wants a fair and equitable solution for all concerned.
MySQL 5.6 is notably better than the earlier 5.x releases so is a reasonable alternative for most RDBMS use cases. In the hands of a competent DBA I'd say it isn't too far off SQL2000 or even SQL2005 standard.
SQL Server is to server software what Office/Excel are to desktop software. What's left to add?
New features I love that have been introduced since SQL2000
64 bit technology to easily allow SQL Server to use more than 2 gig of memory
Schemas
Native DB Backup compression
Better Activity Monitor
Service Pack/CU applies much easier as it now will stop then start SQL Server in single user mode to apply the patches to SQL Server.
Clustering has GREATLY improved in each release
Better use/efficiencies of use of TEMPDB
Allowing Rebuild indexes IN TEMPDB instead of bloating the mdf file of the user database
September 28, 2014 at 11:22 am
SQL Server is growing contiuously for two years, again and again. Shortly before it reaches the "mature status" it drops back with a new version.
Then it starts all over again: numerous hot fixes followed by CU's at a rather high frequency, sooner or later followed by SP1.
Based from previous experience there'S a large portion of the community waiting for SP1 before they even consider using the new version in production.
For a good reason, from my perspective at least...
Until version 2008 MS had a mainstream support of up to 7.5 years (SQL2000 Standard from Nov 2000 to April 2008).
The "lower end" is held by SQL2008R2 with as low as 4 years (July 2010 to July 2014).
MS (intentionally?) cut the mainstream support by 2 years just by choosing a different name for the product (instead of SQL2010), ending both, SQL2008 and SQL2008R2, in 2014. Now it looks like MS goes toward a 5yr mainstream support with a new release every other year.
From my point of view the release cycle is way too short, as is the mainstream support cycle. This is mainly driven by the two facts that the new versions only support the previous two versions and that the previous versions are no longer avaiable from MS directly as soon as they release the new version. They should at least offer all products currently supported (= within mainstream support) or expand the mainstream support cycle significantly.
MS simply pushes the (partially significant) effort to maintain a wide range of versions to the end users and at the same time flooding the market with new version at ever increasing cost.
I've been an advocat for SQL Server since more than a decade. But starting with SQL 2012 I don't have the arguments any more how to justify the enormeous price increase. The only "argument" (Oracle is even more expensive) becomes less and less relevant.
Where's the discount for unwanted add-ons (like SSAS, for instance)? Why do I have to pay for the huge bundle if all I need is a high performing database engine? Why do I have to pay for SSRS improvements, if I'm happy with the SSRS version I currently have (which even is capable of importing Report Builder models - an option that seems to be lacking in the 2014 version...)? So I have to pay more just to get less?
MS licencing strategy pushes SQL Server's status from "mature" back to "childhood". If I'm using several SQL Server instances and I'm unable to verify that I'm still properly licenced without an MS rep doing that for me (usually still resulting in an "opinion" instead of a "bullet-proof" statement together with the recommendation to go with a core based licenced, "just to be on the safe side"), I'm loosing all the trust I have in such a company (MS).
MS puts theirself in a position to start a lawsuit against a customer at their own will without a chance that a customer can calculate the licences required without MS getting involved. If that is the strategy MS wants to treat their customers, then they deserve to loose market shares and become a niche product.
I think, the direction M$ has chosen will scare away more and more customers...
September 29, 2014 at 7:11 am
The cost of upgrading is way out of line for what it provides. I don't believe including bug fixes as a reason to upgrade is valid if I have to pay for that upgrade. They sold it to us with those bugs.
September 29, 2014 at 6:19 pm
I don't think I would call SQL Server mature. SQL Server 2000 lasted long enough to become mature. Maybe SQL 2005 did, I didn't have enough contact with it to find out. SQL Server 2008 didn't, SQL 2008R2 even less so - by the time SQL 2008 R2 was becoming mature it was no longer possible to buy it. SQL 2012 and SQL 2014 are still too new and have too many bugs/inconsistencies/irritating quirks - many of them with Connect items that have been closed "won't fix". There is no attempt at all to bring the behaviour of the data engine into line with the apparently clear semantics of T-SQL - there is a connect item still open, MS promised action years ago, nothing is happening - apparently because there is a lot of careless optimisation that prevents the engine from doing what the T-SQL clearly tells it to do and that is too hard to unravel.
And as someone else said, the licensing is a nightmare - incomprehensible documentation, no-one willing to clarify it in any attributable manner. Being a nightmare is surely a sign of immaturity? Being incomprehensible and refusing to clarify certainly is.
Tom
October 2, 2014 at 3:36 pm
TomThomson (9/29/2014)
I don't think I would call SQL Server mature. SQL Server 2000 lasted long enough to become mature. Maybe SQL 2005 did, I didn't have enough contact with it to find out. SQL Server 2008 didn't, SQL 2008R2 even less so - by the time SQL 2008 R2 was becoming mature it was no longer possible to buy it. SQL 2012 and SQL 2014 are still too new and have too many bugs/inconsistencies/irritating quirks - many of them with Connect items that have been closed "won't fix". There is no attempt at all to bring the behaviour of the data engine into line with the apparently clear semantics of T-SQL - there is a connect item still open, MS promised action years ago, nothing is happening - apparently because there is a lot of careless optimisation that prevents the engine from doing what the T-SQL clearly tells it to do and that is too hard to unravel.And as someone else said, the licensing is a nightmare - incomprehensible documentation, no-one willing to clarify it in any attributable manner. Being a nightmare is surely a sign of immaturity? Being incomprehensible and refusing to clarify certainly is.
The one thing I'd say, Tom, is that the core of SQL 2012/2014 is very mature. The bugs are mostly in changed areas. The things that are quirky, or you may not like, are mostly the same things that exist in 2005/2008/R2. They haven't been improved, but they work as expected, though not as designed.
As a core RDBMS, I still think SQL Server is mature. There are less things in 2014 that make it substantially better than 2005. A few, but not many, and it's not really a big change from 2012 for the requirements of many applications.
August 3, 2018 at 4:57 am
I'm currently in the middle of a migration for 2005 to 2017 and the difference in what can be achieved in a shorter timescale is night and day. Not having to fiddle around with XML path to concatenate strings, having direct JSON support, a plethora of Window functions... so many of these have already made it into chunks of our TSQL code base because they just unlock a lot of potential that would otherwise require lots of laborious development to accomplish. Even things like Query Store are a massive boon to getting the job done.
That said, I'd vastly be in favor of a licensing model based on scale rather than features. It's like they gone half way there with the changes since 2016 SP1 but removing some of the other irritating limitations would seem like a more logical approach to me.
August 3, 2018 at 6:46 am
"More and more I think that key to continued adoption and growth of SQL Server is licensing by scale, not edition, and not by feature. Just like Azure, let me pay for the cores and RAM I need, and let me easily grow that as needed"
That licensing model makes sense for SQL Azure - but I think the licensing by core model for stand-alone editions for is hard for MS, or any software vendor to justify. If the software development costs can be recovered by the returns for the basic license fees, then why charge someone more if they use more hardware resources?
There may be competitive economic reasons for licensing by core, perhaps it allows them to charge less per edition, but a licensing structure that penalizes customers simply because they use more resources to run it, could be seen as being unethical. Maybe I 'm missing something, but using that reasoning, couldn't they also consider charging customers more based on their gross revenue, or profit margin?
MattF
August 3, 2018 at 8:35 am
... If things are working, it becomes hard to justify an upgrade. In fact, I had aclient that was running a SQL Server v6.5 instance in 2005, a full ten years after that version was released. Why? Mostly because the database backed a card key system that worked...
It's true that the arguments for upgrading a SQL Server instance on an embedded and / or ISV application are less compelling.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 3, 2018 at 9:03 am
I'm also a big believer in 'if it ain't broke, don't fix it', but it seems security issues make everything a bit of a moving target necessitating a lot of scrambling.
I'm kind of overstating the problem, perhaps, but definitely feel more urgency around not letting moss grow on things these days. Maybe 'the cloud' (don't hit me) addresses this somewhat. People talk about purposefully tearing down and building up systems from nothing periodically which is possible with the whole 'infrastructure as code' business. Not so easy to take this route with monster databases, but in that case if you're running on a reasonably solid platform being managed by the provider that works out.
Another force acting against 'if it ain't broke, don't fix it' is that if you work with SQL Server they typically put at least one or two things you're just dying to have for at least some of your systems in every new version.
August 3, 2018 at 10:11 am
SQL Server is a good product. However as with most other Microsoft products, Microsoft is generating revenue from making versions "unsupported" which then forces people to upgrade otherwise they fail audits etc. They are not upgrading because MS has produced revolutionary new features but because some ISO standards person has decided that once a vendor makes a product unsupported, everyone who wants to retain accreditation has to upgrade whether they like it or not. Then the vendor is like , "Ker-ching!"😀 - thanks standards body!
I don't like that thousands of man hours around the world are/were spent rewriting DTS packages in SSIS because "DTS isn't supported any more", rather than because it provides a business benefit. I like SSIS though and obviously write any new ETL with it. SSRS was a good addition. However a lot of new features are very niche or come with so many caveats (like in-memory tables) they are useless to most people.
Apart from that SQL Server is mature.
August 4, 2018 at 12:02 pm
99zardoz - Friday, August 3, 2018 10:11 AMI don't like that thousands of man hours around the world are/were spent rewriting DTS packages in SSIS because "DTS isn't supported any more"...
Precisely why I don't use add-ons that fall into the "4 letter word" category of SQL Server.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 12 posts - 31 through 41 (of 41 total)
You must be logged in to reply to this topic. Login to reply