On Mon, 19 Apr 2004 20:17:38 -0700 (PDT), Marc Slemko wrote: > On Mon, 19 Apr 2004, Stormblade wrote: > >> Ok. Love MySQL and I will be using it for my personal use and recommending >> it to clients as a lower cost alternative. I've only been using it for a >> very short time but there one major gripe I have with it and I believe it's >> just a design thing. >> >> MySQL seems to put the burden of error checking and such on the client. >> >> - All fields have a default value even when I don't tell it to? >> - Allow Null will only result in an error if I explicitly try to set the >> field to null. >> >> These are the two things that I really dislike. I think it's a poor design >> to rely on clients only for error checking. MySQL supports foreign keys. >> This is good because the database handles referential integrity. But it >> shouldn't stop there. I should also be able to tell the database not to >> allow a field to be empty/null and it should not put anything in there that >> I have not told it to. > > Yup, it is a bad idea, and thankfully it seems to be slowly improving > as more and more people try to use mysql as a more serious database. > > However, keep in mind that it is not an adhoc arbitrary decision, > but it based on a very fundamental traditional mysql design fundamental: > not to support transactions because they aren't required most of > the time, or so the claim goes. While there are a few mysql storage > engines now that do support transactions, and at least one is in > widespread use, this history explains why it is the way it is. > > If you don't support transactions, what do you do if you are running > a statement that updates multiple rows and get an error with one > row? If you just abort the whole statement, it is really ugly since > then you leave the statement half executed. If you try to be able > to undo the entire statement, it is really ugly because without > transactions you are unlikely to have the backend support for doing > that or for avoiding dirty reads, etc.... since that is one of the > fundamentals of what a transaction is. So ... you bravely soldier > on.
Ah this makes sense. Although for me I wouldn't have done it this way even if I hadn't planned on supporting transactions but that is because of my personality and the type of programming I usually did. My concerns were almost always with reliability, maintainability. Sure speed was a concern but not as much as the other two. But I can understand (If not agree with) the decision at least. Speed was more of a concern and with them not supporting transactions this makes sense. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Stormblade (Shaolin Code Warrior) Software Developer (15+ Years Programming exp.) My System: http://www.anandtech.com/mysystemrig.html?rigid=1683 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
