Home -> Usenet -> comp.databases.theory -> Re: theoretical question on the RDBMS

Re: theoretical question on the RDBMS

From: Lauri Pietarinen <lauri.pietarinen_at_atbusiness.com>
Date: 10 Aug 2002 02:35:42 -0700
Message-ID: <e9d83568.0208100135.7e4655e9_at_posting.google.com> 






> 

> Transparencies just mean you cannot see that


> there exists another layer of application X  between

> you and the RDBMS.

>




Exactly - and that is the whole idea! You just deal
with the database schema and the rules that are
conceptually very similar.  The product then optimises
when and where to do what.
 


> I dont think this product as is would fit


> the bill we are after.




Well, seeing is believing...
 


> 

> Thanks for all the information.

> Dataphor looks to be some form of

> SQL algebra, so we are immediately

> again stepping outside of the RDBMS

> and therefore I dont think this solution


> is the general one.




Maybe I could elaborate on what I think this
rule based thing is about:



Take a "typical" table



create table Customer

 ( customer_id integer primary key,
   customer_name char(50) not null,
   customer_credit_rate money not null );





This table alone implies (at least) the following
rules:



    
  
  •   we deal with customers
  
  •   each customer has it's own id
  
  •   each customer has a name
  
  •   each customer has a credit rate






Then we have referential integrity constraints,
which are rules also, e.g.



create table Order


 ( order_id integer primary key,


   customer_id integer not null references Customer,
   order_sum money not null,


   order_date date not null );



    
  
  •   each order belongs to one and only one customer
  
  •   + plus the other implied rules.






We can have more elaborate rules, e.g. 


customer cannot have unpaid orders over


his credit rate.  These can be expressed
in a manner that is very similar to defining
tables (details beyond the scope of this posting,
but see IBM Redbook).



When a user tries to do something to the data
that breaks the rules he gets an error message -
and the whole beauty is this:






  E.g. "Cannot add order because customer does not have any more credit"



What happens is that the distinction between the database
and the application logic blurres - no more impedance miss match.



And a clever application server will also know how to optimise
processing so that it will do the right thing in the right
place: simple checks on the client side, complex ones on
the server side etc...



It is really so natural and simple (at least as a concept).



I think database people need to think beyond the idea that
a (relational) database is just a place where you put your stuff - it
has the potential of being _much_ more.



Lauri
Received on Sat Aug 10 2002 - 11:35:42 CEST












Original text of this message