Re: What so special about PostgreSQL and other RDBMS?

[e-mail] (Quirk) wrote in message news:<[e-mail]>...

> Thanks for all your effort Volker, but I will continue putting any
> proprietary bindings my own functions, and use those functions through
> out my application, rather than have proprietary binding through out
> my application, and I will continue to recomend that others do the
> same, you do whatever you want though.

<nit-picking>
I really wish people would call things by the names they've had for
decades, rather than inventing new ways to say PRECISELY the same thing.
Let me provide the example:
"...but I will continue putting any proprietary dependencies in my
own functions, and use those functions through my applicatin, rather than
have proprietary dependencies through out my application..."

THERE!  I've said it.  "bindings" means exactly squat outside the world
of S&M. The correct term is "dependencies". 
</nit-picking>

> Funny, that's what I said. Usualy however, performance concerns are
> not terribly significant and the abstraction can be kept very light
> weight.

Actually, IME performance is the biggest concern.  I still have
to see ONE application built using these modern "concepts" of
"abstraction" from everything and the kitchen sink that doesn't 
have a serious performance problem outside of demo environments...


> Access to the source code gives you the freedom to swith 'database
> specialists' even if you never touch the code yourself.

Access to the source code of the database lets you do this?
I don't think so...  I mean, isn't that the whole opposite
of abstracting implementation details?  

Do what you recommend:  wrap your application functionality around 
the available API for the base-layer software, be that db or whatever.  
And that's it.   Why the heck would you want to become dependent on 
yet another piece of source code?  What's the point of writing 
wrappers in the first place for something you have the source code of?

> It also means you never have to stop using the product simply because
> the vendor wants to sell you a new one if the product continues to
> meet your needs, since with source, you can recompile for for a new
> cpu, a new os, or when new security updates are available for the
> libraries it depends on.

But, my dear cyber-friend:  no vendor of anything considered
base-layer software like databases has EVER changed the product 
so much that it broke all previous code!  That would be called
"suicide" in market terms.  It's never happened, it will never happen!
There is NO NEED to work around such an eventuality: it won't happen,
it's a wasted effort.  

Now, if you have to interface to freeware, I'd be sick worried: there 
is no guarantee whatsoever that some drongo won't go changing everything 
next month.  It's happened before many times.  It's with freeware that 
you need a STACK of wrappers to protect you from sudden underlying
code changes!  Not with commercial software!

> With source, you have the assurance that the product is yours for
> keeps, just like your own code, without source, you have no such
> assurance.

The question of course being: what the heck do I need that source
for in the first place?

> > And in what way is that different if mysql AB goes bust and fails to deliver?
> 
> You still have the source code.

I don't think Oracle, nor Sybase, nor M$ are about to go bust any day
now...  Why worry about what might happen in 10 years time if
the average lifetime of any IT application nowadays is 3 years tops?
After that it's replacement/upgrade time.  It's a waste of time
and resources to plan any further than that, I'm telling you!

> You do not need to, just like if you design a curcuit with a
> proprietary conector or a standard one, the former is expensive and
> only comes from one comany, the later is cheap and comes from many.

It's the connector!  NOT the entire wiring behind it that you need
to make portable, isn't it?  Like I said: why bother with the 
entire edifice of the source code for a db when all you want
is the API?

> Unless you really need the former, you would always chose the later.
> In neither case are you required to manufacture connectors.

Precisely.  So, why bother with the source code that lets you
manufacture connectors?  See what I mean?

> Since the Market is growing rather fast, and big names like SAP are
> promoting it, I see no reason to worry about a lack of support for
> MySQL.

Now you lost me: ANYTHING that SAP promotes is emminently
objectionable and suspicious, IMHO!  THERE is an example
of a totally proprietary company, if I ever saw one....


> Oracle has you trapped because no one else can compete with them,
> since their source is closed. 

I BEG your pardon?  Care to rephrase that?  Since WHEN is 
availability of source code ANY measure of competitiveness
or existence of competitiveness?  Exactly where have you been 
hiding if you think no one competes with Oracle?  Helloooo????  :)

> typical IBM consulting clients, however, with SAP behind MySQL AB,
> this could soon change.

I'll agree with that.  Put SAP behind anything and it stops
being cheap and competitive...

> If the code is a working part of your application, it is not obsolete,
> however a closed source vendor can obsolete it on purpose to force you
> to buy a new licence.

Don't confuse "making it obsolete" with "making it inoperational".
The two things are worlds apart.  I drove a 15 year old car
for YEARS!

> First of all, you do not have any such right, secondly, without
> source, how you will compile it for your new CPU, or new OS, or to
> link a security-updated library?

No one will, old chap.  It's called upgrade lifecycle.  You are
wasting a lot of resources and work making yourself obsolescence-free
in a society that made obsolescence a way of life about 30 years ago.

All this to say: I understand your motivation and it makes sense
in terms of engineering concerns.  But, there is one thing called
(I hate to use a common place) "real world". 
Wasted effort, in today's real world, to try and make an IT product
obsolescence-free.  

> Funny, that's exactly what I said, many times in this thread. Yet
> abstarction is good advice, which is, as I've also said many times,
> all I have offered.

Yeah sure.  But abstraction doesn't mean over-complicate your work
by taking in even more source code!  Abstraction is used PRECISELY
to reduce the amount of source code you have to worry about.  That
is what an API is for!

> What kind of idiot are you?

Now, that's the spirit!!!!!    :)
Anyways I'm coming in late on this one, so reply only if
you could be bothered.  I just thought I'd throw in a few thoughts
prompted by some things you said that rang a bell.

Cheers
Nuno Souto
[e-mail]