Hi Jim,

Great discussion. An an important point where you and Markus seem to disagree concerns the concept of what constitutes an entity. While others may disagree, I think this is an important issue.

For lack of a better buzzword, it facilitates a developer's design style which, theoretically, could be applicable across projects. In other words, it forces an abstract discipline during the design phase and possibly with framework development.

For example, I have a Company (company name) table, a Vendor (company name)table, and a Contact (first/last name) table all of which require address information. As such, I create a single Address table (normalizing futher, I could combine the Company and Vendor table). So what constitutes an entity?

In this example, a Company, Vendor, or Contact is no good to me without an address (a business rule) and therefore, can only be an entity with an address. It seems to me that however the entity is represented in the database tier is an implimentation issue that is constrained by current technology (e.g. lack of three dimensional tables). Here is where the abstract discipline comes into play.

Why should these implimentations/technology contraints determine what consitutes an enity?

I'm inclined toward Marcus's point of view here, but would like to hear more of your comments regarding this issue. I really just want to keep this thread alive - this is good stuff.



>Markus,
>
>I'm sure we can find something without too much difficulty :-0