On Dec 3, 9:18 am, James B. [email protected]
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.
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
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