Re: OO vs. RDB challenge

From: Alfredo Novoa (alfredo_novoa_at_hotmail.com)
Date: 03/15/05 

Date: Tue, 15 Mar 2005 16:23:27 +0100

On Tue, 15 Mar 2005 14:53:57 +0100, bruno modulix <onurb@xiludom.gro>
wrote:

>>>May I remind you that a DBMS is a program that has it's own business
>>>logic (it's business being, as the accronym implie, to manage data), and
>>>that a not-so-small part of this logic (the one dealing with internal
>>>data and indexes representation, IO access, request optimisation etc
>>>etc...) cannot be enforced by a DBMS ?
>
>What ? Stating that a DBMS is a program ? Stating that it's business is
>to manage data ? Or stating that a DBMS cannot relie on a DBMS to
>enforce (at least part of) the rules that pertain to it's business ?

Stating that physical representation, IO access and optimization is
business logic.

>> Business logic are: database structure, database constraints and
>> database derivation rules.
>
>Lol.
>
>This (obviously biased) definition implies that there is no business
>logic in an application that dont use a database, so an application that
>dont use a database can only handle presentation logic.

There are not applications that don't use data. Any organized data set
is a database independently of the representation.

On the other hand business logic is a term related to business
systems. Business logic are business system database constraints.

>> And an RDBMS is a software system that can enforce all that.
>
>I didn't say that a RDBMS could *not, never, in any way* be used to
>enforce some kinds of business rules, did I ?

What I say is that a DBMS must be computationally complete for being a
DBMS. It must have all the power of a Turing complete language (and
this consists basically in the "while" instruction).

>Nothing I saw on theses pages supported your statement that business
>logic was directly tied to DBMS.

I never said that. Business logic is directly tied to the database,
not the DBMS.

Many people in this group confuse both concepts all the time, and this
mistake explains many what you wrote.

> If I missed something, please provide
>links to more accurate documentation.

I have found an interesting link

http://www-db.stanford.edu/~ullman/dscb/ch1.pdf

> From what I saw, it's all about defining the rules that the application

The system, not the application.

>(however it's implemented) must enforce to solve the customer's problem.

No, that is a fuzzy definition. Business rules define what are the
consistent states of a database.

All business rules can be viewed as constraints. For instance if we
define the following derivation rule: "the current stock is the
initial stock plus the inputs minus the outputs", we are constrainting
the value of the current stock attribute.

> From this POV, I think it's perfectly valid to state that the
>'business' of a DBMS program is to manage user's data and enforce user's
>specified rules (users in this context being the DBA and the application
>programmer).

But it does not make any sense. A DBMS is a tool and the business
logic concept don't apply to this internal level.

><troll>
>Then what do you mean by 'objective' ?-)
></troll>

Measurable.

>Ok, I'm not here to troll, and I pretty well understand what you mean.
>
>Now what I meant here is that there is no such thing as an 'absolute'
>superiority in this domain.

And you are wrong. It was proved a long time ago. RDBMS's are
(theoretically) absolutely superior to NDBMS's, although that is
obviously not true for fatally flawed implementations like the ones we
have.

I agree on that a good NDBMS could be better than a bad SQL DBMS in
some circumstances. But these circumstances are a lot less frequent
than many people could think.

> The 'best' tool *for a given problem* is the
>one that best solves *that* problem.

The problem is that I am talking about theoretical computational
models and you are talking about concrete tools.

>> Your testimonial is irrelevant.
>
>Of course, since it doesn't go your way.

Testimonials don't make science.

>Of course, I must be a very bad and illiterate programmer, not educated
>enough to even have a clue about how to use a DBMS. This is of course
>the only possible explanation to the fact I observed.
>
>When facts comes in contradiction with theory, you can dismiss facts or
>revise the theory...

You have to revise the experimentation method first. Do you remember
cold fusion? :)

And yours is obviously flawed because you didn't use a truly RDBMS.

>Would you categorize SQL Server, Oracle and Postgres as 'SQL DBMS' or
>'RDBMS' ?

SQL DBMS of course.

> and in the first case could you be kind enough to tell us
>about existing RDBMS ?

They don't exist.

>Too bad you're so biased as to not even accept that
>there exists a whole world of applications outside RDBMS based apps, and
>that RDBMS are *not* the alpha and omega of application programming -
>just a pretty nice and useful *tool*.

At the present day, RDBMS's are (theoretically) the alpha and omega of
the computerized data management, but they were never tried seriously
(at practice). There are many people trying to dismiss the concept
basing in misconceptions (the most) and in very bad implementations of
the Relational Model.

>Have nice day !-)

You too.

Regards

Relevant Pages

  • Re: SQL
    ... >business and presentation rules in the applications. ... DBMS were created ... The fundamental purpose of a DataBase Management ... >Around a corruption of THE Relational Model. ...
    (comp.object)
  • Re: limit of lines?
    ... Agreed, but don't let database design influence OO design, the two are not ... > part of the business rules it is not part of the navigation. ... Navigation should not exceed the business rules otherwise the rules end up ...
    (borland.public.delphi.non-technical)
  • Re: Relational model versus object model
    ... > As far as concurrency is concerned, the DBMS is the logical place to ... > applications are reading and writing the data. ... >> over and over in our class interfaces. ... > business problem solutions. ...
    (comp.object)
  • Re: RMs Canonical database
    ... What, in your opinion, does belong in the database? ... Imagine that your database is used by multiple applications where ... why one should not include business rules in a db. ...
    (comp.databases.theory)
  • Re: OO vs. RDB challenge
    ... Or stating that a DBMS cannot relie on a DBMS to ... more explanations about why this has to do with the DBMS's business ... >>dont use a database can only handle presentation logic. ... an application has to enforce rules pertaining to its ...
    (comp.object)