January 21, 2016 at 7:14 am
Sean Redmond (1/21/2016)
To be fair to PostgresSQL, it is a nice DB to work with. I haven't used it in a while though.
The PostgresSQL licencing model is nice as well, you can use the standard free version, and either support it yourself or pay someone to support it. Then there is the option to buy an Enterprise level licence with Enterprise level support if you need it.
I have used SQL Server Express Edition in the past for production databases, so there is a licencing saving at the cost of maybe more personnel, adding an Admin database with procedures for running the backups and other maintenance jobs and then calling them using OSQL/SQLCmd from the Windows Scheduler is hardly more effort than setting them up in SQL Server Agent. If the amount of data stored is not going to exceed the limits of this system you can manage a handful of SQLEE instances. When you need to scale up there are options from Standard all the way up to APS or Azure data Warehouse. I would prefer 1 licence = 1 physical/virtual machine like we had with SQL Server 7.
January 21, 2016 at 7:37 am
Maybe not perfect from MSs prospective but how about the core DBMS is free. They sell enterprise features on top of it. I'd imagine some/a lot of the logic required to make partitioning work is also what allows hot standby for example. So sell a redundancy/scaling product. Also tooling, sell VS for T-SQL scripting/source control/PM work.
If startups keep using free DBMSs while they scale up their companies, guess what? They have a codebase and a developer pool that all know the flavor of syntax and how to setup instances of whatever product they are using. They'll try to find a way to scale that up when they get big to avoid switching to SQL Server. Giving away "Standard Edition" and when companies scale up hope that the problem is reversed. They know and have coded against the MS stack so they'll drop the 30k a server for SQL rather than drop a bunch more on staff and delays migrating.
January 21, 2016 at 7:42 am
I wouldn't mind seeing more granularity in pricing based on features there's some features in even standard edition I'll never use and some features in EE I'd like to have but can't get without also paying for a bunch of things I won't use.
Unfortunately MS has little motivation to worry about their pricing structure right now as it's already better and cheaper than Oracle's....
January 21, 2016 at 8:10 am
How about a licensing model that simply charges for and caps the number of concurrent connections or non-system session SPIDs without concern for number of cores, distinct users (CAL), or I/O metering? You could upgrade (or downgrade) the number session cap as your usage patterns change.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 21, 2016 at 8:39 am
Eric M Russell (1/21/2016)
How about a licensing model that simply charges for and caps the number of concurrent connections or non-system session SPIDs without concern for number of cores, distinct users (CAL), or I/O metering? You could upgrade (or downgrade) the number session cap as your usage patterns change.
While not a bad idea, it would require that tools like SSMS be re-written to either pool all of their connections, or have all of the panels and panes which have their own connection off by default with users informed that they were opening another connection, which will count towards the total allowed.
January 21, 2016 at 8:49 am
Alex Gay (1/21/2016)
Eric M Russell (1/21/2016)
How about a licensing model that simply charges for and caps the number of concurrent connections or non-system session SPIDs without concern for number of cores, distinct users (CAL), or I/O metering? You could upgrade (or downgrade) the number session cap as your usage patterns change.While not a bad idea, it would require that tools like SSMS be re-written to either pool all of their connections, or have all of the panels and panes which have their own connection off by default with users informed that they were opening another connection, which will count towards the total allowed.
What I'm suggesting is that SQL Server itself would count and functionally cap the number of sessions, and the customer would need plan ahead, providing some padding to accomodate connections from things like DBA SSMS sessions, scheduled jobs, and monitoring tools. Also, there could be a license intended for a development and QA environment, where more ad-hoc connections are expected, having a lower per session liscensing cost. More application and ad-hoc connections implies a larger IT organization and thus would justify a proportionally higher licensing cost.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 21, 2016 at 8:59 am
Eric M Russell (1/21/2016)
Alex Gay (1/21/2016)
Eric M Russell (1/21/2016)
How about a licensing model that simply charges for and caps the number of concurrent connections or non-system session SPIDs without concern for number of cores, distinct users (CAL), or I/O metering? You could upgrade (or downgrade) the number session cap as your usage patterns change.While not a bad idea, it would require that tools like SSMS be re-written to either pool all of their connections, or have all of the panels and panes which have their own connection off by default with users informed that they were opening another connection, which will count towards the total allowed.
What I'm suggesting is that SQL Server itself would count and functionally cap the number of sessions, and the customer would need plan ahead, providing some padding to accomodate connections from things like DBA SSMS sessions, scheduled jobs, and monitoring tools. Also, there could be a license intended for a development and QA environment, where more ad-hoc connections are expected, having a lower per session liscensing cost. More application and ad-hoc connections implies a larger IT organization and thus would justify a proportionally higher licensing cost.
I'm guessing microsoft wouldn't like this solution because a lot of application will happily use 1 connection for multiple users so the number of SPIDs doesn't accurately reflect number of users or usage.
January 21, 2016 at 9:35 am
ZZartin (1/21/2016)
Eric M Russell (1/21/2016)
Alex Gay (1/21/2016)
Eric M Russell (1/21/2016)
How about a licensing model that simply charges for and caps the number of concurrent connections or non-system session SPIDs without concern for number of cores, distinct users (CAL), or I/O metering? You could upgrade (or downgrade) the number session cap as your usage patterns change.While not a bad idea, it would require that tools like SSMS be re-written to either pool all of their connections, or have all of the panels and panes which have their own connection off by default with users informed that they were opening another connection, which will count towards the total allowed.
What I'm suggesting is that SQL Server itself would count and functionally cap the number of sessions, and the customer would need plan ahead, providing some padding to accomodate connections from things like DBA SSMS sessions, scheduled jobs, and monitoring tools. Also, there could be a license intended for a development and QA environment, where more ad-hoc connections are expected, having a lower per session liscensing cost. More application and ad-hoc connections implies a larger IT organization and thus would justify a proportionally higher licensing cost.
I'm guessing microsoft wouldn't like this solution because a lot of application will happily use 1 connection for multiple users so the number of SPIDs doesn't accurately reflect number of users or usage.
With connection pooling, the number of SPIDs won't measure the total number of "users" or "seats", but counting concurrent SPIDs can be used to cap usage.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 21, 2016 at 9:48 am
kingsland71 (1/21/2016)
farid.abdi (1/21/2016)
Being charged per core is a rip-off due to the decrease in performance as each successive core is utilized.For instance utilizing all 8 cores on an 8 core processor is negligibly faster than only utilizing 6 cores. Hence the license paid on the last two cores is a waste of money.
In this case you set the processor affinity to only use 6 cores, as then only buy 6 x core licenses. ...
I think you're completely wrong on this one. I built a very beefy server with lots of RAM with the intent of buying one CPU with 4 cores and hyperthreading, the guy who wrote up the purchase order saw that a second CPU was only another $400 and bought it. I spoke directly with Microsoft and they said that it was the number of cores present, regardless of how you have the affinity mask set.
That may have changed as that was 6ish years ago, but it is my understanding that it is still the rule.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
January 21, 2016 at 9:53 am
Eric M Russell (1/21/2016)
... With connection pooling, the number of SPIDs won't measure the total number of "users" or "seats", but counting concurrent SPIDs can be used to cap usage.
I haven't studied the licensing documents in a year or so, but MS was very explicit that you couldn't use that stunt to avoid licensing charges. My previous employer had an ERP system (that cannot be sufficiently cursed) that used an application server (and did everything through RBAR with zero stored procedures) that had a single connection going to SQL Server, even though there were 200+ people using it.
They were using Enterprise edition, so they were fine. Much better off than if they were using the D-7 edition. :hehe:
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
January 21, 2016 at 10:16 am
Wayne West (1/21/2016)
Eric M Russell (1/21/2016)
... With connection pooling, the number of SPIDs won't measure the total number of "users" or "seats", but counting concurrent SPIDs can be used to cap usage.
I haven't studied the licensing documents in a year or so, but MS was very explicit that you couldn't use that stunt to avoid licensing charges. My previous employer had an ERP system (that cannot be sufficiently cursed) that used an application server (and did everything through RBAR with zero stored procedures) that had a single connection going to SQL Server, even though there were 200+ people using it.
They were using Enterprise edition, so they were fine. Much better off than if they were using the D-7 edition. :hehe:
Not under the current licensing model no, if we're just blue sky gazing about a "better pricing model", paying for concurrent SPIDs (rather than CPU cores or warm bodies) might make more sense for both the customer and Microsoft. It could make sense for a certain case usage, like a data warehouse or ETL server.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 21, 2016 at 10:30 am
I find the discussion interesting compared to what I've heard about IBM mainframes. The additional processing capacity is there, but it's restrained by the license. If you need additional power for EOY or holiday processing, you pay a little more for your license and the power is temporarily unlocked. After the peak crush is over, you're back to your normal processing levels.
But that's just at the hardware level, I have no idea if they do similar contortions with things like DB2.
I agree with a previous post about charging only for production servers and active end users, not for development/QA/deployment, only production. Hot spares shouldn't count but can't be 'bigger' than the system they're waiting to fail.
Since we can get away with spending $50 per developer on Developer Edition, are there specific prohibitions against using Dev Ed for the full DLC chain? They're not being used for production at that point.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
January 21, 2016 at 11:58 am
g.britton (1/21/2016)
Yet Another DBA (1/21/2016)
I think that most will use a developers copy or msdn copy for all non-production copies of sql.+1
MSDN works for me in development. I do have to watch what features I use and make certain that the targeted production SQL supports them but that is easy if one has just a tad of discipline.
For production the license depends on the function of the SQL install. If high volume transactional, an Operational Data Store or Staging server, or a Document Server either buy what you need for the level of service required or fail.
Not all gray hairs are Dinosaurs!
January 21, 2016 at 11:59 am
My impression from reading some of the "leading" IT mags is that M$ SQL is losing market share especially to MySQL. I know if you look at Craigslist in my area (Seattle) there are a heck of lot more jobs asking for MySQL. I just hope M$ sees this (if it's really true) and tries to make an adjustment because it seems like it's fading a bit. I think costs are the major factor here.
January 21, 2016 at 12:41 pm
John Hanrahan (1/21/2016)
My impression from reading some of the "leading" IT mags is that M$ SQL is losing market share especially to MySQL. I know if you look at Craigslist in my area (Seattle) there are a heck of lot more jobs asking for MySQL. I just hope M$ sees this (if it's really true) and tries to make an adjustment because it seems like it's fading a bit. I think costs are the major factor here.
I'd be curious to consider what they consider the market for those statements. I don't see MySQL replacing MS SQL Server or Oracle for that matter but on the other hand it does fulfill a different need that is becoming more prevalent as more and more applications and canned websites deploy with a prebuilt MySQL backend.
Viewing 15 posts - 16 through 30 (of 36 total)
You must be logged in to reply to this topic. Login to reply