[Chicago] Random book notes

Peter Fein pfein at pobox.com
Fri May 5 20:04:17 CEST 2006


CONSTRAINTs, I suppose.  CHECK, UNIQUE (for non-PK), partial indexes, etc.

I don't use ORMs, but usually use a mix of application and database validation 
techniques.  Some constraints (UNIQUE, say) cannot be implemented by the 
application (b/c of transaction semantics).  Others (data integrity for an 
individual row) are often better done in the app, where you have a 
friendlier/more powerful language to work in.

That being said, I'll occasionally implement a particular validator at *both* 
levels - a 'weak' check in the DB and a 'strong' check in the app.  While the 
DB check is theoretically unnecessary, it gives protection against app-level 
bugs - doing so has prevented bad data from making it into my tables on more 
than one occasion.

It all depends on how much you care about data correctness/purity.  I care 
quite a lot...

On Friday 05 May 2006 11:23 am, Jess Balint wrote:
> What kind of data sanity checking are you talking about? Application-level
> checks are usually done with input-level validation and relationships are
> check by foreign key constraints in the db.
>
> -----Original Message-----
> From: chicago-bounces at python.org [mailto:chicago-bounces at python.org] On
> Behalf Of Martin Maney
>
> one of the things I find disappointing about Django's ORM (and others):
> they do too much of the data sanity checking only in the ORM/framework,
> and treat the database mostly as a dumb filesystem to hold their data.)
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> http://mail.python.org/mailman/listinfo/chicago

-- 
Peter Fein                                                     pfein at pobox.com
773-575-0694                                      Jabber: peter.fein at gmail.com
http://www.pobox.com/~pfein/                     irc://irc.freenode.net/#chipy


More information about the Chicago mailing list