On Wed, Jan 31, 2007 at 02:54:01PM -0900, Joshua J. Kugler wrote:
In that same document, they give the reason for doing so:
"The reason for using the preceding rules in non-strict mode is that we can't
check these conditions until the statement has begun executing. We can't just
roll back if we encounter a problem after updating a few rows, because the
storage engine may not support rollback. The option of terminating the
statement is not that good; in this case, the update would be ???half done,???
which is probably the worst possible scenario. In this case, it's better
to ???do the best you can??? and then continue as if nothing happened."
I'm sorry, but "our database can't always handle transactions" is not a
valid excuse for allowing bogus data.
And also provide a way (from 5.0.2 on) of enabling the "traditional" strict
behavior. So, with one config option, MySQL will now reject all invalid data
(providing you're using transactional engines, for reasons described above).
Please read this:
http://developers.slashdot.org/comments.pl?sid=219722&cid=17824340
Now, tell me seriously that it is valid for any database to treat data
integrity as an *optional* feature.
As for your assertion that those who spec MySQL don't know what they're doing,
I do believe the techs that work at MySQL are some pretty sharp cookies. I
think they know what they're doing, and I'm sure they know how to either
enable the above config option, or check their data before it gets to their
database.
So what? Microsoft has some absolutely brilliant architects, engineers
and developers. They are still polishing a turd.
All products have their gotchas. One should be familiar with the product
against which one is writing, or weird things will bite you down the road.
Boy, that's an understatement.
Regards,
-Roberto