Re: What so special about PostgreSQL and other RDBMS?

"Doug Hutcheson" <doug.blot.hutcheson_at_nrm.blot.qld.blot.gov.blot.au> wrote in message news:<QySqc.2189$IH5.98940_at_news.optus.net.au>...

> Guys, Guys....
> Calm down.

> The propositions put forth by Quirk are becoming lost in a tide of acrimony.

Thanks Doug, it's nice to know that there are one or two actual developers in these groups, but anyway, I think it's pointless to go on discussing these things in this thread, it's pretty clear to me we are dealing with zealots and those looking for genuine answers have likely stopped reading long ago, I'll avoid argueing with them and instead stick to giving good suggestions, the readers can make up their own minds, as they should in any case.

You summary of the issues should be enough for those with real questions, I'll add a few comments and leave it at that.

> 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.
>
> I agree with that proposition.

And also note that simply issolating database functions in your code is a easy and light way to abstract data access, just to make this clear for those that keep insisting that database access abstraction means automaticaly including a third tier:

For instance, in pseudocode:

    function myapp_query(query)

        if not connected
            prop_connect
       result = prop_query(query)
       for each result
           data(ii++) = prop_fetch(result)
       if not set cleanup
           set cleanup connection callback
                prop_disconnect
       return data

That is a very simple wrapper, an abstraction object like PEAR::DB is a lot more complex, but that works for simple issolation assuming standard SQL, we issolate the use of the proprietry bindings ('prop_*') to one function, and convert our result set into a standard array, manage openning our db connection and register a callback to close, all in one place.

Not using SQL as the argument, but rather a more general request describer is a further abstraction that makes your application cleaner, but that is another subject, which if there interest, I could explain in more detail.

Then you have your application:

    function myintreface()

        global data
        data = myapp_query(<query>) 

    function myview()
        global data
        for each data
             display data (ii++)

    function mydetail(key)
       global data
       display data(key)   

And so on...

The functions themselves only use the wrapper, 'myapp_query', and a native array, 'data'. So, if your application has hundreds of functions that use the wrapper function and/or the native array, and only a few functions where the proprietary bindings are issolated, you can migrate much easier, or even take advantage of new features in your existing platform more quickly, because you have issolated the data access code.

I even use such a data access wrapper when I do use a data abstraction object, it keeps my code cleaner, and I can even change the abstraction object if I like, even, when needed, (*gasp*) intoduce another tier.

> 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.

And, of course, a self contained, self describing, human readable file is also usefull when the data has a long life span, and may in fact out live the application and the platform, or when the data needs to be shared with other organisations and their applications.  

> Note that neither Quirk nor I claim that these propositions always apply to
> every situation, nor that there are not clear and obvious exceptions.

That's right, these are suggestions, each application has its own requirements, this is why at first it was confusing to me why the likes of Volker scream and shout that these suggestions are bad because it deosn't suite their application (or so they think), but then it became pretty obvious since Volkers most recent drivel, where he argues with the subject title of the thread instead of my arguments and claims that my arguments are an attempt at diversion, even though I have maintained them form my first post. The likes of Volker are just rabid scum, and talking to them, and the other zeolots just distracts from the topic and likely drives away any readers who are generaly interested in the topic being discussed.

Regards,
Dmytri Kleiner
my initials at trick dot ca will reach me (I don't live in Canada anymore though)    

> However, I must take issue with Noons, who states:
>
> > 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.
>
>
> There are large companies in our industry who are famous for implementing
> backward-incompatibility in new versions of their software. Further, most
> support is time limited: once the software has reached a certain age, the
> vendor demands that you upgrade (at your cost) if you want to continue to
> receive support and bug fixes. Clearly, that makes good commercial sense and
> nobody would dispute their right to drop suport for old products, but it
> does lock customers into an "upgrade or else" cost cycle. 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.
>
> The point here is that current commercial practice by many vendors forces
> clients into expensive upgrades which have no direct commercial benefit to
> the customer. Quirk's propositions present a scenario under which customers
> have the freedom to choose what to upgrade and how much to spend, based on
> their own business imperatives and not those of a third party on which they
> depend.
>
> After 25 years in the industry, I know of many organisations which are
> getting heartily sick of spending vast sums of money in knee-jerk upgrades
> (which usually involves staff retraining and other ancilliary expenses) at
> the whim of a vendor. When I am able to offer my customers an alternative to
> this revenue drain, I am happy to do so. It is not always possible or
> appropriate, but when it is, the benefits are exactly as Quirk has laid out.
>
> Your mileage may vary.
>
> Kind regards,
> Doug Hutcheson
Received on Sat May 22 2004 - 06:05:12 CDT