Toddwrote:
> For the record...
> A groups of users is not Users, it's Personnel.
> A group of users that are part of several groups should not be in a
> table called User_Group, but rather in a table called Membership.
> Sorry. Had to get that off my chest. Use collective nouns where
> possible. Follow up with plurals if necessary.
Except that "membership" begs the question of "in what?" and a group of
users could just as meaningfully be called "humans", or "colleagues", or
"students", or any number of other collective nouns that more or less
impart greater and lesser information regarding the nature of the group.
The word "personnel" implies a contractual relationship among the group
such as the employees of a firm or the crew of a ship, distinct from the
clients of a company or the passengers on a vessel. Is that actually
the intent here, that "outsiders" can never, ever access the system?
What about auditors? Law enforcement officers? Government tax
investigators? Are these all "personnel"? I doubt it.
Okay then. People. It obviously depends on the use case.
Further, in data modeling one must not only consider the problem domain
but the design architecture and its inherent limits when specifying
names of the implementation elements. The question of whether
product_parties or party_products is the correct name of a join table
hinges upon the dominant direction of consideration.
Which, could, in fact, change over time.
The fact that this
is not clear from the outset demonstrates that part of the problem
domain is insufficiently understood rather than reflect a basic flaw in
approach.
If products are the significant entity then product_parties makes sense.
If parties are the significant element then party_products makes sense.
If both parties and products are more or less equivalent from the point
of view of system usage, in other words one is as likely as the other to
be the point of reference for a user query, then simply sub-class one
from the other and use either as appropriate to the situation.
Frankenstiening words is a time honoured practice in languages having
germanic influences, such as English. Hand-Book (ger.) is far more
descriptive of the nature of an artifact than "Manual" (lat.) will ever
be. Just as product_parties is far more meaningful with respect to the
relationship of parties and products than involvements will ever convey.
What, pray tell, do you do with ternary relationships?
If a join relationship has independent significance, like a subscription
or a purchase order, then it can and should be appropriately named for
its own distinctive attributes. Otherwise simpler and clearer is better
from an implementation and maintenance point of view
Sorry. Don't buy it. Happy logistical names of tables do not a happy
programmer make (well, momentarily). This is a classic example of
people using names to discern function when really they should be
disjunct.
The point is that this sort of naming (table_on_table) makes clear to
the designers and programmers that party_products has dependencies on
two named tables whereas "involvement" conveys absolutely nothing
relating to the elements that are involved. If you prefer opening up
classes to get such basic information as to which database tables are
impacted then by all means "futurfy" your design as you see fit.
Myself, I see no good purpose served by obscufating logical connections
enforced by database design choices.
Hey, if a table named users_groups floats your boat, no big deal.
I'll work around it 
Todd
