>>> I'm not sure where the idea that primary keys must be stable comes from. >>> There's nothing necessarily wrong with updating a primary key. All a >>> primary key does is uniquely identify a row in a table. If that id changes >>> over time, that's fine, as long as the primary key columns continue to >>> uniquely identify each row in the table.
Firstly trying to update such a key you'll immediately bump into the practical reasons why it doesn't work well. You have to update every record everywhere in the database that references that key which represents a lot of potential work. But secondly, what happens to applications that have read that value into their local state and then try to operate on it? When they return to perform a second operation and use the primary key to specify the record they wish to operate on they'll find it gone. In short, you have to update every instance of the key, not only in the database, but in every application and even in every other representation in the real world. That could include changing people's bookmarks, notes in PDAs, even paper reports sitting on people's desks -- a tall order for an SQL query. In short primary keys that aren't static just aren't very useful. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
