>If you are going to have a database that will be centralized for the company >and will have many different clients accessing it, I would tell them not to use >MySQL.
OK, though 5.0 makes it possible to write stored procs that protect clients from MySQL's gotchas, and that keep database-protecting validation where it belongs--on the server. PB ----- Original Message ----- From: Stormblade To: [EMAIL PROTECTED] Sent: Tuesday, April 20, 2004 8:35 AM Subject: Re: Gripe with MySQL On Tue, 20 Apr 2004 09:48:11 +0200 (CEST), Jochem van Dieten wrote: > Stormblade said: >> 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. > > Date fields allow invalid dates: 0000-00-00 > Trailing spaces are silently discarded (fixed in 5) > Decimal fields are silently truncated if the inserted value is too long > etc. > > http://sql-info.de/mysql/gotchas.html has a nice list. Thanks for the link. That's very informative. > >> 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. > > To some extend. It is not enforced that the parent record is unique, > which is a requirement with foreign keys according to the SQL spec. Aye but at least it doesn't allow me to add/delete if it'll create an orphan. >> Relying on clients for database integrity is a bad idea in my >> experience. -- > > Then you choose the wrong database. > > Jochem Well, choosing a database involves more than just not liking a particular approach. Their approach in this case only means that I would not recommend using MySQL for any large scale applications. Like the situation I described earlier. If you are going to have a database that will be centralized for the company and will have many different clients accessing it, I would tell them not to use MySQL. It would be a bad idea IMO. Not that it couldn't work of course. But for small projects it is find. It's cost effective and it does the job well. Like the project I'm currently working on. Just a small web site. Only one web app will be accessing the database and I wrote it. And I have another project coming up, similar in size that I will be using MySQL for as well. So it's not that I chose the "wrong" database. Just that I believe their design choices make the database the wrong choice for certain situations and applications. I would love to see MySQL add more features that allowed the database to do more of the work when it comes to integrity but until it does I simply will not use it for situations where that could be a problem. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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]
