On Wed, 18 Jul 2007, Kee Hinckley wrote:
2. Biz-logic
Things you've specified for you application. E.g. We need an email address
for all new accounts
3. DB
Constraints specific to the database and object model. E.g. Field length,
required fields.
The distinction between these two is pretty artificial. To give a simple
example, think of most foreign key uses. If I have a table "Post" and a
table "User", and a foreign key such that Post must have a valid user_id
from User, that's business logic. It says that "posts must be associated
with a valid user".
If SQL DBMS products didn't suck quite so much, I'd be able to say "posts
must be associated with user who is not marked as deleted".
Basically, your distinction for #3 seems to be "stuff I can trivially
define with the SQL implementation I happen to be using".
Having this sort of stuff in the DBMS is _in theory_ a good thing, as it
actually ensures that the data you store is only valid data, according to
the rules you've defined.
Unfortunately, in practice, doing this becomes very cumbersome. My take on
this is that it's the lack of sophisticated declarative constraints that
makes this so. Using triggers and stored procs is a bit gross, and I think
many developers perceive it as "too opaque".
Another problem is that translating the errors the DBMS gives you into
something user-friendly can be a pain, and there's not a good standardized
way of passing DBMS-side validation errors back to Perl code, so you get a
string and have to parse it, which feels horribly fragile. Also, that the
DBMS will generally blow up on the first constraint that's violated,
rather than giving you a set of errors ("first name is required",
"password must be >6 characters").
Personally, I'd much rather define my business logic using a rich
declarative constraint language rather than in app code. As mentioned in
another message, Pg does make this a little easier, since declaring custom
types based on built-ins isn't really hard, so you can have a type like
"email_address", and say that it's a string which matches "[EMAIL PROTECTED]",
which is a small step towards declarative business logic constraints.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
