Hmmm... That brings me back again to those nasty advantages.

There are a number of business goals that lead directly to GUIDs.

As I said, in the past I simply gave in to the appeal.

Since the design of such a system will never be complete and I anticipate refactoring to be an ongoing process, I believe the best step for me at this point is to formulate some rough operational rules and see how far they take me.

So what do you think about this?

For example:

1. GUID columns should exist in all tables which represent client data, but not system data such as lookups or static data such as a GIS table of physical, geographic features.
2. GUID columns would represent ownership of data but would operate as scopes for rows with INT primary keys. They would represent a logical ownership or scope meta data structure across the entire database.
3. GUID columns should be sequentially created on the server side but should be replicated into rows created on the client side to maintain ownershp.

The idea of 'imposing a logical structure' on the database using GUIDs may not be what you are indicating by suggesting GUIDs to represent sites or national partitions?

When I start thinking in this direction, I wonder why not use the PostgreSql system of using scoped multi-column INT keys representing row id, host id, site id.

However then I recall that clients generating new rows would like to submit records with GUID keys so that their key does not get hosed at the server during synchronization. (the client is 'occasionally connected')

That sort of says that Rows exchanged with clients might have to be stored some sort of hybrid 'journal' table that uses GUID keys but those are parsed into normalized tables with INT keys and GUID ownership identifiers.

?

Thanks,

Kimball