Re: licensing $$ comparison to SQLServer?

Glen A Stromquist <glen_stromquist_at_nospam.yahoo.com> wrote in message news:<1kMk9.2596$bj5.239225_at_news2.telusplanet.net>...
> Daniel Morgan wrote:
>
> > Glen A Stromquist wrote:
> >
> >> Has anyone on the NG done a licensing cost comparison to SqlServer in the
> >> recent past?
> >>
> >> We are just bringing on an enterprise wide app and our user base is going
> >> way up, and converting our grandfathered concurrent users license to
> >> accomodate the added users for a new named user license will push our
> >> cost up 385%. Needless to say my boss is less than impressed and I have
> >> been instructed to look at alternatives, as the app in question will run
> >> on either DB.
> >>
> >> I looked at the MS SQLserver site and can't find where their cost per CAL
> >> seat is. They give a price for their EE with 25 CALS, but thats all I can
> >> find at the moment.
> >>
> >> TIA
> >
> > The licensing cost is only one piece of a very complex calculation. Why
> > not ask for the Total Cost Of Ownership?
> >
> > 1. Cost to rewrite application front-end
> > 2. Cost to rewrite application back-end
> > 3. Cost to retrain personnel

From what I've seen of recent applications packages, these three are not an issue, as they are all part of the package, or things basically work "the same."

But there may be additional costs too, as often heterogenous-capable packages are written to a lowest-common-denominator, or worse, without thought towards the differences. I'm sure we've all seen threads on cdo regarding programming specifics. I've seen some real bizarro consequences, particularly in locking, scalability, and data definition.

For example, an app may be perfectly stable, with everyone sitting around waiting for Jose to get back from lunch because he locked up a bunch of rows that shouldn't even belong to him... even on row-lock capable systems...

> > 4. Cost of downtime due to instability of app, RDBMS, and/or operating
> > system 5. Cost of downtime duet to security violation
> > 6. Cost of hardware to achieve performance benchmark
> >
> > I, and my customers, gladly pay more for Oracle licenses. Because we save
> > larger dollars on everything else.
> >
> > When I was consulting at Boeing a few years back we tested the latest
> > version of SQL Server and proved that with as few as three concurrent
> > users we could bring it to its knees in a hard crash requiring a reboot.
> > The same was impossible in Oracle with 100X as many users. Needless to say
> > SQL Server, while used at Boeing, is not allowed for line-of-business
> > (mission critical) applications ... only Oracle, DB2, and Teradata. There
> > are a lot of things that are more important than the cost of a software
> > and support license. I would suggest that you consider them too.
> >
> > Daniel Morgan
>
> Yes of course you are right on all of these points, but the decision is not
> mine to make, just present the numbers to management as well as the pro's &
> cons.

Well, you could always quit in a huff! :-)

>
> I use(administer) both databases, and you dont have to sell me on Oracle.
> As far as users go however, the database itself is transparent to them so
> other than possible performance issues they would not know the difference
> as the app(s) in question will run on either platform. The sqlserver DB's
> we do have do run ok but are relatively small and simple compared to the
> Oracle DB's.

It _should_ be transparent to them. But when you find them performing extremely bizarre behaviors to get around the system's inadequacies, sometimes transparency becomes pretty murky.

>
> However since posting this I did find out some more and did find out that
> although MS is initially less expensive at 10k per server $232 per seat or
> CAL, you are paying on a per seat per database basis for EVERY database,
> whereas the way I understand Oracles licensing the named user license
> covers multi-servers, ie. you pay the same per named user if that user is
> accessing 1 or 10 oracle databases. Taking this in to account with the
> number of databases we have converting them all to SQL would likely end up
> being a wash cost wise or even more $$ than Oracle, but possibly deploying
> the new one in SQL may have a cost benefit as the Oracle named user base
> stays the same.

It may be worth your while to get your nastiest New York lawyer to talk
to the O salespeople about that grandfathering and your new stuff...

>
> I'll likely have to do a spreadsheet with all kinds of scenarios to present
> to management - lucky me! :-(
>
> Actually when it all comes out in the wash I think I may have a vaild case
> for converting our existing sqlserver db's to oracle.

Vet and publish it! Get a free pass to one of the big user group meetings! Save your boss thousands!

>
> TIA
jg

--
@home is bogus.
Watching O licensing change over the years.  Mo' money, mo' money, mo'
money.