Re: Oracle vs SQL Server
Date: Fri, 17 Apr 2009 20:18:06 +0200
Michael Austin schreef:
> Mladen Gogala wrote:
>> On Thu, 16 Apr 2009 07:22:20 -0700, johnbhurley wrote: >> >>> Personally I would not ask for a SQL Server reference unless that is a >>> path that you really want to go down. >> >> SQL Server is much cheaper than Oracle. Oracle is very expensive. I don't >> have any experience with SQL Server but I have moved Oracle databases >> to both MySQL and PostgreSQL. Such moves are frequently justified, in >> case of >> small databases. In many cases, Oracle RDBMS was used to replace MS >> Access, an enormous overkill. PgSQL or MySQL can do that very well at >> the fraction of the cost. If the database is larger then 4GB, Oracle >> XE is not >> an option. >> >> Of course, I did the opposite, too. One of my favorite recent projects >> included moving the product called Cacti from MySQL to Oracle. The >> polling scripts were being run simultaneously and the underlying MySQL >> database couldn't cope with 10 simultaneous transactions. The solution >> was to insert the results from the polling scripts into an Oracle XE >> and then transfer the data from Oracle XE into MySQL using Perl. After >> that, Cacti was happily drawing the results. >> >> After some experiences with Oracle's "stick 'em up and gimme all your >> money" licensing policies, I stopped recommending Oracle first. SQL >> Server
> Here's the deal with Oracle's licensing - [not being given to gambling]
> I would wager a small token that you would not find any two (maybe
> three) Oracle customers paying the same amount for the same thing. The
> one thing you need to know is that buying Oracle is like going to a used
> car lot [granted, you are buying new, but the sales tactics are similar.]
> Me: "I'll give you this much... for these options"
> Oracle Sales Person (OSP): "let me take it back to my boss first"
> [a few phone calls later]
> OSP: "I can't go that low, but what I can do is..."
> Me: " Thats not accepable - I want it for ..."
> you get the picture.
> I always recommend to the person in finance or whoever is in charge of
> procuring stuff for your company is that they be a certified (not really
> but they should be} negotiator. The OSP are very good and will take you
> to the cleaners if you are not careful.
> Another recommendation is to have them include things that really
> shouldn't be options as well as things you cannot NOT install - like all
> if the DBA pack, tuning and OEM stuff. You cannot remove it and their
> installer won't allow you to not install it. Partitioning really
> shouldn't be an option either... Spatial and other "stuff" like that,
> well, you could make a case that it is not really needed - unless of
> course you need to do spatial stuff.
> This list could go on - but I think you get the idea.
>> is a good alternative, if it works. No reasons for paying the premium >> price, if that is not needed. There is a crisis, it's a harsh world >> out there. Don't misunderestimate me, but I would check the SQL Server >> solution, too.
> I was at company that had multiple plants where the each line used XE
> that transmitted data up to a plant-level database (minimal # of users)
> that then pushed aggregates and some detail up to a corporate-level db
> and then to a DW.
> There were things at the Corp-level that would get pushed down to plant
> and line-level dbs. Very interesting configuration.
And take special care when you get tools, options or whatever that you wouldn't normally buy almost for free. You may not pay much for licenses, but support is calculated over the full LIST price. So actually, if they would give you 5 database licenses for free, you'll pay a full license price for support each year! Sales reps need a certain amount of money by the end of their bonus year to reach the target. This ends 31 may. So by that time, they don't care WHAT you buy, but only whether you pay what they NEED. And you may think you get a lot for little, but wait until the support fee bills start to come in!
Shakespeare Received on Fri Apr 17 2009 - 13:18:06 CDT