Everybody should remember as well, if you run rm -rf /*.* on your server you will delete everything from your server, but linux will stay running. Even though that's not documented either.
If you use a client like PHPMyadmin or one of the other 80 million that are around you won't have to worry about error checking because they have already done it for you. Now as far as your clients/customers, if you don't have error checking in yourself, that's your problem not mysql's problem. Donny > -----Original Message----- > From: Michael McTernan [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 20, 2004 9:04 AM > To: Stormblade > Cc: [EMAIL PROTECTED] > Subject: RE: Gripe with MySQL > > Hi, > > ENUM columns can also trip you up if you insert a value outside of the > ENUM; > an empty string is inserted instead. This is documented behaviour > (mysql.com seems to be going slowly though, so can't dig a reference right > now), even if it is undesired in some cases. > > Thanks, > > Mike > > > -----Original Message----- > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Stormblade > > Sent: 20 April 2004 01:42 > > To: [EMAIL PROTECTED] > > Subject: Gripe with MySQL > > > > > > 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. > > > > One scenario I can think of is this. My company uses MySQL as it's > > database. Different departments implement various interfaces to this > > database. All it would take is ONE client to have ONE bad SQL and > although > > the insert works (Thanks to default values being put in) the data is not > > valid. > > > > I've only been working with MySQL for a little bit so this is > > just my first > > impressions. I'll be very happy to be told I'm wrong or that > > future updates > > (5.0 perhaps) will change some of the things I've mentioned. > > > > Relying on clients for database integrity is a bad idea in my > experience. > > -- > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > 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] > > > > > > > > > -- > 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]
