Re: Entity and Identity

On Jul 20, 5:51 pm, "Walter Mitty" <wami..._at_verizon.net> wrote:
> I've known for quite some time that better minds than mine have gone astray
> in the attempt to overcome the object relational mismatch.  Just last week,
> I ran across an article that outlines the O-R mapping problem better than I
> ever could.
>
> The article is called "The Vietnam of Computer Science", and here's a
> pointer:
>
> http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science...
>
> The article devotes rather too much time to exploring the analogy between
> the Vietnam war and ORM attempts.  And as the article admits, all analogies
> eventually fail.  Leaving that aside, I think the survey of problems
> encountered in crossing the divide is excellent.
>
> I want to draw particular  attention to a heading entitled "Entity Identity
> Issues".  Reading this section gave me a better understanding of the
> disconnect between me and Brian Seltzer over matters concerning entity and
> identity.  My own view of identity is colored by my own experience.  And
> that experience includes some practical work with relational databases,
> preceded by a little formal learning in that area and 20 years of work as a
> programmer.  Unfortunately, none of that work included object oriented
> programming.
>
> Anyway, my view of identity (or of identification, if you prefer) is that an
> object's state is all we have to go on as the basis for identification.  In
> particular, an object's location (as specified by a pointer) or its
> trajectory (a history of pointers over time) are unavailable for purposes of
> identification.  This view of identity fits pretty comfortably into the
> relional model, but it runs afoul of object oriented thinking at least two
> important ways.  Frst, if an object can conceal part of its state
> (encapsulation),  then it necessarily can conceal some of what needs to be
> known to identify it.  Second, if two objects  are identical in state, then
> they are the same object, even if they differ in location (at the same point
> in time).  I'll call this the "Doppelganger effect".
>
> When I see an SQL table with two different rows in one table that cannot be
> distinguished by their contents, my reaction is that the database designer
> made a mistake.  Failing in that, the database updaters should have been
> more careful.  Cases where duplication is intentional and carries
> significant information strike me as a misuse of SQL, and a misunderstanding
> of the relational model.
>
> The above doesn't pretend to explain Brian's view.   But I think it sheds a
> little light on why I see things the way I do.
>
> Again, I recommend the article cited above.

The article states: 'The opposite approach--a "relational-only" approach--is almost nonsensical to consider, given the technology of the day at the time this was written'

It sounds as if it just might be doable. Not like a D language, but like a DBMS with support for executing certain forms of data (since code is just another type of data, lisp and prolog proved that). All functions are relations, right? So can a functional programming paradigm be embedded in the relational model? Is there a relational model of computation? Just wondering... Received on Wed Jul 22 2009 - 14:29:30 CEST