On Sun, 2007-06-03 at 22:54 +0200, Alexander Staubo wrote:
> I agree with you and I don't; as it stands now, it's too hard to
> implement validation in the database alone, for the reasons I stated
> earlier. But I would love for it to be possible, so that I can be sure
> that not even plain SQL can screw up the data.
You're blurring the line between an RDBMS and an application.
Applications errors and database errors do not have a one-to-one
mapping, although they do usually overlap.
There are times when one database error maps onto several possible
user-level errors; and when many database errors map onto the same
user-level error; and when one database error does not cause any
user-level error; and when something that is a user-level error might
not have a matching constraint in the database at all. Trying to equate
the two concepts is a bad idea.
The application has much more information about the user and the context
of the error that the database shouldn't have. For instance, the
language that the user speaks might affect the error message. Or, there
may be two possible user interface actions that result in the same
constaint violation. For instance if you have a two-column unique
constraint, perhaps there is one interface to change one column and one
another. But you might want to return a different error to the user that
makes sense in the context of which value they tried to change.
A database error doesn't even always need to be propogated back to the
user. If so, there would be no need for SAVEPOINTs and nobody would use
ISOLATION LEVEL SERIALIZABLE (not directly related to constraints, but
can cause an error just the same).
Some user errors don't have a corresponding database constriant at all.
For instance, how about a "re-type your password here" field? That
should cause an error if it doesn't match the "password" field, but the
database would have no matching constraint.
Regards,
Jeff Davis
