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 -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com
signature.asc
Description: Digital signature
