mengpg@engene.se (Marcus Engene) writes:
> Bill Dika wrote:
>> Thanks Nikola.
>> Your explanation of layering was helpful. The consensus from you
>> experts seems to be that I should keep the business rules and logic
>> out of the database, so I will do that.
>
> Just a small note here. I've seen projects where exactly everything is
> put into the application, including validations of data and such. The
> db was basically a bit bucket with indexes. That turned out to be a
> complete disaster. It's much harder to keep track of all validations
> in the java/whatever code than letting the db do this for you.
>
> It's very easy to add constraints, foreign keys and such to a db and
> that should always be done. There are no excuse what so ever not
> to. Everything you can validate (via CHECK(), fk, trigger, whatever)
> do it. A db with errors is a nightmare to patch. It's much better to
> have the application tell you it won't do an operation and you do a
> fix rather than the application inserting errors silently.
>
> Ok, this was the introductionary chapter of any db book. Sorry about
> that. ;-)
There are multiple sorts of "business logic"; this is a pretty eminent
example.
I'd say that "yeah, having constraints, foreign keys, and such would
seem good here." Starting with a database schema that prevents the
data from getting invisibly unclean seems a good thing.
The "business logic" that's really in question is of where/how to
perform the tax calculations. It seems to me that "inside the DBMS"
is quite likely not to be the right answer.
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://www.ntlug.org/~cbbrowne/linuxxian.html
"In most countries selling harmful things like drugs is punishable.
Then how come people can sell Microsoft software and go unpunished?"
-- <hasku@rost.abo.fi> Hasse Skrifvars
