>I got the impression from Rich and Erik that [usually] keys are added in when [records] are committed. What's the motivation for this?

I can only give you my motives, although I know a few other programmers who do what I do...

I create keys at the moment of committing the records (whether single table, 1:M:..., or what), because of the key-creating scheme I use, which is supposed to give records in one table sequentially incremented (surrogate) primary keys. (I didn't know this was the name for them until recently, I called them "internal IDs", meaning they were internally used by the code and had no meaning to the users.)

Like many programmers, I have a table in each system of "last used" or "next available" primary keys for each table. I don't want the records in this table to be incremented until the moment the "real" tables' records are actually committed, because if the user increments the "last used" or "next available" value for the table they're adding to, then chooses not to commit the new records, the primary key value they've got gets skipped. It's not critical that this not happen, I just would rather it didn't because it seems "unclean" to me. Note that this philosophy applies whether you're using integers for PKs or (as I do for now), use strings which represent numbers in "base 36" (digits count from zero to Z).

Of course, this is a philosophy, and it's my opinion, and as usual, there are many other ways to do this!

Cheers,