Re: Pricing question?

BigBoote66_at_hotmail.com wrote:

>When our customers purchase our product, they also must purchase an
>Oracle license. So your friend's client changing their system to
>Oracle won't mean more licensing costs for them (there will be other
>costs associated with switching technologies, of course), but it will
>add to the cost of each unit sold of their product. Even if they're
>not selling Oracle with the product, their customer's going to pay for
>it, so whether you add $N to the final price or the customer does, the
>result is in increase in cost or a decrease in profit.

But, essentially, you are saying that it doesn't matter how many licences you (as a VAR) "sell", Oracle's going to charge the price that they charge regardless if you sell 10 systems per annum or 1000?

>Keep in mind that selling a "turnkey" product based on Oracle has its
>own set of problems. In addition to the licensing costs, you're going
>to have some customers that want nothing to do with Oracle - they may
>be "100% SQL Server/DB2" shops, etc.

As I understand it, SQL Server doesn't enter into it, because it's Linux based product. As for any other DB, I think that they basically set up the box and add it to the network of the client company, so in a way, it doesn't really matter if they have used DB2 in the past, this machine will be running Oracle. I don't think they sell their system to IT companies, and I don't think it's an issue - I'll double check with my friend.

> You'll have others who have their
>own IT & DBA people who want to have ownership of the server or the
>backup process (you're going to want them to have some ownership over
>backup, even if it means they need to copy the files RMAN produces to
>some other location on their network periodically).

Again, I don't imagine this to be a problem. As I understand matters anyway, isn't Oracle very good at keeping base data and schema details from end users (even customer DBA's), through obfuscation and also allowing anybody at all to backup and restore, but not actually check out the structure of the db, or get their hands on any proprietary data?

> They may dictate
>what kind of hardware you're going to want to run the system on, or may
>insist on auditing your database if they think they're really something
>special or have an IT department that's looking for something to do.

Again, that's a matter I'll have to ask about. Personally though, I'd be a lot (and I mean a *_lot_* happier knowing my firm's data was on Oracle than on any proprietary system - I have come to learn to distrust proprietary systems and the "Oh, we have a guy who can give you all that functionality...." . Guy changes job/falls under a bus/becomes a "consultant" and you're screwed, just like this company.

>I'm a big fan of Oracle, but for both political & technical reasons,

Technical I understand, would you care to expand on the "political" bit?

> it is not always the best solution for software products that have an
>"embedded" database.

Of course not. I did say that I brought my friend through everything from PostgreSQL, Firebird, MySQL, Interbase, Informix, MS SQL Server to Oracle. *_Technically_* I think there is no reason that every one (bar perhaps MySQL) wouldn't work. But, as I pointed out, he also asked what would look best on his own c.v. and the answer had to be Oracle.

> If you don't think you're going to need the high
>availability/high reliability features of Oracle (hot backups,
>clusters, etc.),

Don't go for EE, but rather Standard?

> or if customers are okay with the idea of losing up to
>a day of data in the event of a catastrophic crash and only use the
>system during business hours (meaning you can just take a cold backup
>of your data files during the evening when the system is offline), you
>may want to choose a lighter weight solution.

Vide supra.

> MySQL can be a good
>solution for a system that only needs basic SQL functionality and
>doesn't require high write performance (in terms of many concurrent
>users) - if you have occasional (as in less than 10/minute) writes and
>many queries, it's a good choice.

Ditto. And some of the other Open Source db's are great under heavy(ish) concurrent loads. Stats from an Interbase ng. that I follow, had an 89 GB db with 200 or so concurrent users and truckloads of SP's, triggers &c. - I'm quite sure it would more than cope with their needs.

>Your friend willl definitely learn a ton working with a system like
>Oracle, but make sure you're using the right tool for the customer.

As I said, it's a balancing act between that and what he can get on his c.v. I don't know this firm's price point, and how much adding an Oracle licence would be pain-ful or pain-less. They may well turn around and tell him that there's no way they're going to use Oracle, so he might again turn to me and I might point him down the road of PostgreSQL or Firebird or wherever.

Also, a final point of a discussional nature. You (rightly) mentioned that some places may be "only DB2/MS SQL/Whatever". I have worked for companies in the past (and I'm not talking about minnows here) who just use the db as a bit bucket - i.e. their system will work virtually no matter what db you point it at, but the system makes no use of triggers, SP's and anything else "vendor specific". I'm also thinking of saying that to him (this being dependent on a "translation" of the C/C++ of the original programme and whether much processing is needed on the db side, or whether it's all done in code, in which case, they might be able to use the fact that they can point their system at any db a selling point.

Anyway, thanks for your input.

Paul...

-- 

plinehan __at__ yahoo __dot__ __com__

XP Pro, SP 2, 

Oracle, 9.2.0.1.0 (Enterprise Ed.)
Interbase 6.0.2.0;

When asking database related questions, please give other posters 
some clues, like operating system, version of db being used and DDL.
The exact text and/or number of error messages is useful (!= "it didn't work!").
Thanks.
 
Furthermore, As a courtesy to those who spend 
time analyzing and attempting to help, please 
do not top post.