It's best practice to write unit tests for all your code, with calculated data to show what you expect. That data then gets compared to what is actually generated and if there is a discrepency, then you have a bug somewhere.
But the reason modern databases have foreign keys, primary keys, not-nulls, check constraints and data-metadata (char(5), INT, BIGINT, etc) is to prevent bad data from going in.. If no exception is thrown because you are trying to put a BIGINT into an INT, then why throw one if you try to insert a NULL into a NOT-NULL column (assuming no DEFAULT is present)? Or what about foreign keys? Why not just quietly fail if a fk-constraint is violated?
Go even farther. Say your SQL is just incorrect ("INSETR IN TO " instead of "INSERT INTO"). What if MySQL didn't throw an exception back to your PERL DBI or Java JDBC connection? After all, it's up to the developer to make sure their SQL syntax is correct.
The database has all sorts of constraints that can be applied to your data model. They should all have the same behaviour when violated.
David
Mike Johnson wrote:
From: David Griffiths [mailto:[EMAIL PROTECTED]
MySQL really should throw an exception/error rather than just quietly trim your data and accept it. When your data is critical, and your business depends on it, you can't have bad data quietly going into the database.
Someone correct me if I'm wrong, but isn't it considered best practice to validate data before it gets to the database?
I can't seem to find a source for this after a quick search on Google, though...
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
