Quote:
Originally Posted by cavedude
I'm merely concerned with ease of use. If I have a door that I want to change two keyitems, and lockpick I can do that all with one UPDATE query. Having the extra table would require an UPDATE and two INSERTS. Human error being what it is, I feel that's less efficient. VIEWS unfortunately are out, because they were added with MySQL 5.0. Many people are still using 4.0 here, which we still have full compatibility with. It's silly to remove compatibility with 4.0 when there is no real reason to.
|
Ah, I didn't realize people were still using MySQL 4. We don't need views anyway.
To counter your argument, adding an extra field would mean a table ALTER and an UPDATE, as opposed to a table CREATE, an INSERT, and an ALTER. For human error, they can screw anything up, no matter how simple it can get. Updating is riskier, if you can prove the insert worked correctly it is safer to alter the table and remove the field. Both require changes to code in 2 or 3 files. Its only another table; this is an improvement to schema. In both cases, because schema changed there would either be a drop and rebuild script for the next release, or a patch script. If you want to talk about ease of use maybe its better not doing it at all.
Would KLS like to chime in and make a decision for us? I personally don't care which way to go, I just feel its a more professional solution and better in the long run to have a keys transformation table.
