Re: OO vs. RDB challenge
alex99_at_medcentral.com.au
Date: 03/21/05
- Next message: topmind: "Re: Application logic and Business logic"
- Previous message: alex99_at_medcentral.com.au: "Re: OO vs. RDB challenge"
- In reply to: Costin Cozianu: "Re: OO vs. RDB challenge"
- Next in thread: Costin Cozianu: "Re: OO vs. RDB challenge"
- Reply: Costin Cozianu: "Re: OO vs. RDB challenge"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 20 Mar 2005 18:43:12 -0800
Costin Cozianu wrote:
> alex99@medcentral.com.au wrote:
> > Costin Cozianu wrote:
> >
> >>alex99@medcentral.com.au wrote:
> >>
> >>>Costin Cozianu wrote:
> >>>
> >>>
> >>>>alex99@medcentral.com.au wrote:
> >>>>
> >>>>
> >>>>>Costin Cozianu wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>alex99@medcentral.com.au wrote:
> >
> >
> > SNIP.
> >
> >
> >>You're all just brochure speak. If you were expecting an
intelligent
> >>discussion, you wouldn't be trolling me.
> >
> >
> >>You either have something *technical* and *concrete* and *relevant*
> >>(claiming that SQL cannot control rocket engines is technically
true,
> >
> >
> >>but irrelevant to the point of being idiotic), or else this
> >>"intelligent" discussion is over.
> >
> >
> > Your reply amazes me. I assure you I am not trolling anyone.
> >
> > Can you spell out if that wiki page is only about the SQL challenge
or
> > about relational and object oriented technology in general.
> >
> > The page talks about the general case but here you seem to insist
on
> > strict adherence only to the SQL oriented challenge?
> >
> > Which is it, please clarify.
> >
>
>
> I don't understand where you get such non-sense as implying that I
> insist on a non-existent SQL challenge. Using SQL is just one of
> possible solutions. Other solutions have failed to materialize but a
lot
> of handwaving, including yours have been done instead.
>
> The challenge is clearly spelled, it is about providing an interface
> behind which the client code can manage a typical many to many
> relationship, under the normal constraints most modern software have
to
> face, including concurrent operation.
>
> More than that I do not understand what you want me to clarify.
Great thanks for that. So you're only focused on the challenge while I
am focussed on everything else on that WIKI page. So our paths don't
meet.
A typical many to many relationship for me involves "joining"
information from different kinds of sources. The definitive corporate
user list may be in a passwd file and the (reporting chain) group
information may be an XML file.
If you put the user's in a database then it gets out of sync with the
definitive list.
The groups XML file may change in structure, new fields may appear, old
ones disappear, new branches or sub-trees may appear. All easily
readable to humans and (certain kinds of software) but such a fluid
schema doesn't map easily to systems requiring a more rigid schema.
Models that use polymorphism and complex interrelationships between
objects are also of interest.
Nevermind, maybe another time,
Alex
- Next message: topmind: "Re: Application logic and Business logic"
- Previous message: alex99_at_medcentral.com.au: "Re: OO vs. RDB challenge"
- In reply to: Costin Cozianu: "Re: OO vs. RDB challenge"
- Next in thread: Costin Cozianu: "Re: OO vs. RDB challenge"
- Reply: Costin Cozianu: "Re: OO vs. RDB challenge"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|