Re: What so special about PostgreSQL and other RDBMS?

"Quirk" <[e-mail]> wrote in message
news:[e-mail]...
> Thanks Nick,  your alternative propositions are much clearer than the
> FUD of the other posters. Although, your attitude seems no less
> belligerent, so my hopes for a fruitfull discusion are not high.

Last time I looked my name was Niall, but then its only in my email address
and signature and display name so I guess I can forgive you for missing it
:(  I'm afraid you are probably correct about the liklihood of a fruitful
discussion since you seem to have managed to get heated with every single
one of the posters that I am aware of who regularly post well thought out
informative posts.

Never the less


> "Niall Litchfield" <[e-mail]> wrote in message
news:<40ad113c$0$20509$[e-mail]>...
>
> > > Proposition 1:
> > > There are circumstances under which my client is better protected
against
> > > commercial or accidental events, if he possesses source code to the
> > > application and the underlying database management system.
>
> > Proposition 1a.
> > There are circumstances under which my client is better protected
against
> > commercial or accidental events, if he possesses a contract with a
> > financially stable vendor of the application and/or underlying database
> > management system.
>
> > Is exactly as true as Proposition 1. Define the circumstances. then
relate
> > them to the real business world.
>
> In the real business world, outside of major corporations (and
> sometimes even  there), closed source software is either used
> comepletely illegaly or seriously overdeployed, thus support from the
> provider is unavailable or limited to simple telephone support.
>
> The applications are generaly supported by consultants, who are
> aquired directly or from
> consuting agencies and not development firms.
>
> I'm not saying that this is always the case, or is your case, but it
> is the real world you asked about, and that's it.

If true, and there is some truth to this, I don't see what failing to get
the legalities right has to do with having access to the source. This is
about license management and control of procurement.

> Having source, and using free software is becoming more and more
> common in these cases, and it can be assumed that many of the people
> asking questions in this news
> group are working in such environements.

I'd be careful how you define 'this newsgroup' - it may well be true in
alt.php.sql - it is extremely unlikely to be true in
comp.databases.oracle.server, and I'd guess the sybase group would be
different as well.

> So, when the question of Free versus Propietary Databases is asked, I
> think it is important to help people understand the advantages of
> having source, or using free software, of avoiding dependencies, *as
> well* as comparing features.

No software project, even if you have access to all the source is 'free' of
dependencies, at the very least you are dependent on skill and expertise -
most probably on a whole host of things. FWIW most commercial projects that
fail, fail not because the software is commercial, but because the project
is poorly scoped, poorly managed, inadequately supported by management or
all if the above.

 > As I said in my article in the NonProfitTimes, wether or not a
> particular peice of free software is better that a particular peice of
> nonfree software, free is better than stolen.

Ah a straw man argument. Seen them before.


> > > Proposition 2:
> > > There are circumstances under which my client is better protected
against
> > > commercial or accidental events, if I have coded my application in
such a
> > > way (by use of a database abstraction layer) that migrating my
application
> > > to a different database management system is made very easy.
>
> > Proposition 2a
>
> > There are circumstances under which my client is royally screwed if he
has
> > an app that does not take advantage of the platform on which it is
running,
> > even if this means being dependent upon that platform.
>
> Issolating your data access code does not mean you can not take
> advantage of the platform, it means that all your data access code is
> in one place, meaning that you can more easily change your
> application, for instance to migrate it, or for instance to *make
> better use of the platform you are running*

It almost always does mean you can't take advantage of the platform.

I have 2 databases, both run on clustered hardware, db 1 can resume a select
statement that was issued on a failed node on a second node of the cluster,
db 2 can't. How, precisely, do you 'abstract' this difference in capability
whilst preserving the ability of db 1 to handle failed nodes more gracefully
than db 2. How, precisely, do you abstract differences in datatype between
two db platforms without performing excessive casting..

> > > Proposition 3:
> > > There are circumstances under which my client is better protected
against
> > > commercial or accidental events, if he has a human readable backup of
the
> > > database of the type Quirk describes.
> > >
> > > I agree with that proposition.
> >
> > Why do the words filing cabinet come to mind :(
>
> Because your companies record keepers distrust your closed-source,
> unabstraced application's data so much that they insist on keeping
> their trusty paper records.

And there I was thinking that a proper paper filing system worked just fine
for the purpose for which it was designed.


> With proper electronic archives as I've described, they will soon
> enough be conviced to replace the filing cabinets with datacabinets,
> but it will take some convincing, since after years of dealing with
> developers like Volker (my new synonym for unskilled labour), and
> losing access to their data, they rightfully do not trust the
> datasystems.

The open-paperless office I love the vision.

You snipped what i was referring to, perhaps you misunderstod

referring to

>If a customer
> decides not to upgrade, the vendor has effectively broken the code for the
> customer as soon as the next bug or insecurity is encountered: no support
> means no fix.

I said

> > Where can I get the security & performance fixes for linux kernel 1.5 -
I
> > don't want to upgrade?
>
> You are equivicating here on the difference between installing more
> recent software and paying for a new licence, one is not the same as
> the other.

Not at all. You claimed that if I have access to the source, as I do with
Linux 1.5, then I can always find a way forward without external
dependencies. The only route to what you claim as an advantage would seem to
be rewriting the code in-house, or being dependent on external agencies with
whom I don't have a legal relationship (you don't seem to like legal
relationships much) . Perhaps you suggest that we review  and understand in
house the change log between kernel 1.5 and kernel 2.4 before applying 2.4,
or is there a support contract available that will backport fixes from later
linux to earlier linux. Oracle can and do backport fixes.

Oh and by the way I am perfectly free under my licence to install new
versions of the Oracle software for no change in cost and with the same
support.


-- 
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com