Re: An object-oriented network DBMS from relational DBMS point of view
Date: 13 Mar 2007 08:04:35 -0700
Message-ID: <1173798275.841756.98300_at_v33g2000cwv.googlegroups.com>
On Mar 13, 1:45 pm, "Walt" <wami..._at_verizon.net> wrote:
> "topmind" <topm..._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.
agreed.
>
> It doesn't matter. The ID is equally artificial in all the above cases, and
> some others.
Or equally real depending on your perspective of course. The point is that they are equally valid - just an attribute handled in the same way as every other attribute. Received on Tue Mar 13 2007 - 16:04:35 CET