Kodrik wrote: > > Understand also that the check for a uniq index has to be made by a call to > the DB so it makes sense the DB does it, but a check on the content of a > variable can be made by one line of code without any call to the db.
Anything that the database does, one can also do in code. I could make sure a column is unique by checking it in code before inserting or updating values, but I prefer that it is done in the database with a unique index because this centralizes it. For the same reason, I prefer having NO DEFAULT in the database, because this centralizes the check and avoids errors. The worst thing any development tool can do is silent unwanted favors. Java and C don't do unwanted favors which is why they are great. Javascript and most Microsoft tools do lots of unwanted favors which is why I hate them. This is a personal preference but I suspect most programmers with experience in large projects share this preference. MySQL does many unwanted favors to avoid rollback. This was a bad design decision because update speed usually doesn't matter much. What matters is the speed of reading and reliability of the data. My point about unique indexes is that I assume that this forces MySQL to deal with the rollback problem anyway. If you have a multi-row insert and one of these rows violates a unique index, what does MySQL do? You either do a rollback or lose atomicity. This looks like exactly the same problem that you would have implementing NO DEFAULT or any other column value sanity check in the database. --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
