July 19, 2017 at 6:25 am
Jeff Moden - Wednesday, July 19, 2017 5:58 AMpeter.row - Wednesday, July 19, 2017 1:19 AMSteve Jones - SSC Editor - Tuesday, July 18, 2017 9:54 AMpeter.row - Tuesday, July 18, 2017 1:36 AMIf MS are going to release at this cadence then they need to start selling licensing such that it covers 2 versions, i.e. if you buy 2017 it should cover 2017 and 2018.
It can't be in MS' interests to have so many versions of SQL Server out there.
...Why? Do you think that you get less value from SS2017 if SS2018 (or likely early SS2019) is released 18 months later? The support is the same. You'll get 5 yrs of SS2017 support + 5 more of security and potential 6 more if you pay.
Is it in MS interest? I think it is. They only get x% upgrading to each version. If they release every 12-18 months, I think they get more upgrades along the way, especially as new features come along.
I do think that there is a slight support increase, but they way they've moved to a streamlined engineering process and feature flags, I think providing support for SS2016+ is easier than previous versions.
Okay I'm going to re-frame the statement - so many SQL Server versions is going to be a pain in the arse for devs.
5 years + 5 more security fixes that means at this rate by 2022 a dev using SQL Server for their product depending on customers might have to support 5 - 8 different versions of SQL Server and that doesn't even include service pack levels. That might not be a problem for MS with it billions of dollars and endless resources on its projects but for small - medium companies it's going to be painful and will end up with some painful decisions, i.e. you simply tell the customer no or you end up having to support much older versions..The issue could be for upgrades for a company that is on an older version. With yearly releases there will always be a newer version just around the corner which gives those in charge of purse strings a good excuse to put off needed upgrades continuously.
Yes I do think you'll get less value for your money. If they charge how ever many thousands they do for licensing but you are only getting a few features then depending on what you are upgrading from it's simply not worth it. However if the license covered 2 versions, you could buy with the knowledge that you can upgrade next year and get those features.
Alternatively I see maybe SQL Server going the subscription route, you pay nothing upfront just a monthly cost. You upgrade to newer versions when you choose, not when they are available, much like you do now. However unlike now older versions would get dropped quicker.
Before you say it moving to the cloud is quite clearly not the answer - especially if you use anything more than the database engine because SQL Azure doesn't support any of the other SQL Server components - SSRS, SSAS, SSIS.
In my case customers have sensitive data that they simply would not allow in the cloud end of story. That might change in 20 years and if no company offers an onsite DB system, but that's not going to happen for a long time.Amen to that... especially that last paragraph. I'll also add that forced upgrades would be horrible, as well. Ironically and with the understanding that security fixes will be missing, the cool part about a version going out of support is that it finally becomes stable with no chance of something new breaking because they've stopped messing with the code.
That's why we are using VS 2015 and ignoring the later versions. (Until they are fixed.) It's just like waiting for SP2 in the early days... 🙂
July 19, 2017 at 6:35 am
Jeff Moden - Tuesday, July 18, 2017 4:37 PMriversoft - Tuesday, July 18, 2017 8:05 AMI have been testing IN-Memory OLTP. With the release of 2017 most of the restrictions I have encountered have been addressed (Support for CASE, Unlimited Indexes on Memory Optimized Table for example).
One of the features I really like in the ability to have schema only memory tables.
There are still some features I would like to see. Subquery support for example.
The combination of Memory optimized tables and native compiled procedures and functions have shown incredible performance results.
In my opinion, disk based SQL Server will be replaced with IN-Memory for OLTP. With the changes in hardware (memory) it just make sense.
If you think about it, you should have the entire OLTP database in memory even for disk-based SQL server.I have to ask... what are you calling "incredible performance results"?
I will see if I can find the performance numbers for my tests but it was an incredible difference; especially if you are using stored procedures. As a matter of fact, I didn't believe the numbers at first. Its the difference between running interpreted code and native code. Also, with the memop tables there are no pages or extents to deal with. I'm sure someone has some better benchmarks than I. If you have a need for speed you should check it out
July 19, 2017 at 6:44 am
peter.row - Wednesday, July 19, 2017 1:19 AMBefore you say it moving to the cloud is quite clearly not the answer - especially if you use anything more than the database engine because SQL Azure doesn't support any of the other SQL Server components - SSRS, SSAS, SSIS.
Technically all those are available in Azure but I'm assuming you meant available via the SaaS model.
FYI Analysis Services is now available in the SaaS model - https://azure.microsoft.com/en-ca/services/analysis-services/
July 19, 2017 at 7:34 am
chrisn-585491 - Wednesday, July 19, 2017 6:25 AMJeff Moden - Wednesday, July 19, 2017 5:58 AMpeter.row - Wednesday, July 19, 2017 1:19 AMSteve Jones - SSC Editor - Tuesday, July 18, 2017 9:54 AMpeter.row - Tuesday, July 18, 2017 1:36 AMIf MS are going to release at this cadence then they need to start selling licensing such that it covers 2 versions, i.e. if you buy 2017 it should cover 2017 and 2018.
It can't be in MS' interests to have so many versions of SQL Server out there.
...Why? Do you think that you get less value from SS2017 if SS2018 (or likely early SS2019) is released 18 months later? The support is the same. You'll get 5 yrs of SS2017 support + 5 more of security and potential 6 more if you pay.
Is it in MS interest? I think it is. They only get x% upgrading to each version. If they release every 12-18 months, I think they get more upgrades along the way, especially as new features come along.
I do think that there is a slight support increase, but they way they've moved to a streamlined engineering process and feature flags, I think providing support for SS2016+ is easier than previous versions.
Okay I'm going to re-frame the statement - so many SQL Server versions is going to be a pain in the arse for devs.
5 years + 5 more security fixes that means at this rate by 2022 a dev using SQL Server for their product depending on customers might have to support 5 - 8 different versions of SQL Server and that doesn't even include service pack levels. That might not be a problem for MS with it billions of dollars and endless resources on its projects but for small - medium companies it's going to be painful and will end up with some painful decisions, i.e. you simply tell the customer no or you end up having to support much older versions..The issue could be for upgrades for a company that is on an older version. With yearly releases there will always be a newer version just around the corner which gives those in charge of purse strings a good excuse to put off needed upgrades continuously.
Yes I do think you'll get less value for your money. If they charge how ever many thousands they do for licensing but you are only getting a few features then depending on what you are upgrading from it's simply not worth it. However if the license covered 2 versions, you could buy with the knowledge that you can upgrade next year and get those features.
Alternatively I see maybe SQL Server going the subscription route, you pay nothing upfront just a monthly cost. You upgrade to newer versions when you choose, not when they are available, much like you do now. However unlike now older versions would get dropped quicker.
Before you say it moving to the cloud is quite clearly not the answer - especially if you use anything more than the database engine because SQL Azure doesn't support any of the other SQL Server components - SSRS, SSAS, SSIS.
In my case customers have sensitive data that they simply would not allow in the cloud end of story. That might change in 20 years and if no company offers an onsite DB system, but that's not going to happen for a long time.Amen to that... especially that last paragraph. I'll also add that forced upgrades would be horrible, as well. Ironically and with the understanding that security fixes will be missing, the cool part about a version going out of support is that it finally becomes stable with no chance of something new breaking because they've stopped messing with the code.
That's why we are using VS 2015 and ignoring the later versions. (Until they are fixed.) It's just like waiting for SP2 in the early days... 🙂
We'll be updating our project to VS 2017 soon, we want the new C#7.x features and some of the features.
July 19, 2017 at 7:38 am
FridayNightGiant - Wednesday, July 19, 2017 6:44 AMpeter.row - Wednesday, July 19, 2017 1:19 AMBefore you say it moving to the cloud is quite clearly not the answer - especially if you use anything more than the database engine because SQL Azure doesn't support any of the other SQL Server components - SSRS, SSAS, SSIS.Technically all those are available in Azure but I'm assuming you meant available via the SaaS model.
FYI Analysis Services is now available in the SaaS model - https://azure.microsoft.com/en-ca/services/analysis-services/
Yes - SaaS - obviously if you use an Azure VM then it's no real difference.
Specifically we need to use SSRS which is already a complete bitch to configure and integrate with your software due to the need for writing a custom security DLL and then get SSRS to use the damn thing.
July 19, 2017 at 7:42 am
riversoft - Wednesday, July 19, 2017 6:35 AMJeff Moden - Tuesday, July 18, 2017 4:37 PMriversoft - Tuesday, July 18, 2017 8:05 AMI have been testing IN-Memory OLTP. With the release of 2017 most of the restrictions I have encountered have been addressed (Support for CASE, Unlimited Indexes on Memory Optimized Table for example).
One of the features I really like in the ability to have schema only memory tables.
There are still some features I would like to see. Subquery support for example.
The combination of Memory optimized tables and native compiled procedures and functions have shown incredible performance results.
In my opinion, disk based SQL Server will be replaced with IN-Memory for OLTP. With the changes in hardware (memory) it just make sense.
If you think about it, you should have the entire OLTP database in memory even for disk-based SQL server.I have to ask... what are you calling "incredible performance results"?
I will see if I can find the performance numbers for my tests but it was an incredible difference; especially if you are using stored procedures. As a matter of fact, I didn't believe the numbers at first. Its the difference between running interpreted code and native code. Also, with the memop tables there are no pages or extents to deal with. I'm sure someone has some better benchmarks than I. If you have a need for speed you should check it out
The latest SQL Server Central email has a link to a free ebook SQL Server Internals: In-Memory OLTP this has an outstanding information related to In-Memory OLTP. There is a section showing some basic performance statistics.
July 20, 2017 at 12:06 am
riversoft - Wednesday, July 19, 2017 7:42 AMThe latest SQL Server Central email has a link to a free ebook SQL Server Internals: In-Memory OLTP this has an outstanding information related to In-Memory OLTP. There is a section showing some basic performance statistics.
This book is wonderfully detailed and helped me greatly when I did my first In-Memory OLTP project. I have it on my bookshelf behind me.
However, it is for SQL Server 2014 and much of what was not possible is now possible in SQL Server 2016. I am hoping that Redgate can convince Kalen Delaney to write an updated version.
Viewing 7 posts - 31 through 36 (of 36 total)
You must be logged in to reply to this topic. Login to reply