> Why not to build PKs like (Site_ID, Table_ID) in this case? This
>not only provides uniqueness but advantages in further grouping and
>identifiying "owner" of the record too.

This solution presumes that you have control over site ID's. When I have a package distributed to say, an engineering company, a six general contractors and six subcontractors bidding on the same job, the opportunity for confusion expand as "meaningful" key fields multiply. Since I do not control my customers' business, I cannot guarantee what format they will enter job ID's, company name, site names/locations, etc. Multiply this by the potential market space of all of the general and sub-contractors in the construction industry, across Canada and the US, and you will see why meaningful keys become unweildy in a real hurry.

Instead of trying to anticipate every combination of job, site, contractor, etc, and then trying to work backwards to identify an entity in a bid, it is easier to assign a guaranteed unique ID up front, before it goes out for bid, and then to receive a guaranteed unique ID back. The product I am working on is not used in an environment that is under my (or any single company's) control, and the framework is required to guarantee a successful merge between data in dissimilar databases operated on independent infrastructures by different companies, during intermittent and unreliable communication windows.

The GUID is attractive to me in this case because, like the integer keys, it eliminates the issue of control of the environment and business structures from my database schema. Unlike the integer keys, it does not require any centralized coordination or alteration of records in transit.

[Non-text portions of this message have been removed]