>I've run into a situation where I miss my SQL days: GUIDS'. Right now in Mere Mortals, we can use NewID() stored procedure to get a unique identifier --for that table--.
>
>I've taken a look at the NEWID code, and have a few questions. Why does the ID table keep track of each table's "next" id to use? Why not just use the same concept, but keep track of just one ID. So if any table is making a new record, instead of looking up the ID for it's table, just look up the new ID for all tables...
>Had this been tried before? Did Kevin run into a problem with conflicts of some kind?

Part of the problem with doing something like that is that your primary key is going to get really big, really quickly. Plus in some systems (generally accounting) you can't have "missing" primary id's. If you do you know there is some sort of issue.

>
>The reason I was looking at all this is because (for example) I have an Address table. I'd like to put all addresses of all our projects in this table. However, I have a lot of objects/tables that need addresses. (Customers, Employees, Contacts, etc.) In the Address Table, I can't reference iOwnerID = 1 to belong to AddressID #1, because each table (Customer, employees, contacts) will have their own ID=1.
> I also can't add fields to the Address Table such as: "CustomerID", "EmployeeID", "ContactID" because the list could go on forever. At the moment I'm using reference tables, but that causes headaches for something as simple as referencing addresses.
>

Why not just include a foreign key in the table that needs the address that points to the correct entry in the address table?

Eg.

AddressTable
------------
iid - Integer primary key
street
city
state
...

ProjectsTable
--------------
iid - Integer primary key
projectname
fk_address - integer, points to address in address table.
...