Re: OO vs. RDB challenge

From: Rich MacDonald (rich_at_@clevercaboose.com)
Date: 03/16/05 

Date: Wed, 16 Mar 2005 02:03:24 GMT

Alfredo Novoa <alfredo_novoa@hotmail.com> wrote in
news:bq0e311404s1mm6123vqgcv0tdeuq5kj8v@4ax.com:

> On Tue, 15 Mar 2005 14:40:16 GMT, Rich MacDonald
> <rich@@clevercaboose.com> wrote:
>
>>One good thing about "business logic" in the DBMS is that its
>>declarative rather than procedural. And that's a really good thing.
>>However, in practice its outweighed by the unfortunate fact that SQL
>>is a piss-poor programming language
>
> Agreed, although that is particular to relational based DBMS's.
>
>> (VB for data)
>
> IMO it would be more accurate to say that SQL is the COBOL for data.

Better.
 
>> and the relational model hasn't bridged
>>the gap between "beautiful theory" and "useful in practice".
>
> I completely disagree. The implementations of the RM are fatally
> flawed, but they are everywhere and controlling many aspects of our
> everyday life.

I hear you. Unfortunately I'm biased because I spend a lot of time on
problems where moving my biz logic to the DBMS isn't "useful in
practice".

BTW, I think the "non-relational" star schema is eventually going to
dominate.
 
>> I wonder if
>>this is due to short-sightedness (SQL gave us a partial step that's
>>good for X% and useless for the remaining 100-X%, so accepting that X%
>>made the 100% impossible) or just that the relational mathematics
>>needs a few more layers of "sugar" to overcome its cumbersome nature
>
> If you study the matter with care you will see that it is the first.
> The Relational Model is the best possible layer, although SQL is not
> relational nor a well designed language.

I've actually studied the application of the relational model to some of
my problems and I can honestly say its nowhere near the "best possible
layer". I must admit that no existing OO language is the "best possible
layer" either, but they're better. Moving my OO language "behind the
constraints of the RDBMS" is an attractive idea in theory, but the tools
to do that are nowhere near good enough.
 
>> and make it (1)
>>productive for the programmer and (2) fast for the computer. (Pure
>>mathematics often has a ways to go before it can be useful to applied
>>mathematics.)
>
> Striking innovations often need a lot of time to be adopted. There are
> many old dogs that are not able to learn new tricks.

Its not just a question of adoption. Deciding to adopt is often the
easiest part; what's hard is making the next step practical. Read: "pure
=> neat but possibly completely impractical; applied => finally creating
new mathematics that makes the pure mathematics practical".
 
> The problem is that the partial step of SQL was so succesful that many
> people forgot to implement the whole thing, and when the problems
> arised people have forgotten that SQL was only a crappy partial
> implementation and the blamed on the model.

I agree entirely.
 
>>Graph "business logic complexity" on the x-axis and "implementation
>>complexity" on the y-axis. SQL is an exponentially rising function. OO
>>is less exponential.
>
> What do you mean with OO?

A good OO language used to implement the business logic. Persistence
being trivial in comparison.
 
> Many people here identify OO with the file processing and the network
> approaches which are exponential compared to SQL.

Their problem, not mine. BTW, you're wrong; you just don't understand
what they're saying.
 
>>Exponential of course but I can't say for sure how it really compares
>>because its never been tried.
>
> You can try it on the paper. Costin's challenge is one example.

When he first posed that problem on this ng some years ago it was simple
to solve with a 3rd object. Now he has rewritten it as "implement an
RDBMS in some other language and show its as easy as using an RDBMS". Not
willing to play that game.
 
> I could post more complex challenges to show how the file processing
> and network approaches have exponential implementation complexity
> compared to the DBMS and relational approaches.

Don't bother on my account.
 
>> I do know that I have some applications that
>>would devolve into a single table of "objects" and a single table of
>>associations in order to satisfy my business logic using the
>>relational model. The matrix-inverse puzzle hinted at the issue, but
>>went right over the head of Alredo. Hint: Where do you put the
>>constraints between tuples?
>
> I don't follow you here. I would put the constraints with the rest: in
> the catalog, the constraints database.

Sorry. Constraints between "rows", i.e., something the relational model
doesn't support without "devolving" the base model. And no I don't mean
the 2+2=4 kind although its the same deal: Your constraint solution has
to go into the rdbms as a mere row in a table.
 
> Constraints are also data. It is not a good idea to hardcode them.

Agreed. One table for the "actual data", one table for the "actual data"
constraints".

To be explicit, here is a simple example:

Variables X, a set of numbers to be calculated.
Constraints H, a set of arbitrary equality constraints on X.

Enforce H(X)=0

If X is size N and H is size M and N >= M, then whenever N-M variables
are "externally specified", the remaining M variables are determinable
and must be calculated. So calculate them.

Now I know *how* to do this with an rdbms. I just know better than to
try. Don't rub two sticks together when you have matches; not all
business logic is suited to going into the rdbms; this is a broken
record.

BTW, have you tried storing an arbitrary mathematical equation in an
rdbms? Takes lots of little tables (the addition table, the subtraction
table, the multiplication table, you get the idea table...) and lots and
lots of joins. And no you cannot cheat by storing it as a string. One
case where OO scales better IME.

Relevant Pages

  • Re: OO vs. RDB challenge
    ... That is very easy with SQL Server 2005, Oracle, DB2, etc. ... >RDBMS in some other language and show its as easy as using an RDBMS". ... Constraints between tuples are among the most ...
    (comp.object)
  • Re: Databinding - Best Practice (object-oriented)
    ... >>relational model throughout your application severely restricts the ... The Relational Model is not SQL. ... difficult to persuade developers to ditch the database independance this ... What SQL domains should be but they are not. ...
    (microsoft.public.dotnet.framework.windowsforms.databinding)
  • Re: Databinding - Best Practice (object-oriented)
    ... >>relational model throughout your application severely restricts the ... The Relational Model is not SQL. ... difficult to persuade developers to ditch the database independance this ... What SQL domains should be but they are not. ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: loop and recordset
    ... those members whose membership lapsed. ... Use the SQL language to return only the set of required ... This table obviously needs some constraints. ... ALTER TABLE enrollment_2 ADD ...
    (microsoft.public.access.modulesdaovba)
  • Re: loop and recordset
    ... there IS a missing period? ... Could your SQL approach be modified to deal with such a recordset? ... This table obviously needs some constraints. ... ALTER TABLE enrollment_2 ADD ...
    (microsoft.public.access.modulesdaovba)