Re: Data validation

[prev] [thread] [next] [Date index for 2004/11/10]

Edward J. Sabol writes:
 > > The docs imply that validate_column_values() is the right place to do
 > > this validation, but the implementation makes this rather messy. How do
 > > other people do validation?
 > 
 > FWIW, I use a MVC (Model-View-Controller) design pattern. My CDBI classes are
 > Models in that pattern, and I put data validation in their respective
 > Controller classes, IMHO, since it's the Controller class that interacts with
 > the user and creates and modifies each Model class. I currently use my own
 > validation module which heavily extends Params::Validate. If I had to do it
 > over again, I'd probably use Data::FormValidator.

A related question for everyone.  (BTW, if this is too off-topic for
CDBI, what forums are appropriate?  I'm familiar with the c2 wiki, but
it's often over-abstract.)

Why not perform all -- or most -- data validation at the RDBMS level?
For example, as most of you are aware, PostgreSQL provides a rich set
of features for programming at the database server level, including a
Perl interpreter.  You can create custom datatypes, constraints,
triggers, rules, etc.

For web-based applications, there are many levels at which data
validation can occur, from high to low:
* the browser;
* the portion of the web application that's running on the web server,
either in the Model (e.g., CDBI constraints and/or triggers) or the
Controller (Data::FormValidator, CGI::FormBuilder, etc.); or
* the RDBMS.

Pros and cons of data validation at the RDBMS level:

Pros:
+ Model can be implemented entirely in the lowest level, and
Controller code is less cluttered by validation logic.

+ Prevents invalid data more closely to the level at which data is
actually stored.  Suppose you or a colleague modify data in the
database via a method that bypasses your Controller, e.g., an INSERT
or UPDATE is issued via the RDBMS's interactive terminal ('psql' for
PostgreSQL).  If your data validation does not occur at the database
level, you may (and likely will) end up with invalid data in the
database.  A constraint in the database would have prevented this.

Cons:
- Makes porting to another database platform more difficult.
Counter: This con can be applied to any level, which seems to cheapen
the argument.  E.g.: Data validation at the Model (CDBI) level makes
porting to another database abstraction platform more difficult.  Data
validation at the Controller level makes porting to another language
platform more difficult.  Data validation at the browser level makes
porting to another browser more difficult.

- Untainting, SQL injection attack prevention, etc. still must be
handled prior to sending data to the RDBMS.

- Places more load on the database server, as it's doing more than
just read/writes.
Counter: This con can be argued at any level.  E.g.: Data validation
at the Model (CDBI) or Controller level places more load on the web
server.  Data validation at the browser level places more load on the
client box.

Opinions?  Other pros and cons?

Kings