Re: Data Layer architecture

Alfredo Novoa wrote:

> On Mon, 25 Jul 2005 01:01:30 -0700, "Frans Bouma [C# MVP]"
> <perseus.usenetNOSPAM@xxxxxxxxx> wrote:
>
> >> But it is a very expensive learning way. Everyone with a clue on
> data >> management theory knows that the business logic must be
> ensured by the >> DBMS and not by the applications (this is taught in
> the first week of >> any serious database course).
> >
> > Hmm, then my serious db courses at the uni weren't very 'serious'
> > then!
>
> If you don't know that I am afraid they were a little disaster.
> Nothing rare, by the way.

Ah, a 'holier than thou'-person.

> > NO law states that BL has to be IN the DBMS.
>
> No law, but it is a well stablished principle in the database
> community. You might check the first chapter of any popular
> introductory book like Date, Elmasri & Navathe, Korth & Silverschatz,
> etc.

I think you confuse some things. First of all, a lot of books about
database theory are rather old, say, the 80-ies. In that time, having
distributed applications was a non-existing phenomenon. Of course the
rules were described to be inside the RDBMS, as the RDBMS was located
on the mainframe / mini.

However times changed. In a distributed environment, business rules
aren't necessarily placed inside the RDBMS, as there's no real need to
do that.

I haven't heard any argument in favor of doing so from you yet.

Oh, and the 'database community' is largely formed by DBA's. Of course
they don't want to give up their role as BL developer as it would
degrade their position in the company/organisation.

> > BL is a data-consuming tier, not part of the relational model. If
> > you pick up a book by Nijssen or Halpin, or Yourdon for that
> > matter, you'll learn that relational theory, e.g. the schema setup
> > in your DBMS, is not a theory which states anything about business
> > rules.
>
> None of them is an expert on relational theory.
>
> You should read Codd, Date or Fabian Pascal to get a clue. Business
> rules support is one of the main components of any database model.

Oh dear, I don't have a clue, according to mr. Alfredo 'Holier than
thou' Novoa.

Business rules aren't the same as integrity rules. If you would come
off your high horse, you'd learn I do agree with placing data-integrity
rules inside the database. Though it's something else to place behavior
in the database as well. After all, a relational model defines static
rules, but not behavior.

> In a 1981 paper entitled "Data Models in Database Management" Codd
> defined a data model to consist of a combination of three components:

in 1981, the only computing model available was the mainframe/mini
setup: large box in the corner/basement, and terminals. There was no
other solution than that. No n-tier development, just a single tier,
located on the server.

> 1. A collection of data object types, which form the basic building
> blocks for any database that conforms to the model;
>
> 2. A collection of general integrity rules (business rules), which
> constraint the set of occurrences of those object types that can
> legally appear in any such database;

BL rules != integrity rules!

> 3. A collection of operators, which can be applied to such object
> occurrences for retrieval and other purposes

which you can also define as commands to the RDBMS. After all, code
INSIDE the rdbms, is located there physically but is ran AGAINST the
RDBMS engine the same way as external code is ran against it.

> Source:
>
> http://www.amazon.com/exec/obidos/tg/detail/-/0201612941?v=glance
>
> > It only gives
> > context to the data its format it defines, no logic whatsoever.
>
> The Relational Model is nothing but a direct application of set theory
> and predicate logic to the data management field. If you don't know
> that then you know practically nothing about it.

Dear Alfredo Novoa, why do you even take the time to lecture me about
relational model theory? Because you want to show the world you're the
only person who knows it all?

the relational model doesn't define predicate logic, it defines
relations between attributes and relationships between relations.

> Codd's genial insigth was to use the mathematical logic for the
> business logic. The Relational Model is a small branch of mathematical
> logic.

the relational model offers you the structure but not the behavior.

geezz.. this is like explaining OO to a C-fetisjist.

> >> Applications must be the presentation layer of an Information
> System >> (something known since the 60's), and we should keep away
> from all the >> business objects trade media garbage.
> >
> > One researcher once made a list of how many client-server
> > architectures there were, he came to 7 if I'm not mistaken. Your
> > proposed setup is one of them, but far from the only one.
>
> My proposed "setup" might have infinite architectural forms. Client
> Server is only an special kind of distributed system. A distributed
> DBMS composed by zillions of servers still is a single DBMS.

No, your only possible setup is: everything in the RDBMS and on top of
that a thin client with solely presentation functionality. Any business
rule is in teh RDBMS after all.

> > What you suggest is typically a big-iron box in the basement, and
> > thin clients connecting to it, where all the software is written by
> > DBA's.
>
> All the business logic code is written by DBA's or database
> programmers, but all presentation logic still needs to be written by
> application programmers.

aha, all business logic is written by DBA's, there we have the
background of your story. Check out the 'A' in DBA. It doesn't stand
for progrAmmer.

Writing procedural code in SQL is stupid also. SQL is a set-oriented
language and interpreted (as the statements by themselves are handled
by optimized code). So writing procedural BL code in SQL is a paradigm
clash between prodecural code and set-oriented code.

BL code is procedural by nature, not set-oriented. This is also why BL
code is better off in its own environment. The 'distribution of
concerns' is then also done in a better way, as BL code consumes, and
the rdbms delivers.

After all, your BL code written in SQL statements is ran ON TOP of
your relational model anyway.

> > I hope I don't have to drop the word 'scalability' on you.
>
> Scalability has nothing to do with this. There are many ways to scale
> a well designed Information System where all the business logic is
> ensured by the DBMS.

If you have an E10000 with your large oracle db on it, and because you
store all your logic inside that oracle instance as well, the server
needs expanding, you have more trouble than when your middle tier with
your BL needs expanding, as you then just place a tiny new server into
your BL sever farm and everything is OK.

But I disgress. You think you know it all, we're stupid, you're not.
Well, Alfredo Novoa, have fun.

FB


--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
.

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: No knowledge of the database?
    ... No, the business layer is the system logic, and it is always different ... a botched ad-hoc DBMS that expose pointers to users and manage the ... >> have a clue of what The Relational Model really is. ... RDBMS are (more or less, ...
    (comp.object)
  • Re: Ms Access 2003
    ... employees to build a database application or use their department budget to ... I find that some businesses will pay, ... a small business which employs five consultants. ... when I was a corporate Access developer for a little more than a year. ...
    (comp.databases.ms-access)
  • Re: polymorphism (was: Poly Couples)
    ... but this is not really "business software"... ... Most of such applications are built as a combination of ... database with flat files or a different RDBMS vendor?" ... couldn't care less if I do it in using structured programming or OOP ...
    (comp.object)
  • Re: How should I generate a primary key?
    ... Obviously the designer did not get all of the business rules from the ... Should the database ... A Work Order records the transaction of a truck service at a given ... This has got nothing to do with bad design, it is about the developer trying ...
    (comp.databases)