Re: What so special about PostgreSQL and other RDBMS?

"Quirk" <quirk_at_syntac.net> wrote in message news:4e20d3f.0405220405.57e0a8bf_at_posting.google.com...
> 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" <niall.litchfield_at_dial.pipex.com> wrote in message
news:<40ad113c$0$20509$cc9e4d1f_at_news-text.dial.pipex.com>...
>
> > > 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