[DUG] Stored procedures and business logic

[Karl at Work]

Neven wrote:
> b) Because the DB Server enforces the rules you have to have the UI
> guiding the user otherwise its a 'chuck at the db and see
> what happens'
> UI (ughh). if you do this then you have duplication in business logic
> (in the ui and the db) and therefore the inevitability of errors

What about foreign keys and unique indices?  Or database constraints?  To
push your statement to its logical conclusion, such things could all be
checked at the UI stage and they could be left out of the db entirely.
Personally, I think it's perfectly reasonable to have stored procedures (and
triggers) do similar checks on data validity to ensure that no code slips
ever permit crap into the database, which it seems to me was what Kurt was
advocating.  So you might end up duplicating some logic at the front and
back ends, but not to cause errors - to catch them.  Just like foreign key,
unique index and other constraints, stored procedures to do referential
checks on data validity are a safety net.

Where does referential integrity end and business logic begin anyway?

Cheers,
Carl