Re: An object-oriented network DBMS from relational DBMS point of view

From: Walt <wamitty_at_verizon.net>
Date: Tue, 13 Mar 2007 13:45:15 GMT
Message-ID: <LVxJh.3997$8o1.3868_at_trndny01>


"topmind" <topmind_at_technologist.com> wrote in message news:1173745603.434263.291930_at_t69g2000cwt.googlegroups.com... On Mar 12, 4:54 pm, "JOG" <j..._at_cs.nott.ac.uk> wrote:
> On Mar 12, 6:08 pm, "Dmitry Shuklin" <shuk..._at_bk.ru> wrote:
>
> > On 10 อมา, 18:32, "JOG" <j..._at_cs.nott.ac.uk> wrote:
>
> > > - Row A says Aristotle is a Row Z
> > > - Row Z says a Human is a mortal.
>
> > No,
> > Row A has attribute Name = "Aristotle" and attribute Type = RowZ
> > Row Z has attribute Lifetime = "mortal"
>
> > So here is one join
>
> Hi dimitry,
>
> First let me make it clear i'm an OO coder, as well as having an
> interest in db theory so I don't have an vested interested in one area
> more than the other. However I sincerely believe that DB theory over
> the past 30 years has progressed information modelling through its
> abandonment of OID's - essentially enforcing that there is no identity
> outside of attributes. After all this is how we perform identification
> outside of a system, and so there seems no reason to think we should
> require an extra mechanism once we are encoding information
> (especially now our models are logical ones completely separated from
> physical layer considerations). Row identifiers hence seem
> superfluous, adding an unnecessary layer of complexity that doesn't
> actually give me anything /extra/.
>
> Like yourself, I believe there may be scope for a useful middle ground
> between object and relational approaches (despite their philosophical
> differences). But I'm not sure what you propose is that middle-ground.
> Get rid of those OID's, allow me to join objects and work
> declaratively, and I'll be all ears. J.

>To clarify, I hope you are not ruling out system-generated ID's (such
>as sequentially-assigned employee ID's). These can be quite useful in
>practice. Ideally domain attributes would do the job of unique
>identification alone, but it often does not pan out that way. (The
>biggest difference between RDBMS generated ID's and object-ID's is
> that the DB ones "stay" and are not tied to physical RAM.)

The above, and more. System generated IDs are no more and no less artificial than human generated arbitrary IDs. For example, it's possible that there's a person over at the Social Security Administration who is in charge of doling out new SSNs. Or it's possible that it's done automatically by an application program. Or it's possible that it's done by the sequence generator inside some DBMS. It may even be done by a distributed mechanism, to avoid a bottleneck.

It doesn't matter. The ID is equally artificial in all the above cases, and some others. Received on Tue Mar 13 2007 - 14:45:15 CET

Original text of this message