Re: You have my sympathies

nobody has mentioned normalising functions. duplication of functionality is just as bad as duplication of data and has all of the same problems.

take the example where you have payments coming in from different sources such as direct debits and cash payments. there may be more on some systems but at least two sources is quite typical. systems that are hacked up often duplicate business rules for both sources of payments. this is fine when the systems are first put in but then the business rules change. all of the original programmers have left and someone else amends the programs. they don't remember to amend both the places where the business rules exist and the functionality is corrupted. of course this corrupts the data as well. i have seen this happen a number of times.

one of the best reasons for putting functionality on the database is that the rules exist in one place.

everyone hates using proprietary languages but pl/sql has been around for a long time and it isn't going away. if you really want to use C++ you can still call it from the database. one of the problems with C++ is the lack of dynamic linking (the implementation of polymorphism is very half hearted) that results in version problems. anything on the database will be linked dynamically. the person who wrote the original comment should understand about binding data to functions. If you put business rules in front end C++ then you'll have duplication of data types as well.

another way to think about this problem is how do you reduce duplication of metadata? it might not change as quickly as data stored on tables but it does change and it can become corrupt.

Dave P.

Nuno Souto <nsouto_at_nsw.bigpond.net.au.nospam> wrote in message news:38d0af13.6141408_at_news-server...
> On Wed, 15 Mar 2000 19:02:12 -0000, "Jonathan Lewis"
> <jonathan_at_jlcomp.demon.co.uk> wrote:
>
> >
> >Still taking the position of the devil's advocate
> >here - this bit of 'data integrity' is not an inherent
> >requirement of the data when viewed from
> >the perspective of the database
>
> Oh yes it is! Data is stored in the database, which is assigned to
> take care of its integrity not only in the physical level but also
> logical.
>
> >
> >Arguably the purpose of the database is to
> >ensure that if I put in 1 customer and 5 orders
> >they all go in or nothing goes in, and if I join
> >two tables on a given column then the
> >results appear as expected.
>
> And to ensure that if you put a new customer John Doe and 5 orders
> from him, they don't end up (part or whole) assigned to customer Betty
> Fonebone.
>
> Which is possible if you don't put that rule in the database and leave
> it to a coder to "not forget to do"... The database will in that case
> religiously save 1 customer and 5 orders. But all mixed up.
>
> Fully recoverable, though... ;-)
>
> >
> >The fact that the business layer will only
> >allow orders to go in if a related customer
> >exists is not a piece of information that
> >the database needs to know.
>
> Oh yes it is. That's got nothing to do with business rules and
> everything to do with logical data integrity rules. Please read on
> for a true business rule coming up.
>
> >
> >(And, of course, if the only code to insert
> >and delete data comes from the business
> >layer,
>
>
> Says who? Better yet: ensures who? That is the whole reason for
> putting logical data integrity rules in the database: NOBODY can
> ensure to you that is the case UNLESS the rule lives in the database.
>
>
> > (as it no doubt will ;)
>
>
> Yeah, right! :-) Tell that to the guys who had to maintain old
> flat file-based applications...
>
>
> >then the business
> >rules about customers will say that a
> >customer may only be removed from the
> >business if they have placed no orders.
>
>
> Not necessarily. The data integrity rules may say that, and the
> database should enforce it.
>
> But the business rules should instead say: a customer with no orders
> should receive heaps of advertising.
>
> A perfect example where a business rule is not necessary in the
> database.
>
> It's a functional rule, not a data integrity rule. Therefore it
> BELONGS in the business layer. The data integrity rule IS for the
> database.
>
>
> >So the database does not need to
> >duplicate the code built in to the
> >business layer).
>
> Correct. The problem is separating the rules into what is data
> integrity rule and what is a functional rule.
>
> Spread the rules into the layer that executes them better and safer
> and you got the perfect solution.
>
> And a lot less network load. Which allows you to plonk the business
> layer away from the data layer and the presentation layer. More
> flexibility, better final system.
>
>
> Don't even try to do that with a model that says all rules belong in
> the business layer. That is analogous to going back to the old
> mainframe application days, where the thin client was the block-mode
> terminal, the application layer was that horrible lump of Cobol code
> that nobody did understand and the data was amorphous flat filed and
> (in 99% of the cases) totally corrupt in the logical sense.
>
> In fact, if you look at the 3-tier commercial applications out there
> that do just this, guess what? They are ALL, without exception,
> straight ports of applications that used to run in mainframes against
> flat files. Funny that, ain't it? <d&r>
>
> With the worse problem now that the connection between the application
> server and the data server is not shared memory but relatively s-l-o-w
> net wire.
>
> Please read my other reply, it complements this one as well as
> vicky-the-versa.
>
>
> Cheers
> Nuno Souto
> nsouto_at_nsw.bigpond.net.au.nospam
> http://www.users.bigpond.net.au/the_Den/index.html
Received on Sat Mar 18 2000 - 00:00:00 CST