Bill Dika wrote:
Hi,

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

Best regards,
Marcus

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

mengpg (AT) engene (DOT) se (Marcus Engene) writes:
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 (AT) rost (DOT) abo.fi> Hasse Skrifvars

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend