Re: General semantics

"Nilone" <reaanb_at_gmail.com> wrote in message
news:661d6afd-14f6-40f5-a48b-e9a05f5f3304_at_l6g2000vbo.googlegroups.com...
On May 21, 10:06 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>> Perhaps you are not communicating what you want to do. Creating OID> because OOPLs have pointers sounds like a bad idea. Before going down> that road, I suggest you ask yourself whether it is truly necessary and> what you hope to achieve by simulating a low-level computational model> in a higher-level symbolic algebra.

<<QUOTE
I would prefer to program in a pure relational model, but I must deal
with both OOP classes and SQL tables, so I want to understand how the
concepts and mechanisms fit together. As far as I know, relational
theory has the expressive power to describe both. I can't change the
fact that SQL tables allow duplicate rows (except via correct design,
when I decide the design), but I can recognize rowids explicitly, and
normalize tables and predict how they will join.

Similarly, I can't change the fact that OOP uses OIDs, but I can
recognize them explicitly, understand why "new Integer(1) != new
Integer(1)", and why and how a dictionary keyed on such objects
works. In fact, I can use dictionaries to map objects to attributes
based on their OID, a technique I recently used successfully in a
visual control to avoid contaminating the objects in the data model
with visual attributes. I also managed to consolidate my collection
classes in that project to three generic classes: one for unary
relations, one for binary relations, and one for sequences; it worked
pretty well even though I couldn't use relational algebra in the
language.

In the database for that project, I normalized beyond 3NF in some
cases (not in all cases, which I now regret). The unary relation
tables had a nice effect - CRUD became CRD, and since my sets of
objects were equally normalized and corresponded to the table, loading
and saving became an easy affair. Also, those tables which I
normalized fully won't need to change as often as a denormalized
table. I didn't need to design for significant scaling, but I had no
performance problems at and over the projected level of use.

>>QUOTE
Contrary to the consensus of the D&D evangelists here on c.d.t., OIDs are
not always evil. There are instances when their use is clearly indicated.
It certainly makes more sense to store the OIDs from an established
application in a relation rather than spend thousands of man-hours rewriting
the app. Anyone who argues otherwise is a fool and should be ignored.
Received on Fri May 21 2010 - 20:43:54 CDT