Hi All,
On Tue, Dec 2, 2008 at 11:49 AM, Kristian Nielsen <[EMAIL PROTECTED]> wrote: > I don't think using an engine internal ROWID is a solution for > replication. Such an internal id is just that - internal. And the strong point > about replication is that it is external; it gives freedom to replicate data > without being restricted by engine internals. The rowid you typically have in > non-clustered engines such as MyISAM, Falcon, Oracle, ... is little more than > a pointer to an offset into a datafile/tablespace. Now you cannot replicate > between different engines, probably also not replicate between different > version of the same engine (row size change?), cannot replicate between > different setups of table space/storage on master and slave ... most of the > benefits of MySQL-style replication seem lost. Ok - these are very good points > > Both InnoDB and NDB adds their own hidden primary key if none is specified by > the user. Unfortunately, it causes quite a lot of complications to the storage > engine interface code that the upper MySQL layers do not know about this > hidden key. It adds _lots_ of special cases, due to no space in the record for > the hidden primary key, user-defined partitioning, and others. Much simpler if > the upper layer could add it once for all engines that need it. Also very good points. However - I still consider replication a technical operation that should have little to do with the logical design of the schema. To me, a primary key is part of the logical design. 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,...) > > About the only use for replicating without a primary key is an insert-only > table (eg. logs). Adding an auto_increment primary key to that really does not > cause much overhead, and solves a lot of problems with replication and > otherwise. > > - Kristian. > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~drizzle-discuss > More help : https://help.launchpad.net/ListHelp > -- Roland Bouman http://rpbouman.blogspot.com/ _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
