In my oft overstated and sometimes under-informed opinion, and in spite
of my recently demonstrated lack of math abilities, this sounds like a
REALLY BAD idea verging on evil.

Normalizing "Businesses", "Addresses" and "Contacts" makes sense.
However, putting all of this in one table does not. Business to address
and Business to Contact relations are often a via a role. For example,
given the business "Horne and Pitfield Foods", my "SHIPPER" address will
often be different than my "RECEIVER" address, and definitely different
from my "PHYSICAL" address for courier deliveries (also by department -
shipping, receiving, accounts payable, accounts receivable), or my
"MAILING" address (again by department).

It make make sense to represent businesses and employees under a single
concept like "trading partner". I would look at some of these off the
shelf products for ideas and pitfalls around the modelling of business
relationships: Maximo, Peoplesoft, SAP, and various CRM packages
targeted at different industries.

I can't get into much more detail here without crossing "that" boundary.
But, suffice it to say that I am in a good position to know that a
single table for this is in the category of a REALLY BAD idea.

By OID's, do you mean the same thing a UUID's? The question of using
UUID's is a cross cutting concern that is most often appropriate when
working with disconnected databases that must be merged or distributed.
A master table to identify which table an object with a given OID
resides in is a common technique, but the master table typically
contains only the unique ID plus the name of the table that the object
actually resides in.

In a centralized or well connected database paradigm, UUID's are not
necessarily the most appropriate tool.

Good luck!

On Tue, 2005-05-03 at 23:55 +0000, Rick Roen wrote:
> I am in the process of redisigning a FB DB. I read a bit about
> using a Unique Object identifier (OID's) for all sequential numbers
> used in tables like Customer numbers, invoice numbers etc.
>
> This got me thinking about converting all my businss contact into
> just one table. Currently I have Customers, Vendors, Employees,
> Billto and Shipto tables all with the same basic fields. I was
> thinking about adding them all into one big table and add
> some "boolean" fields (0/1) to identify the records type - which
> could be customer/vendor/employee etc. The same contact could belong
> to multiple categories.
>
> Then when I wanted to display a customer and billto I would do a
> self-referencing (or maybe re-entrant) query like:
>
> Select C1.ContactNum, C1.ContactName, C1.Address1, C1.Address2,
> C1.City, C1.State, C2.ContactName, C2...
> >From CONTACTS C1
> Left Join CONTACTS C2 on C1.BILLTO = C2.ContactNum
>
> This business has quite a few customers who are also vendors and
> might occasionally sell to an employee so there is some overlap in
> categories.
>
> Does anyone has some opinions about if this is a viable option for
> design?
>
> Rick