In relational database design, it is a well-known design limitation that many-to-many relations between two tables cannot exist without an intermediate table connecting the two. For example, an Author can write many Books, and a Book can have many Authors:

 

This relationship, sometimes referred to as a "Has And Belongs To Many" (HABTM) relationship, imposes a requirement upon the database designer to introduce a new database table:

 

It is a common naming convention for such tables to join the singular name of both connected tables, resulting in names such as "Author_Book", or "Book_Author".

Unfortunately, this naming convention often hides important underlying concepts. Discovering a descriptive, "real-world" name for junction tables will often increase the structure and readability of application code.

In the example above, a descriptive table name might be "Authorship". A Book is then the result of multiple Authorships, and an Author is the creator of multiple Authorships.

In the future, the application might need to register whether a Book is the first, second, or 42'nd work of an Author, or perhaps denote what percentage the Author's contribution to the Book was (i.e., 10%, 50%,  90%)? These concepts are intuitively represented as "numbering" and "contribution" columns on the Authorship model. A name such as "Author_Book" does not help to discover these names, possibly resulting in less readable code.

If this is the case, then why is the "Author_Book", or "Book_Author" naming convention still so common? Unfortunately, finding the underlying concept of junction tables can be quite challenging, and while no silver bullet exists, it can be a helpful exercise to think about what the creation of a record in this table requires in the real-world. In the above example, an author must write a book before the connection can exist. Had, for example, the relationship existed between the Book and its Publisher, we might have called it a "Publishment".

Interestingly, the English language often uses endings such as -ment or -ship for junction table concepts. These words have come into existence to fulfil the need to express a given relationship between two nouns with a new, concrete noun of its own. Sometimes, no English noun exists, and programmers will have to come up with their own imaginary nouns to name a junction table, such as "groupment", “belongship”, or “paintment”.

To help illustrate my point and aid fellow programmers, I've started a list of possible names for junction tables. It might serve as a starting point when attempting to find the underlying concept of a junction table. Feel free to contribute to this with your own suggestions :) 

Ending in -ment:

advertisement
announcement
arrangement
assignment
attachment
commitment
ejectment
employment
enrollment
enrollment
measurement
involvement
payment
placement
publishment
reimbursement
shipment

Ending in -ship:

authorship
membership
ownership
partnership
relationship

Ending in -tion:

affiliation
association
connection
estimation
participation
selection
junction
transaction
prediction

Ending in -sion

Decision

Ending in -ling:

coupling
revealing
tangling

Ending in -ing:
(When possible, prefer other endings, e.g. -ment, -tion,  -ship)

belonging
booking
documenting (prefer documentation)
engaging
grouping
handling
meeting
offering
opening
painting
picking
sampling
shipping (prefer shipment)
showing
troubleshooting

Ending in -ry:

expiry

discovery

memory

summary

injury

salary

documentary

Ending in -al:

Approval
Withdrawal

Ending in -ance:

Appearance

Ending in -ence:

Other:

badge
bond
chip
choice
contract
draft
hookup
link
option
pick
pin
seam
tie
commit