Re: Data Layer architecture

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Tue, 26 Jul 2005 01:24:33 -0700, "Frans Bouma [C# MVP]"
<perseus.usenetNOSPAM@xxxxxxxxx> wrote:

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

Almost all have revision from the 00-ies.

> In that time, having
>distributed applications was a non-existing phenomenon.

Very wrong. Distributed applications are even older. Almost all
database books have chapters devoted to distributed DBMS. In fact
client/server is also a special case (the simplest) of distributed
system.

> Of course the
>rules were described to be inside the RDBMS, as the RDBMS was located
>on the mainframe / mini.

Wrong again. A distributed DBMS might have parts located in the PCs,
and you can build a network of federated DBMS's having DBMS's
installed on the client PCs.

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

All the reasons mentioned by the books still apply. It is still
foolish to implement the business rules in the applications.

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

They are in the elementary texts.

http://ioc.unesco.org/oceanteacher/resourcekit/Module2/Database/DBMS/advantages.html
http://db.cs.berkeley.edu/postmodern/lecs/dbprimer/sld011.htm

The most important argument in my opinion is that the development and
maintenance costs are reduced to a little fraction. A few lines of SQL
might be equivalent to many dozens of C# pages. C# is still a 3GL, and
SQL is an orders of magnitude more productive 4GL.

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

We could say the same about application programmers and the
consquences are evil. They break a very fundamental principle and
waste lots of resources in order to have a better position in the
company/organization.

If fact, to maximize the development and maintenance costs and to
create a big mess in which nobody else is able to find anything tends
to be very good for the programmers. The system often rewards
incompetence.

> Oh dear, I don't have a clue,

Absolutely!

Fortunately it has an easy solution.

I recomend this book to you:

http://www.amazon.com/exec/obidos/tg/detail/-/0321197844/002-4704546-5588825?v=glance

It was published in 2003.

I also strongly recomend this complementary website:

www.dbdebunk.com

> Business rules aren't the same as integrity rules.

What are they then?

I readed several books about business rules and all of then say the
same.

http://www.amazon.com/exec/obidos/tg/detail/-/0201708507?v=glance
http://www.amazon.com/exec/obidos/tg/detail/-/0471412937/002-4704546-5588825
http://www.amazon.com/exec/obidos/ASIN/0201788934/002-4704546-5588825

It is evident again that you don't have a clue on what you talk.

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

You are regurgiting nonsenses you readed somewhere without thinking.

It does not make any sense. DBMSs are computationally complete, you
might program any behavior you want with them, and thanks to the very
high level nature of the relational languages, it would take orders of
magnitude less effort than to use a comparatively low level procedural
language like C#.

Try to duplicate the behavior of a view that joins three tables and
has a multi-attribute "group by" clause using C#.

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

Definitely you don't have a clue!

Any rookie knows that an Information System that uses a DBMS to
decouple the applications from the database has more than one tier.

>> 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 are spreading a lot of misinformation that might harm many
readers.

>Because you want to show the world you're the
>only person who knows it all?

Any competent developer knows all or almost all what I said.

>
> the relational model doesn't define predicate logic

No, I said that it is directly based in predicate logic.

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

I already showed to you that the structural component is only one of
the three components of any database model.

This is like to talk with a wall.

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

Presentation functionality might be very complex and important. In
many cases presentation functionality is the biggest part of the work
by far. You should not fear the proper use of a DBMS so much.

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

Administration is more than programming. Programming is only one of
the skills a DBA must have.

> Writing procedural code in SQL is stupid also.

What is stupid is to write procedural code when it is possible to use
declarative code, which is orders of magnitude more productive.

> BL code is procedural by nature, not set-oriented.

The biggest nonsense you said until now.

Business rules are declarative by nature.

See this:

Best practices
Declarative: A business rule is a statement of truth about an
organization. It is an attempt to describe the operations of an
organization, not an attempt to prescribe how an organization should
operate. This is why business rules are said to be discovered or
observed and not created.

http://en.wikipedia.org/wiki/Business_rules

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

You might have all your business logic on the DBMS and to have all the
physical tiers and distributed servers you want. Again you don't have
a clue on what you talk about.

There are many solutions: message servers, federated DBMSs, relational
middlewares, one server per database, etc, etc.

You have a LOT to learn


Regards
.

Relevant Pages

  • Re: Data Layer architecture
    ... >>database theory are rather old, say, the 80-ies. ... A distributed DBMS might have parts located in the PCs, ... > foolish to implement the business rules in the applications. ... >>> Server is only an special kind of distributed system. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: SQL
    ... The enforcement of business rules could happen in another ... user interface to the low-level code that talks to the database, ... >>other business rules, than the DBMS. ...
    (comp.object)
  • Re: Searching OO Associations with RDBMS Persistence Models
    ... RDB is about data structure an OO is about ... The DBMS must store the data, manage the queries, and enforce some integrity rules. ... We don't want the business rules being done by the database. ...
    (comp.object)
  • Re: Check out the IDC paper on U2
    ... when we sold our UniData/D3 application we sold the database as ... I never even thought of the size of the dbms in this. ... embedded DBMS and SQL Server not. ... and many open source projects focus on the idea of embedding ...
    (comp.databases.pick)
  • Re: What so special about PostgreSQL and other RDBMS?
    ... >abstraction layer that can use alternative database backends, ... putting a strain on the database (and with high-end commercial RDBMS ... And, of course, you will be using a high-end server with redundancy ... to bring it or the DBMS off-line. ...
    (comp.lang.php)