Re: Possible bridges between OO programming proponents and relational model
- From: Kenneth Downs <knode.wants.this@xxxxxxxxxxxx>
- Date: Tue, 30 May 2006 19:07:23 -0400
Cimode wrote:
I noticed a recurring commercial argumentation about creating
*behavior* into components (named classes). This caracteristics is
often presented as being a differentiation of relational model where no
such thing really exists (and in fact is not necessary). In a word, In
OO approach (for whatever it may rely on), one of the main limitation
of relational model would be not to allow its elementary components to
emulate elementary predefined processes (transformations for instance).
You don't have to worry all that much about what the relational model allows
or doesn't allow. As anybody here can tell you, there are no pure
relational databases in the Real World.
What we have is quasi-relational table-based systems that in fact can handle
processes very well.
The problem is in how you think about the process, especially
transformations. All transformations and processes can be mapped into
simple precise definitions of what values should be written to what columns
of what tables. In other words, processes resolve to database
specifications. If you can specify it, you can code it.
When trying to specify processes in terms of tables, the relational concepts
of unique key and foreign key come in very handy for specifying how data
should be moved from place to place as it is transformed. Adding basic
formulas finishes it off.
So sure, the RM can't do it, but who cares? Table-centric systems can.
--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
.
- References:
- Prev by Date: Re: Mildly OT: dBASE IV
- Next by Date: Re: Why all the max length constraints?
- Previous by thread: Possible bridges between OO programming proponents and relational model
- Index(es):
Relevant Pages
|
