[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