On 12/2/08, Roland Bouman <[EMAIL PROTECTED]> wrote: > > > I don't like picking the PK for replication purposes because a good PK > from a logical POV may be piss-poor for replication purposes. > > Why not find something in between, and automatically add a special > replication id column in case you want replication? This would be an > ordinary column, visible to SQL statements, but perhaps it would be > disallowed to update it directly using SQL. Advantages are that > replication performance is independent from schema design, and in the > future, the key can be adjusted to fit special replication > requirements (integer, biginteger, guid,...)
A disadvantage with that approach is that the moment you expose something like that at all, some users will find a use for it and start to rely on it for something else too. Then, a few years later, when a better idea comes along, you're in a situation where changing it breaks an unknown but non-zero number of other things. I'd either (1) keep it completely behind the scenes and visible only to drizzlebinlog (or some similar mostly diagnostic tool) or (2) use the user's primary key and let them understand what's happening. Jeremy
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
