The Best Ever

  • The latest version or summit is also the one that is being most scrutinized. Scrutiny can cause people to rate it higher. This is generally known as the Hawthorne effect, well known in social sciences, and something that everyone should consider when analyzing product or participant evaluations.

  • We are currently on 2011. My vote:-

    I) 2005
    ii) 2008R2

  • I'd say that SQL Server 2016 is probably what I'd consider the best, with SQL Server 2008 R2 being second best.  The problem I have with 2012, 2014, 2017 is that they mainly seem to be a bunch of noise designed to pacify people looking for the latest wiz-bang trends but doing very little to actually improve the product itself.  In my opinion SQL Server versions before 2005 couldn't even be considered enterprise worthy solutions, but it took until 2008 R2 to really polish those features.  2012 was mainly about BI.  2014 brought us the new cardinaliy estimator, which broke many old queries so it's difficult to say it's a big success.  Don't get me wrong the carinality estimator needed improving, but I'm not convinced they did this in the best way as there still seem to be a number of problems with the SQL Engine's cost based optimizer that cause it to use poor execution plans.  There hasn't been much in 2017 to really draw me in as being a significant improvement over 2016, and we're still in the middle of upgrading our systems to 2016 and I want to limit the number of different versions I need to support.

  • I have used SQL 2000 to SQL 2016.
    And my vote goes for SQL 2012.

  • 2012 was mainly about BI.

    You say that like it's a bad thing....

  • Plus you're missing the AG changes, which were a large step forward.

  • RonKyle - Tuesday, April 10, 2018 9:14 AM

    2012 was mainly about BI.

    You say that like it's a bad thing....

    It's not that BI is a bad thing, but I thought the focus of this discussion was SQL Server.  There just happens to be a number of things bundled in with the database engine that we tend to call "SQL Server"

  • Even for core SQL Server developers, the incremental improvements to ColumnStore and In-Memory table support are reason enough to upgrade.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • It is a human thing to say that each event / software release was better than the last. Especially if there is some emotion attached to it. Meaning - if you have emotional investment in the SQL community that makes it hard as a member not to say this year was the best because it would mean it wasn't as good as last year. Cognitive dissonance is why people react this way. 

    As for SQL versions - for some reason I have the most usage on 2008 R2. It will always hold a special place for me.
    As for the biggest and truly great releases - I would say 2000, 2005, and 2016 were the biggest changes.

  • Steve Jones - SSC Editor - Tuesday, April 10, 2018 9:51 AM

    Plus you're missing the AG changes, which were a large step forward.

    oh... I thought AG was just a way to add the complexity of Windows OS clustering and other extra overhead to the simplicity of database mirroring?  :hehe:

  • It's not that BI is a bad thing, but I thought the focus of this discussion was SQL Server. There just happens to be a number of things bundled in with the database engine that we tend to call "SQL Server"

    Not bundled--integrated.  The SS in both SSIS and SSAS is SQL Server. 

  • So as long SQL Server keeps adding features I can use, while maintaining the same historical level of reliability and affordability, then I'd say each new release is better than the last. Microsoft's data platform (of which SQL Server is one component) certainly stacks up to the competition better today than it did ten years ago when v2008 was released.

    Distributed data warehouse appliance version: Done
    Cloud hosted version: Done
    In-Memory and ColumnStore: Done
    Linux version: Done

    Microsoft not only rose to the challenge of the "NoSQL" movement but hijacked it by creating a better version of the competition's own open source products and now offering it all in the cloud as an Azure based service. They even stacked a SQL language on top of it. Ha!

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • RonKyle - Tuesday, April 10, 2018 11:26 AM

    Not bundled--integrated.  The SS in both SSIS and SSAS is SQL Server. 

    I think they are bundled. SSAS and SSIS and SSRS are separate services and subsystems. I can run SSAS without running the core db engine.

  • I think they are bundled. SSAS and SSIS and SSRS are separate services and subsystems. I can run SSAS without running the core db engine. 

    No doubt technically.  I was trying to put the appropriate pro-BI spin on it.

  • 1. SQL 2008 - not just because it took so many years in coming that included a massive amount of performance and programmability features, but also due to the .Net/CLR capabilities.  In short, this version was the largest upgrade of features of any upgrade.  Look at your most used features and it's likely they were introduced in this version.
    CLR Data types were introduced here (as I just mentioned - and these can be YOUR custom data types)
    Data types like "Date" and "Time" were introduced here.
    Filestreams were introduced here.
    "practical" database mirroring was introduced here (including standby servers)
    "practical" database monitoring was introduced here
    "practical" full text searching and very powerful T-SQL was introduced here.
    partion switching was introduced here.
    Spatial data was introduced here
    SQL Dependency was introduced here
    and so on and so on.

    2. SQL 7 - because it brought enterprise speed to SQL server.  Our server performance went from equivalent to Access to equivalent to Oracle for most simple projects.  No more "create TempDB in a memory RAM drive" to get speed.

Viewing 15 posts - 16 through 30 (of 33 total)

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