Re: theoretical question on the RDBMS

"Lauri Pietarinen" <lauri.pietarinen_at_atbusiness.com> wrote in message news: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...

So the saying goes ,,,

> > 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:

OK. Thanks.

> 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:
>
> - The error message he receives is the same as the
> logical meaning of the constraint!
>
> 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).

It is indeed, but we now have two machines and an investment in two places. We have an investment in the RDBMS and an investment in the product X which requires the application server.

Things may be transparent such that all anyone deals with are the database constraints, but it is a cludge. It is still not theoretically at optimum.

> 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.

You are correct in what you say in my opinion.

I want to be able to take Product X off the application server and place it inside the RDBMS so that I deal with my orgainsational intelligence and my data in the one environment. ie: within the RDBMS.

Best wishes,

Farmer Brown
Falls Creek, OZ Received on Sun Aug 11 2002 - 00:53:18 CEST