Re: What so special about PostgreSQL and other RDBMS?

quirk_at_syntac.net (Quirk) wrote in message news:<4e20d3f.0405190205.416ed0ce_at_posting.google.com>...

> 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
wizofoz2k_at_yahoo.com.au.nospam Received on Wed May 19 2004 - 17:45:30 CDT