Menu
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.
The ORM suggests pluralizing table names, using all lowercase names, and using underscores for many-to-many table names. So for your example, you'd have the following tables: clients, brokers, and brokers_clients (the ORM suggests alphabetically arranging table names for many-to-many tables).
Tables are used for storing data in the database. The naming convention for a table name are as follows: Each table name should have a “tbl” prefix. The next word after the “tbl” prefix should be the table name.
There are only two hard things in Computer Science: cache invalidation and naming things
-- Phil Karlton
Coming up with a good name for a table that represents a many-to-many relationship makes the relationship easier to read and understand. Sometimes finding a great name is not trivial but usually it is worth to spend some time thinking about.
An example: Reader and Newspaper.
A Newspaper has many Readers and a Reader has many Newspapers
You could call the relationship NewspaperReader but a name like Subscription might convey better what the table is about.
The name Subscription also is more idiomatic in case you want to map the table to objects later on.
The convention for naming many-to-many tables is a concatenation of the names of both tables that are involved in the relation. ColourShape would be a sensible default in your case. That said, I think Nick D came up with two great suggestions: Style and Texture.
How about ColorShapeMap or Style or Texture.
Name the table whatever you like, as long as it is informative:
COLOR_SHAPE_XREF
From a model perspective, the table is called a join/corrollary/cross reference table. I've kept the habit of using _XREF at the end to make the relationship obvious.
Interesting about half of the answers give a general term for any table that implements a many-to-many relationship, and the other half of the answers suggest a name for this specific table.
I called these tables intersections tables generally.
In terms of naming conventions, most people give a name that is an amalgam of the two tables in the many-to-many relationship. So in this case, "ColorShape" or "ShapeColor." But I find this looks artificial and awkward.
Joe Celko recommends in his book "SQL Programming Style" to name these tables in some natural language manner. For instance, if a Shape is colored by a Color, then name the table ColoredBy. Then you could have a diagram that more or less reads naturally like this:
Shape <-- ColoredBy --> Color
Conversely, you could say a Color colors a Shape:
Color <-- Colors --> Shape
But this looks like the middle table is the same thing as Color with a plural naming convention. Too confusing.
Probably most clear to use the ColoredBy naming convention. Interesting that using the passive voice makes the naming convention more clear.
This is an Associative Entity and is quite often significant in its own right.
For example, a many to many relationship between TRAINS and TIMES gives rise to a TIMETABLE.
If there's no obvious new entity (such as timetable) then the convention is to run the two words together, giving COLOUR_SHAPE or similar.
A mapping table is what this is usually called.
ColorToShape
ColorToShapeMap
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With