Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 02 Jun 2006 04:02:02 GMT
Message-ID: <_KOfg.16362$A26.379134@ursa-nb00s0.nbnet.nb.ca>


Joe Van Dyk wrote:

> Alfredo Novoa wrote:
>

>> Robert Martin wrote:

>
> <snip>
>
> Question for the "the system's behavior needs to be in the dbms" people:
>
> My current view of a dbms is that it's a place to store stuff.
> Obviously, it can be much more than that.
>
> Say I'm writing an e-commerce website. I'm restricted to cheap and/or
> free databases, but feel free to assume that I'm not.
>
> The credit card supplied with the order needs to be verified against an
> external encrypted web service. If the order goes through, then it
> needs to notify another web service that fulfills the order. Once UPS
> ships, I need to get that information from UPS. If all the rules for
> the sytem are in the dmbs, can the dbms do all that external stuff?
> Perhaps through stored procs?
>
> If so, is anyone aware of any open source web applications that do have
> all the rules for the system in the database?
>
> And to you same people, do you think there's room for "application
> databases", where applications (who may or may not use databases for
> storing information) talk to each other through well-defined interfaces?

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

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US