¿Qué debería nombrar una tabla que mapea dos tablas juntas?

Digamos que tengo dos tablas:

Table: Color Columns: Id, ColorName, ColorCode Table: Shape Columns: Id, ShapeName, VertexList 

¿A qué debería llamar la tabla que mapea el color a la forma?

 Table: ??? Columns: ColorId, ShapeId 

Solo hay dos cosas difíciles en Informática: invalidation de caching y nombrar cosas
– Phil Karlton

Venir con un buen nombre para una table que representa una relación de many-to-many hace que la relación sea más fácil de leer y entender. A veces, encontrar un buen nombre no es trivial, pero por lo general vale la pena pasar un time pensando en ello.

Un ejemplo: Reader y Newspaper .

Un Newspaper tiene muchos Readers y un Reader tiene muchos Newspapers

Podrías llamar a la relación NewspaperReader pero un nombre como Subscription podría transmitir mejor de qué se trata la tabla.

El nombre Subscription también es más idiomático en caso de que quiera asignar la tabla a los objects más adelante.

La convención para nombrar tablas de many-to-many es una concatenación de los nombres de ambas tablas que están involucradas en la relación. ColourShape sería un ColourShape razonable en su caso. Dicho esto, creo que Nick D propuso dos grandes sugerencias: Style y Texture .

¿Qué tal ColorShapeMap o Style o Texture ?

Nombra la table como quieras, siempre que sea informativa:

 COLOR_SHAPE_XREF 

Desde la perspectiva del model, la tabla se denomina tabla de combinación / corrolor / reference cruzada. He mantenido el hábito de usar _XREF al final para hacer que la relación sea obvia.

Interesante aproximadamente la mitad de las respuestas dan un término general para cualquier tabla que implemente una relación de muchos a muchos, y la otra mitad de las respuestas sugiere un nombre para esta tabla específica.

Llamé a estas tablas tablas de intersecciones en general.

En términos de convenciones de nombres, la mayoría de las personas dan un nombre que es una amalgama de las dos tablas en la relación de muchos a muchos. Entonces, en este caso, " ColorShape " o " ShapeColor ". Pero creo que esto se ve artificial e incómodo.

Joe Celko recomienda en su libro "SQL Programming Style" para nombrar estas tablas de forma natural. Por ejemplo, si una forma está coloreada por un color, nombra la tabla ColonetworkingBy . Entonces podrías tener un diagtwig que más o less se lea de forma natural así:

 Shape <-- ColonetworkingBy --> Color 

Por el contrario, se podría decir que un color es una forma de color:

 Color <-- Colors --> Shape 

Pero esto parece que la table del medio es lo mismo que Color con una convención de nomenclatura plural. Demasiado confuso

Probablemente sea más claro usar la convención de nombres de ColonetworkingBy . Es interesante que el uso de la voz pasiva hace que la convención de nomenclatura sea más clara.

Esta es una Entidad Asociativa y con frecuencia es significativa por sí misma.

Por ejemplo, una relación de muchos a muchos entre TRAINS y TIMES da lugar a un HORARIO.

Si no hay una nueva entidad obvia (como el calendar), la convención es ejecutar las dos palabras juntas, dando COLOUR_SHAPE o similar.

Una tabla de mapeo es lo que generalmente se llama.

 ColorToShape ColorToShapeMap 

Por lo general, escucho que se llama una tabla de unión. Nombro la tabla por lo que une, por lo que en su caso, ColorShape o ShapeColor. Creo que tiene más sentido que una Forma tenga un color que un Color para tener una forma, así que iría con ShapeColor .

He trabajado con DBA que lo llaman una tabla de unión .

Colour_Shape es bastante típico, a less que la relación tenga un nombre explícito específico de dominio.

Tabla intermedia o una tabla de unión

Yo lo llamaría "ColorShapes" o "ColorShape", dependiendo de su preference

Junction table

O Bridge Table

O Join Table

O Map Table

O Link Table

O Cross-Reference Table

Esto entra en uso cuando buscamos relaciones de muchos a muchos donde las keys de ambas tablas forman la key primaria compuesta de la tabla de unión.

También escuché el término tabla asociativa utilizada.

un nombre para su tabla podría ser ColorShapeAssociations lo que significa que cada fila representa una asociación entre ese color y esa forma. La existencia de una fila implica que el color viene en esa forma, y ​​que la forma viene en ese color. Todas las filas con un color específico serían el set de todas las forms a las que está asociado el color, y las filas para una forma específica serían el set de todos los colors en los que se encontraba la forma …

Siempre he sido parcial con el término "Hamburger Table". No sé por qué, suena bien.

Oh, y yo llamaría a la tabla ShapeColor o ColorShape dependiendo de cuál es la tabla más comúnmente utilizada.

Tabla "Muchos-Muchos". Yo lo llamaría "ColourShape" o viceversa.

Es difícil responder a algo tan arbitrario como este, pero tiendo a preferir la idea de tosh de nombrarlo después de algo en el dominio real en lugar de una descripción genérica de las relaciones subyacentes.

Muy a menudo este tipo de tabla evolucionará en algo más rico para el model de dominio y tomará attributes adicionales más allá de las keys externas vinculadas.

Por ejemplo, ¿qué sucede si necesita almacenar una textura además del color? Puede parecer un poco raro expandir la tabla SHAPE_COLOR para mantener su textura.

Por otro lado, también hay algo que decir para tomar una decisión bien informada basada en los requisitos que tiene hoy y estar preparado para refactorizar cuando se presenten requisitos adicionales más adelante.

Dicho todo esto, lo llamaría SUPERFICIE si tuviera una idea de que habría properties adicionales similares a las superficies que se introducirían más adelante. Si no, no tendría problemas para llamarlo SHAPE_COLOR o algo por el estilo y pasar a problemas de layout más apremiantes.

Tal vez solo ColonetworkingShape ?

No estoy seguro de get la pregunta. ¿Se trata de este caso específico o está buscando pautas generales?

En general, la mayoría de las bases de datos tienen algún tipo de convención de nomenclatura para índices, key principal, etc. En PostgreSQL se ha sugerido la siguiente denominación:

  • key principal: tablename_columnname_ pkey
  • restricción única: tablename_columnname_ key
  • restricción exclusiva: tablename_columnname_ excl
  • index para otros fines: tablename_columnname_idx
  • key externa: tablename_columnname_ fkey
  • secuencia: tablename_columnname_seq
  • activadores: tablename_actionname_after | before_ trig

Tu table es una tabla vinculada a mí. Para estar en línea con el nombramiento anterior elegiría lo siguiente:

  • tabla vinculada: tablename1_tablename2_lnk

En una list de objects de tabla, la tabla vinculada estará después del nombre de tabla1. Esto podría ser visualmente más atractivo. Pero también puede elegir un nombre que describa el propósito del enlace como otros han sugerido. Esto podría ayudar a mantener corto el nombre de la columna de identificación (si su enlace debe tener su propia identificación con nombre y se hace reference en otras tablas).

  • o me gustó la tabla: purposename_lnk

Recomiendo usar una combinación de los nombres de las entidades y ponerlas en plural. Por lo tanto, el nombre de la tabla expressá la connection "muchos a muchos".

En tu caso:

Color + Forma = ColoresFormas

Yo lo nombraría con los nombres exactos de las tablas que se unen = ColorShape.

En adicción a lo que Developer Art ha relacionado,

 ColorShape 

sería una convención de nomenclatura habitual. En el diagtwig de ER, sería una relación.

Llámalo una tabla de reference cruzada.

 XREF_COLOR_SHAPE ( XCS_ID INTEGER C_ID INTEGER S_ID INTEGER ) 

r_shape_colors o r_shape_color dependiendo de su significado.
r_ sería un reemploop para xref_ en este caso.

Mi voto es por un nombre que describa mejor la tabla. En este caso, podría ser ShapeColor pero en muchos casos un nombre diferente de una concatenación es mejor. Me gusta la legibilidad y para , eso significa sin sufijos, sin guiones bajos y sin prefijos.

Yo personalmente iría por Colour_Shape, con el guión bajo: solo porque he visto esta convención upload un poco. [pero estoy de acuerdo con las otras publicaciones aquí que probablemente hay forms más "poéticas" de hacer esto].

Tenga en count que las keys externas también se deben build en esta tabla de unión que haría reference a las tablas de Color y Forma, lo que también ayudaría a identificar la relación.

Una convención que veo mucho para unir tables que personalmente me gusta es 'Colour_v_Shape', que he oído popular referir coloquialmente como 'versus tablas'.

Deja muy claro a simple vista que la tabla representa una relación de muchos a muchos, y ayuda a evitar esa situación confusa (aunque rara) cuando intentas concatenar dos palabras que de otro modo podrían formar una palabra compuesta, por ejemplo 'Manteca' y 'Milk' puede convertirse en 'ButterMilk', pero ¿y si también necesitaras representar a una entidad llamada 'Buttermilk'?

Haciéndolo de esta manera, tendrías 'Butter_v_Milk' y 'Buttermilk' – sin confusión.

Además, me gusta pensar que hay una reference de Foo Fighters en la pregunta original.