Let us say I've two tables:

Table: Color
Columns: Id, ColorName, ColorCode

Table: Shape
Columns: Id, ShapeName, VertexList

What must i call the table that maps color to shape?

Table: ???
Columns: ColorId, ShapeId

You will find only two hard things in Computer Science: cache invalidation and naming things
-- Phil Karlton

Approaching with a decent reputation for a table that signifies a many-to-many relationship can be very convenient in lowering complexity from the data model. Sometimes it's not easy however it takes care of to invest a while considering it.

A good example:

Reader and Newspaper. A Newspaper has numerous Readers along with a Reader has numerous Newspapers. You might call their Relationship a Subscription rather than NewspaperReader. By doing this additionally, it feels natural if you wish to add characteristics towards the relationship or wish to map objects towards the table afterwards.

The convention for naming many-to-many tables is really a concatenation from the names of both tables that take part in the relation (so ColourShape could be okay inside your situation) though I believe Nick D published great suggestions with Style and Texture.

Interesting about 50 % from the solutions provide a general term for just about any table that implements a many-to-many relationship, and also the partner from the solutions advise a reputation for this unique table.

I known as these tables crossing points tables generally.

When it comes to naming conventions, many people provide a title that's an amalgam of these two tables within the many-to-many relationship. So within this situation, "ColorShape" or "ShapeColor." However I find this looks artificial and awkward.

Joe Celko suggests in the book "SQL Programming Style" to title these tables in certain natural language manner. For example, if your Shape is colored with a Color, then title the table ColoredBy. Then you may possess a diagram that pretty much reads naturally such as this:

Shape <-- ColoredBy --> Color

On the other hand, you can say one colors a Shape:

Color <-- Colors --> Shape

But this appears like the center table is identical factor as Color having a plural naming convention. Too confusing.

Most likely most obvious to make use of the ColoredBy naming convention. Interesting that while using passive voice helps make the naming convention more obvious.

It's my job to hear that known as a Junction Table. I title the table in what it joins, so inside your situation either ColorShape, or ShapeColor. It will work better for any Shape to possess a color compared to one to possess a shape, and so i would opt for ShapeColor.

Title the table anything you like, as lengthy because it is informative:

COLOR_SHAPE_XREF

From the model perspective, the table is known as a join/corrollary/mix reference table. I have stored the habit of smoking of utilizing _XREF in the finish to create the connection apparent.

What about ColorShapeMap or Style or Texture.

I have labored with DBAs that refer to it as a join table.

Colour_Shape is rather typical - unless of course the connection comes with an explicit domain-specific title.

It is really an Associative Entity and it is quite frequently significant on its own.

For instance, a many to a lot of relationship between TRAINS and Occasions brings about a TIMETABLE.

If there is no apparent new entity (for example timetable) then your convention would be to run the 2 words together, giving COLOUR_SHAPE or similar.

A mapping table is exactly what normally, this is known as.

ColorToShape
ColorToShapeMap