> Using this kind of technical keys (auto increment id, where > autoincrement is provided by db) is quite common fo db-design. In fact
Yes, and Codd himself said it is wrong, wrong, wrong to do so. Myself, I can only see a problem if/when: 1. the id gets reused or 2. if the record gets deleted and then later added in again with a different id. I'm no db expert, but if the two things above were avoided then it would be pretty safe to use ids, no? I would like to know if I can _depend_ upon ids NOT getting reused - that would simplify things greatly. I don't know about the second worry though. If it is possible to delete a record that another table's record is referring to (as a foreign key field) then it would cause corruption if that id were reused. Further, if the foreign key field referred to the proper *key* of the other table's row, rather than the id field, then when the row gets re-inserted later, the foreign key relationship would just find the new record. Using an id field, which could change, is problematical. > So far no issues are reported regarding this. Wonderful. Does this mean that my concerns are unfounded re (1) ? How about (2). For those (rare?) occasions where 2 could happen, does this lead to the problems that upset mister Codd? --- Rb --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
