Re: Data Layer architecture

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

Hi... we have a battle here! Well I am new to this development stuff (five ou
six years only) and I just want to give my humble opinion here.

I agree with Alfredo in alot of things, but I also think we should keep our
minds open to new ideas. I think there is no design solution that can be
called "the best solution for all your problens". The best solution is the
one you plan before building applications, it depends on the team experience,
it depends on the tools you can use, on the business details, enabled
hardware... so it is hard to discuss about the best development practice
sometimes you just have to do the thing even if you do not agree with the
design.

Well... please do not turn your wrath on me... it is just an opinion... I do
not have half the knowlege all of you around has... but one think I must say
THANKS A LOT I learned a lot with this post!!!

Sorry for my poor english... I am brazilian...

"Alfredo Novoa" wrote:

> 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, ... I readed several books about business rules and all of then say the ... >> 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)