Re: What so special about PostgreSQL and other RDBMS?

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:<40ab3835$0$8990$afc38c87_at_news.optusnet.com.au>...

> Quirk wrote:
>
> [snip to cut to the chase]
>
> > Oracle has you trapped because no one else can compete with them,
> > since their source is closed. BUT EVEN STILL, I am not recomending you
> > never use Oracle, I am only recomending that abstraction is a good
> > idea, particularliy when you do not have source.
>
> [Ditto]
>
> It seems to me that if you are going to abstract because you lack the
> source code, you are likely not going to be making much use of the
> proprietary functionality you've just spent an arm and a leg on. Which
> strikes me as a waste of money.

> In other words, if you insist on taking out the abstraction insurance
> policy, don't use Oracle, because it's just money down the drain for
> functionality you're never going to use. Yet you say you would not
> recommend never using Oracle. Stripping out the double negatives, that
> presumably means you might recommend using Oracle *and* abstraction.

Hmm. Ok, well, first let me say I am in favour of the Open Source databases, so it's a little awkward that I need to defend Oracle here, but abstraction does not prevent you from benefiting from Oracle, for one, Oracle has proven performance (even with standard SQL), security and scalablity advantages that some applications and environment may need and secondly, your product may need to run in a customer's datacenter, where Oracle is the database they use.

Also, with lightweight abstraction, such as simple wrappers around proprietery bindings, you do not realy lose performance, and when you must use prorietary features, you can create additional wrappers to issolate these.

By containing the Oracle bindings to only a few places in your code, you make your application far easier to maintain and debug, let alone migrate.

Using a large abstraction object may cause performance issues, but using wrapper functions is just good coding in any case.

And regarding abstraction objects, as far as PHP goes, PEAR:DB seems to work well, with not to much lost as far as performance goes, although I have not done any major benchmarking, and if performance is critical to your application, you should. Ditto for Perl's DBI.

> Personally, I think my software assurance comes from Oracle's size and
> market share (and my support contract), and I don't need potentially
> crippling abstractions to protect me against their failure at some
> indeterminate and perhaps never-to-arrive point in the future.

And the choice is personal, so you are welcome to yours, however, you can imagine that not all applications, especialy commercial ones, can afford to tie themselves to one exclusive database, and many other applications may not want to force there users into using one exclusive database.

Also, your data abstraction functions need not be any more crippling than the rest of the application's code, so if coding these will lead to crippling the application, likely the application is well on it's way to being coded into cripledom already. Also, abstraction will generaly (i said //generaly//) have less impact on performance than your data model will.  

> I realise I'm butting in late, but that last post was soooo long, I'm
> fairly confident not one person in 1000 is going to know what the hell
> it was saying!

Yes, I agree. Thanks for the truncation :)

  Received on Wed May 19 2004 - 12:03:34 CDT