--- Original Message --- From: "Stormblade" <[EMAIL PROTECTED]> To: Donny Simonton <[EMAIL PROTECTED]> Cc: Sent: Tue, 20 Apr 2004 12:59:58 -0400 Subject: RE: Gripe with MySQL
> On Tue, 20 Apr 2004 11:37:12 -0500, Donny Simonton wrote: > 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 > One clarification. Database checking does not eliminate the need for client error checking. The two of these things have nothing to do with each other. The database should allow for database protecting checks as it knows nothing and shouldn't know anything about the client. Whether the client performs their own error checking or not is irrelevant. Obviously this is, as I mentioned, a design thing and not everyone will agree on a design. I prefer the server to allow a database administration to setup checks to help ensure that data is going in as was intended. The database administrator in many companies have nothing to do with writing the clients or the SQL that accesses the database. There are some checks that I feel are better located on the server and there are some that are better located at the client end. When I tell a field that it should not be blank. I don't mean for the database to take it upon itself to ensure that it's never ever blank. If a record comes in to a server, that server should include a way to tell whether that record is invalid according to the server's specifications. This is not a new model and many many applications do this. Both client and server have responsibilities. We differ on what we feel those responsibilities are. I feel that I should be able to define what an invalid record is AND have the server reject that record if it is invalid. The server has nothing to do with whether the SQL was valid or invalid or whether the SQL is sending bad data like the wrong dates or text fields that are chopped off. That's all client side. However, the server should know what a valid record looks like and reject those that are not valid. Having worked in a distributed environment and using various middleware I can tell you that in an environment like that it is crucial that the server be able to tell invalid records from valid ones and have the option to handle them (reject, accept/fix, log, etc). Right now MySQL only does an accept/fix type thing. It makes it a valid record even though it really isn't. -- Stormblade (Shaolin Code Warrior) Software Developer (15+ Years Programming exp.) "The worth of your opinion is in direct proportion to the number of people who have asked for it." 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]
