Let me just say it flat-out right at the start: Most of the validation your application is engaged in - is detrimental to your business, your UX and to common sense.
I stumbled across this realization quite recently, while working on a consumer-facing web application that probably had one of the more intricate data models I had to contend with.
The problem with intricate data, is that sometimes it comes incomplete, and sometimes has a wrong value that is not really wrong. For example: You might write down your phone number with dashes, when an application is expecting only numerics. These inner rules for your data are sometimes so arbitrary, that people within your organization can't even remember them.
The reason for this is that the database is dictating the allowed data formatting and data-object types, and this authority trickles into the UI.
I found that the only places I would ever possibly need real, hard validation - would be at the gates: during registration and login. Almost all other data will be better off checked, sanitized, set to default or null values if necessary, but never EVER returned to the user as a list of little red tooltips over the fields they "failed to fill".
Back in the day, the pattern of submitting a form and then re-displaying it if the database rejected it was very common - Today, however, users expect to be assisted by the application, for example: see a "New File" label if they didn't set a 'filename'. This expectation is something that isn't going away. Users demand (and should receive) a smooth experience, devoid of the pain of rejection.
I have found that a proper editing mechanism, with the proper visual feedback, has an infinitely better UX value than traditional validation. Our users may sometimes give us "wrong" data, but we sure as hell need to be able to handle it, not bitch about it.
The use of sanitation function rather than validation functions just seems like good UX to me. Keep your database schema out of your user's way. It's your problem, not theirs.