March 25, 2011 at 8:08 am
After thinking about this, I would like to see licensing based on hardware. Many SQL Server implementations are for small low use databases but could use redundancy requirements, fault tolerance, reporting etc. Why should I be forced to spend $25000 for a license to support a 50 MB database that needs the same fault tolerance as any other business.
This is one of the reasons that I am seeing more people thinking of MySQL vs SQL Server or Oracle.
Raymond Laubert
Exceptional DBA of 2009 Finalist
MCT, MCDBA, MCITP:SQL 2005 Admin,
MCSE, OCP:10g
March 25, 2011 at 8:27 am
jasona.work (3/25/2011)
I think the biggest issue for doing this, would be for MS to write SQL to not use more than a set amount of RAM, or a set number of cores / sockets, as well as including a method to increase these numbers.
I don't see that being a problem--the Express edition is already limited to a single CPU core and 1Gb of RAM, so the code to do this already exists, albeit in the bottom-end version!
March 25, 2011 at 8:32 am
One thing I think everyone can agree upon... SSRS should be licensed separately. IIS on my SQL server?!? Ummm... no thanks.
Beyond that, I've wrestled with licensing... and I don't think a better scheme otherwise will be forthcoming. Sure... charge me for processors, not cores. Try to get the information out there so that my customers know what licenses are needed to run a SQL server and what those licenses cost. Don't change those rules often. But I certainly don't mind moving features down into lower version as time passes... and I won't even ask that the OS keep pace. (Yes... SQL 2008 Standard for clustering... but I need that on Windows 2008 Enterprise Servers.) I thought for a few minutes that an a-la-carte pricing system would be better, but reading the comments about Oracle pricing, I don't think I want to go there.
And please, please, please don't ask the developers what version should be running on the production boxes. *grumble* Giving them developer edition as an enterprise edition but without the high cost is a BRILLIANT marketing move. "Well, we wrote it with those features enabled... you'll just need to upgrade your production box to Enterprise." GAH! If any changes are made to editions, please make the developer edition such that the developer has to explicitly turn on anything not enabled in Express! I don't even mind if it's a simple configuration options "which edition of SQL would you like to emulate?" (Maybe this problem isn't as bad now... but I know a few years ago I was getting burned by this every time I turned around.)
March 25, 2011 at 8:43 am
I would like to see the differentiation done by hardware, not be feature. We're a small IT shop, but not having something like database snapshot really sucks. (We're on SQL 2005 SE.) Because we're small, our hardware is small, and adequate for our needs. I'm sure if we got bigger, the bigger box would come and we'd put out for a bigger version of SQL Server, but I really hate not having those extra features.
Kindest Regards, Rod Connect with me on LinkedIn.
March 25, 2011 at 10:29 am
We are using the Standard Version in our office because it's all my company can afford, but it really limits my ability in Reporting Services because you can't do data driven subscription and security. At some point we are going to have to develop our own solution, but it really stinks to know that it's available at the Enterprise level, and we would just be building a poor imitation of it.
If anyone has a suggested method to do this, I would greatly appreciate hearing about it.
March 25, 2011 at 10:35 am
paul.knibbs (3/25/2011)
I disagree here. Licensing per core is all well and good, but you might well end up paying to license a feature you don't want and never use! I'd rather see some sort of system where, rather than have fixed "editions" of the product, you just pay for the bits you need.
You do that now. You easily pay for Enterprise without using all the features. In fact, I don't know anyone that uses all the Enterprise features on one box.
The licensing for features, which I've thought about before, might be nice, but it would be a crazy system to administer. Plus, how would you even split things up? Are you paying for every little feature? A fee for Data compression? Another one for Partitioning? Imagine trying to go get approval for POs for this? What if you forgot something and then needed another PO? It would be a nightmare.
March 25, 2011 at 10:37 am
I'm maybe looking at this from the somewhat selfish point of view that I only have small databases to look after, and it seems I'm paying a lot of money for features I never use and am never likely to... 🙂
March 25, 2011 at 10:40 am
I agree that they should have only one edition with all the features. They could set price points and use licensing to enforce them. The difference would be to have a software based governor in there to limit the speed of certain operations like inserts per minute, reads per minute, etc on the free or cheaper versions.
Life for customers and developers alike would be so much easier if you did not have to code around missing features for smaller or poorer clients.
March 25, 2011 at 10:46 am
As FOSS databases get more features, MS will have to start looking into something like this. What they'll do, I don't know. If they follow the usual MS pattern, their first solution on it will be technically "correct", but will be incredibly stupid from a user/dev perspective, and will be marketted so as to make MS look as dumb as possible. This will be followed, perhaps (hopefully) quickly, by something that has very few actual technical differences, but which will be perceived much better, and will market much better.
That's their usual pattern these days.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
March 25, 2011 at 10:49 am
Richard Weissler (3/25/2011)
If any changes are made to editions, please make the developer edition such that the developer has to explicitly turn on anything not enabled in Express! I don't even mind if it's a simple configuration options "which edition of SQL would you like to emulate?" (Maybe this problem isn't as bad now... but I know a few years ago I was getting burned by this every time I turned around.)
As of Visual Studio 2010 it is still like this.
MSDN subscription that comes with Ultimate has the developer edition with everything turned on.
The common M$ response to flames about this terrible practice is:
"A good Software Project Manager comunicates the limitations of the produciton environment clearly to his developers at the beging of the project. If your developer does not understand how to work within the limits of your environment he must not be qualified to do the task. Testing your software project well and often should expose any issues you will have early enough to recover from them."
Or
"This makes us way too much easy money for us to consider stoping now."
March 25, 2011 at 11:03 am
bphipps-931675 (3/25/2011)
We are using the Standard Version in our office because it's all my company can afford, but it really limits my ability in Reporting Services because you can't do data driven subscription and security. At some point we are going to have to develop our own solution, but it really stinks to know that it's available at the Enterprise level, and we would just be building a poor imitation of it.If anyone has a suggested method to do this, I would greatly appreciate hearing about it.
No suggestion, but I hear, and feel, your pain, as we're experiencing the same thing.
Kindest Regards, Rod Connect with me on LinkedIn.
March 25, 2011 at 11:12 am
Coming from a government contracting environment where we manage databases and hardware for different projects that support different systems owned by the government using MS-SQL Server I have a definite bias towards Microsoft's per-processor licensing model and being able to differentiate on featureset.
One reason is that it allows us to be more competitive when bidding on projects without being concerned about the number of cores in a processor.
This is particularly advantageous considering the lag time between initial contract proposal, award, and finally ordering the hardware which is often much longer than Intel's or AMD's release cycle. There have been times when we have spec'ed systems for a proposal at a particular price and hardware featureset only to find that we can no longer acquire the specified hardware. If we have to specify that System X will have Z number of processor cores then are no longer able to get processors with that number of cores at time of purchase then it is technically a change to the contract. If I specify a dual processor server with no concern for the number of cores I can feel confident that will not be an issue. That is to say I feel confident I can always order a server with only 2 processors even though the actual processor chips available from the hardware manufacturer may have more cores than were available when I specified the system 20 months earlier.
By pricing on featureset I can "right-size" the system and price a proposal to meet the needs of the solution.
Sure, ideally all versions would have the same features.
I find Microsoft's current licensing model appropriate for my approach and has actually resulted in help to win more contracts as I can offer alternative configurations in terms of scalability and featureset. Where some of our competiors try to take a one size (Enterprise) fits all approach which then prices them out of the running.
March 25, 2011 at 12:40 pm
Steve Jones - SSC Editor (3/25/2011)
The licensing for features, which I've thought about before, might be nice, but it would be a crazy system to administer. Plus, how would you even split things up? Are you paying for every little feature? A fee for Data compression? Another one for Partitioning? Imagine trying to go get approval for POs for this? What if you forgot something and then needed another PO? It would be a nightmare.
Steve, I'm livin' your nightmare. See my post on Oracle licensing. To make it more fun, the licensing is all "soft" -- usage is recorded but not prevented. For example, the optional Diagnostic Pack (list: $5K/processor) is required to query data in some system views (any view named "DBA_HIST_%") -- an action that cannot be completely preventable. At any point, Oracorp can audit you and then charge back licensing fees plus a penalty, whether the action was intended or not.
So everyone just calm down. It could be much, much, much worse...:hehe:
Rich
March 25, 2011 at 12:48 pm
Steve,
I tend to agree with paul.knibbs. Buy the SQL Server engine on a per-processor/RAM basis then add feature modules to get the product you want. If you want log-shipping, buy the log-shipping module. If you want table partitioning buy that module. Give discounts for feature packs so one could buy the Standard feature pack and add on a single enterprise feature. Or one could buy the Enterprise feature pack if you need most of it anyway.
--
JimFive
March 25, 2011 at 2:54 pm
bphipps-931675 (3/25/2011)
We are using the Standard Version in our office because it's all my company can afford, but it really limits my ability in Reporting Services because you can't do data driven subscription and security. At some point we are going to have to develop our own solution, but it really stinks to know that it's available at the Enterprise level, and we would just be building a poor imitation of it.
At the very least they could make it obvious in the documentation that the feature is only available in EE when you look it up. It can be kind of embarrassing to say “Yeah, I should be able to set up a report subscription that fires on the last day of the FISCAL month.” Only to spend a couple of hours trying to figure out why the “New Data Driven Subscription” button won’t show up, and then having to go back and say, "How about if it runs every Friday night, that should be close enough shouldn't it?"
Just because we’re a smaller company, doesn’t mean that we won’t need the same features, and BECAUSE a company is small with an IT department to match (there’s two of us, me for SQL and my boss for everything else) there may not be the available time and people to create a reporting system from scratch. A small company might actually get more use out of a fuller feature set than a large company that can spend the time and resources to scratch build something in-house.
Viewing 15 posts - 16 through 30 (of 34 total)
You must be logged in to reply to this topic. Login to reply