Hi, I don't agree with this "You should never: * Use primary keys having more than one column. * Actually have any meaningfull data in the key olumn" but I do agree that when possible put use an ID with not semantic meaning. It just simplifies a lot of things and in reality is sometimes semantically more correct. Performance wise there should be not difference as current databases work very well with composite keys too (Indexation is a turning a set of value into one value, like a map or hash table) so IMHO this is no motive to have OID in the table as there are several drawbacks too (not the one presented). Fo instance, when doing database merges automatic ID's can turn the process into a nightmare (creating view spaning multiple databases). One can circunavigate this by using an ID of type GUID, but then there can be a performance hit when doing JOINS. But if you don't have to do nothing like this, then ID such as the one purposed by Thona can be used and should be used IMHO. Nuno