| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Joe Van Dyk wrote:
> Alfredo Novoa wrote:
>
>> Robert Martin wrote:
This gets back to some questions I asked elsewhere in this massive thread:
"This 'domain logic' to which you [Sasa] refer. What does it do that is not entering, manipulating, reporting or deriving data? Of that which remains, what does not interface with the external world through some device or another?"
Obviously, the primary domain of data management systems includes entering, manipulating, reporting and deriving data. The best formalism we currently have for doing all of that is the relational model.
The questions that remain are: How often does the relational model provide a good formalism for interfacing with the external world? Do we have better formalisms for interfacing with the external world? How can we improve upon the formalisms we have?
Certainly, at the logical level, we could use relations instead of SOAP requests and responses to communicate to external systems, and at the logical level, we could treat those external systems as sets of relation variables. At the physical level, we could even use SOAP requests and responses to represent the relations.
Doing so would mean we would have all the features available for making views updatable at our disposal for dealing with versioning issues.
Doing so would mean we would have the full power of the calculus for expressing constraints.
Doing so would make issuing a set of requests as easy as issuing a single request.
Doint so would leverage the existing encryption, authentication/security, transaction, auditing, integrity etc. functions of the dbms.
I have no doubt that Dr. Codd expected businesses to use relations for communicating. Of course, businesses must still find some common ground for doing so.
I suggest it is possible to create a 'driver' that represents any physical I/O device as relation variables. Whether that is always the best thing to do is a good question to ask even if we do not have the answer. Even if we suspect the answer is "no", the question then becomes "When is it the best thing to do?"
Again, doing so would leverage existing encryption, authentication/security, transacton, auditing, integrity etc. functions of the dbms. Received on Thu Jun 01 2006 - 23:02:02 CDT
![]() |
![]() |