Re: OOP - a question about database access
From: AndyW (awatson__at_attglobal.net)
Date: 11/08/03
- Next message: Tsolak Petrosian: "Re: GUI v Script"
- Previous message: Bob Badour: "Re: OOP - a question about database access"
- In reply to: Costin Cozianu: "Re: OOP - a question about database access"
- Next in thread: Costin Cozianu: "Re: OOP - a question about database access"
- Reply: Costin Cozianu: "Re: OOP - a question about database access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 08 Nov 2003 15:57:05 +1300
On Fri, 07 Nov 2003 17:09:29 -0800, Costin Cozianu
<c_cozianu@hotmail.com> wrote:
>
>If I want to "Put The Damn Data on The Damn Screen" (TM) , I can take
>the invoice number and total cost from one place, customer name form
>another, due data of the first shipment from yet another.
>
>This my friend, makes a tuple, and it can be obtained from a simple join
>and project (aka SELECT) so much better in SQL DBMSes than in ODBMSes,
>and the end users care that the data comes fast on the damn screen, they
>do not care at all about your OO voodoo and hollistic philosophy. If you
>hide your object identities behind the bushes (oops I meant O/R mapping
>layer), you may not be able to make the join, or even if, you may bring
>100x more bytes from the database, just because you want your objects to
>be whole.
This is part of my point. Why would you need to do any of that
selecting and organising and getting of data and formatting it just to
put it on the screen. Since by principle in OO the mere fact that I
have accessed an object means I have the data already, why would I
need to concern myself with all of the faffle of getting it from a
database.
Likewise if I am dealing with a customer and I want to display part of
a related invoice.. Would it not be faster to just traverse the
assoication from the customer to the invoice collection and have done
with it. Why should I bother with writing sql queries and joins to
do that. Bit of a waste of time in my book.
The best code is the stuff you dont have to write. And it kinda makes
me cringe at the thought of trawling through reams of legacy database
code to make changes just because someone modified the format of a
table or changed a relationship.
The two mechanisms have their merits and weaknesses like any differing
systems would. I wouldnt bother with OO DB if all I was doing was
batch processing lists of data, producing reports or basic data
entry.. But then I wouldnt try and develop a system to handle
complex parts catalogs or real time telephony rating systems in a RDB
either.
I guess if the customer has grown up using manual key systems to
unlock their doors, there is no real reason to give them a proximity
based key fob. I suspect if they have always stood in the rain
getting wet while they search for their key, i suspect they probably
wouldnt care about the benefit of having the door unlocked and open
when they got to it. :)
- Next message: Tsolak Petrosian: "Re: GUI v Script"
- Previous message: Bob Badour: "Re: OOP - a question about database access"
- In reply to: Costin Cozianu: "Re: OOP - a question about database access"
- Next in thread: Costin Cozianu: "Re: OOP - a question about database access"
- Reply: Costin Cozianu: "Re: OOP - a question about database access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|