So it seems that we are all in agreement.

1. It is best that the system is designed to avoid these issues in the first place. This is similar to every dog owner removing their dog droppings.

2. Sometimes you find youself in the poo. In this case you need to a) Clean the data & b) Change the system to prevent it happening again.

There is often a third part to this issue. One that the "Hey I would just write a perfect database" folks may be ignoring. What happens if your perfect DB now starts to reject these dirty rows? Often systems with poor error handling in the DB also have poor error handling in the App tier.

If one insert in a more complex process fails, will it be contained in a transaction to ensure everything fails cleanly? (Most likely not, few developers use transactions, many prefer WITH (NOLOCK) hints).

If the app does correctly use transactions, will it check the return code from SQL (often not)

If it does check return codes will it present some kind of error to the end-user in a way the User can correct the issue?

And sometimes the User is already gone. eg: Batch systems, Real-Time capture ie: RFID, CEP, Process control, Toll Booth & Speeding Cameras etc.

In short it may be cheap to fix the DB, but you occasionally open the door to a huge rectification project. One that will take a long time to get resourced & funded. Which is why, you will often hear IT mgrs request you to clean the huge mess their DB is in now, & maybe write some scans they can run periodicly, till they get budget to do it right.

Or to go with the dog analogy. If you've just fallen in the sewer. You need to priortise. Perhaps wipe it from your eyes. Shake off the big chunks. And then figure out how to sort out the rest. Having someone nearby tell you, that they wouldn't have fallen in the sewer, is rather redundant.