Re: OOP - a question about database access

"Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message news:bogabu$1dmsv4$1_at_ID-152540.news.uni-berlin.de...
> [snip]
> > Why would a database be a good place to validate text from an
> > input field, wouldn't it make everyone's life a lot easier if data were
> > validated before making a write to a DB?
>
> Well, just because you typically *have to* do it in three places
>
> 1. First in the client (JavaScript)
> 2. Second in the middle tier (ASP.NET, Java, etc. )
> 3. Have it as a constraint defined in the database.
>
> Any solution less than all three is pretty much guaranteed to be a bad
> solution

I'd don't care how many tiers enforce integrity constraints of various kinds, but I don't see why in the 21st century we still seem to think we have to *hand* code the checks into all those tiers. Since the rules do need to be enforced in the database, and since we have to interrogate the database for the data anyway, we ought to expect it to be able to deliver the
constraints along with all the other metadata (e.g. data type, nullability, or whatever) at run-time. Instead of constantly, everywhere, for all time, re-implementing the same checks (and ensuring simultaneous and comprehensive rollout of all changes in those myriad implementations, forever) we need to have a way to make the various tiers dynamically configure themselves from the database constraints at run-time. I don't care if it's done with code-generators or APIs or "constraint servers" or what, but I sure as heck want the enforcement fully automated and hidden from view, and I want the database alone to drive it.

I know I'm not going to see any such standards for a very long time, so for now I'd be happy to see more people recognize that it's madness to approach data validation the way we're doing it now--piecemeal, by hand, with no assurance of consistency.

[snip]

Roy Hann Received on Fri Nov 07 2003 - 16:51:15 CET