This complicates the database. This discussion has come up hundreds of
times on this list.
NULL/NOT-NULL is a basic check, and by saying NOTNULL, you're telling
mysql to fail it.
Same thing with Syntax checks, they're just that.
The different INT fields are provided to make the database more efficient
(and compact), as
the byte requirements for each are different. It is up to the developer to
use them correctly.
The database (fields in general) is not expected to provide workflow, it
is merely a repository for
objects dictated by the workflow. The application front-ending the
database should always handle
exceptions correctly.
When you add all of this crap to a database, you get MSSQL. All that, and
the glorious deadlocks
that make it the marvelous workhorse it is.
David Griffiths <[EMAIL PROTECTED]>
05/25/2004 04:04 PM
To: [EMAIL PROTECTED]
cc:
Subject: Re: Very Strange data corruption
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]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
