[thelist] DB Schema Design

[Hershel Robinson]

> Eeyuch... I'm afraid I think the single statuses table is misguided. I 
> think you can have a common status table where you have a consistent set 
> of values for each class of entity to which it relates, but you don't.
> 
> Because you're acknowledging that - for instance - customers can't be 
> shipped, I think you've basically answered your own question. You need 
> different status tables for each class of entity.

But why, from a database or informational point of view, does this 
answer the question? It may be the I agree with you (or that I don't) 
but I am looking for a compelling reason to suggest one approach versus 
the other. There should never be a mistake of thinking a customer could 
be shipped because the 'shipped' status has a class of 'orders' so that 
system would never apply that status to a customer.

> Also, I think you have to ask: if you have separate tables with entities 
> so similar that they share a single set of statuses, why are they in 
> separate tables?

We don't. Each status has one and one 'class' only. Entities do not 
share statuses.

Hershel

-- 
Gallery Robinson Web Services
http://web.galleryrobinson.com/