Что мне следует назвать таблицей, которая объединяет две таблицы?

Ответ 1

Есть только две тяжелые вещи в Компьютерные науки: аннулирование кэша и обозначение вещей
- Фил Карлтон

Придумать хорошее имя для таблицы, которая представляет связь many-to-many, облегчает чтение и понимание отношений. Иногда найти великое имя не тривиально, но обычно стоит потратить некоторое время на размышления.

Пример: Reader и Newspaper.

A Newspaper имеет много Readers, а a Reader имеет много Newspapers

Вы можете вызвать связь NewspaperReader, но имя типа Subscription может лучше передать информацию о таблице.

Имя Subscription также более идиоматично, если вы хотите впоследствии сопоставить таблицу с объектами.

Соглашение об именах таблиц many-to-many является конкатенацией имен обеих таблиц, участвующих в отношении. ColourShape будет разумным дефолтом в вашем случае. Тем не менее, я думаю, что Nick D придумал два замечательных предложения: Style и Texture.

Ответ 2

Как насчет ColorShapeMap или Стиль или Текстура.

Ответ 3

Назовите таблицу, которая вам нравится, если она информативна:

COLOR_SHAPE_XREF

С точки зрения модели таблица называется таблицей ссылок join/corrollary/cross reference. Я придерживался привычки использовать _XREF в конце, чтобы сделать отношения очевидными.

Ответ 4

Интересно, что половина ответов дает общий термин для любой таблицы, которая реализует отношения "многие ко многим", а другая половина ответов предлагает имя для этой конкретной таблицы.

Я обычно называл эти таблицы таблицами пересечений.

В терминах соглашений об именах большинство людей дают имя, которое является амальгамой двух таблиц в отношениях "многие ко многим". Поэтому в этом случае "ColorShape" или "ShapeColor". Но я считаю, что это выглядит искусственно и неудобно.

Джо Целько рекомендует в своей книге "Стиль программирования SQL" назвать эти таблицы каким-то естественным языком. Например, если фигура окрашена цветом, затем назовите таблицу ColoredBy. Тогда у вас может быть диаграмма, которая более или менее читается естественно следующим образом:

Shape <-- ColoredBy --> Color

И наоборот, вы можете сказать, что цвет имеет цветовую форму:

Color <-- Colors --> Shape

Но это выглядит так, что средняя таблица - это то же самое, что и Color с множественным соглашением об именах. Слишком сложно.

Возможно, наиболее понятно использование соглашения об именах ColoredBy. Интересно, что использование пассивного голоса делает более понятным соглашение об именах.

Ответ 5

Это Ассоциативная сущность и довольно часто значительна сама по себе.

Например, отношение между многими и многими отношениями между TRAINS и TIMES приводит к TIMETABLE.

Если нет очевидной новой сущности (например, расписания), тогда соглашение должно запускать два слова вместе, предоставляя COLOUR_SHAPE или аналогичный.

Ответ 6

Таблица отображения - это то, что обычно называют.

ColorToShape
ColorToShapeMap

Ответ 7

Я обычно слышу, что называется таблицей развязки. Я называю таблицу тем, с чем она объединяется, поэтому в вашем случае либо ColorShape, либо ShapeColor. Я думаю, что для Shape имеет смысл иметь цвет, чем для цвета, чтобы иметь форму, поэтому я бы пошел с ShapeColor.

Ответ 8

Я работал с администраторами баз данных, которые называют это таблицей соединений.

Colour_Shape довольно типичен - если у отношения нет явного имени домена.

Ответ 9

Промежуточная таблица или Таблица соединений

Я бы назвал его "ColorShapes" или "ColorShape", в зависимости от ваших предпочтений

Ответ 10

Я также слышал, как используется ассоциативная таблица.

имя для вашей таблицы может быть ColorShapeAssociations, что означает, что каждая строка представляет собой связь между этим цветом и этой формой. Существование строки подразумевает, что цвет приходит в этой форме и что фигура входит в этот цвет. Все строки с определенным цветом будут представлять собой набор всех форм, с которыми связан цвет, а строки для конкретной фигуры - это набор всех цветов, в которые фигура входит...

Ответ 11

Junction table

ИЛИ Bridge Table

ИЛИ Join Table

ИЛИ Map Table

ИЛИ Link Table

ИЛИ Cross-Reference Table

Это используется, когда мы переходим к отношениям "многие ко многим", где ключи из обеих таблиц образуют составной первичный ключ таблицы переходов.

Ответ 12

Я всегда относился к термину "Гамбургский стол". Не знаю почему - это просто звучит хорошо.

О, и я бы назвал таблицу ShapeColor или ColorShape в зависимости от того, какая из них чаще используется.

Ответ 13

Таблица "Много-много". Я бы назвал его "ColourShape" или наоборот.

Ответ 14

Трудно ответить на что-то столь же произвольное, как это, но я предпочитаю tosh идею называть его после чего-то в фактическом домене, а не какое-то общее описание базовых отношений.

Довольно часто такая таблица будет развиваться во что-то более богатое для модели домена и будет обладать дополнительными атрибутами выше и выше связанных внешних ключей.

Например, что, если вам нужно сохранить текстуру в дополнение к цвету? Может показаться немного забавным расширить таблицу SHAPE_COLOR, чтобы сохранить ее текстуру.

С другой стороны, есть также что-то, что можно сказать для принятия обоснованного решения, основанного на том, какие требования у вас есть сегодня, и готовности к реорганизации, когда дополнительные требования будут представлены позже.

Все, что сказал, я бы назвал это ПОВЕРХНОСТЬЮ, если бы понял, что будут добавлены дополнительные поверхностные свойства, введенные позже. В противном случае у меня не возникнет проблем с вызовом SHAPE_COLOR или что-то в этом роде и переходом к более насущным проблемам проектирования.

Ответ 15

Может быть, просто ColoredShape?

Я не уверен, что у меня вопрос. Это касается этого конкретного случая или вы ищете общие рекомендации?

Ответ 16

В большинстве случаев большинство баз данных имеют своеобразное соглашение об именах для индексов, первичного ключа и т.д. В PostgreSQL было предложено следующее название:

• первичный ключ: tablename_columnname_ pkey
• уникальное ограничение: tablename_columnname_ ключ
• исключительное ограничение: tablename_columnname_ excl
• для других целей: tablename_columnname_ idx
• внешний ключ: tablename_columnname_ fkey
• sequence: tablename_columnname_ seq
• триггеры: tablename_actionname_after | before_ trig

Ваша таблица привязана ко мне. Чтобы остаться в соответствии с именованием выше, я бы выбрал следующее:

• связанная таблица: tablename1_tablename2_ lnk

В списке объектов таблицы связанная таблица будет отображаться после tablename1. Это может быть визуально более привлекательным. Но вы также можете выбрать имя, которое описывает цель ссылки, как предложили другие. Это может помочь сохранить имя столбца id коротким (если ваша ссылка должна иметь свой собственный именованный идентификатор и упоминается в других таблицах).

• или понравившаяся таблица: purposename_ lnk

Ответ 17

Я рекомендую использовать комбинацию имен сущностей и поместить их во множественное число. Таким образом, имя таблицы выражает связь "много-ко-многим".

В вашем случае:

Цвет + Shape = ColorsShapes

Ответ 18

Я бы назвал его точными именами соединяемых таблиц = ColorShape.

Ответ 19

В признании того, что связано с проектом разработчика,

ColorShape

будет обычным соглашением об именах. В диаграмме ER это будет отношение.

Ответ 20

Позвоните в таблицу перекрестных ссылок.

XREF_COLOR_SHAPE
(
     XCS_ID INTEGER
     C_ID   INTEGER
     S_ID   INTEGER
)

Ответ 21

Я бы использовал r_shape_colors или r_shape_color в зависимости от его значения.
r_ заменил бы xref_ в этом случае.

Ответ 22

Мое голосование за имя, которое лучше всего описывает таблицу. В этом случае это может быть ShapeColor, но во многих случаях лучше, чем имя, отличное от конкатенации. Мне нравится читаемость, а для меня это означает отсутствие суффиксов, никаких подчеркиваний и префиксов.

Ответ 23

Я бы лично пошел за Colour_Shape, с подчеркиванием: просто потому, что я видел, что это соглашение проявляется совсем немного. [но согласитесь с другими сообщениями здесь, что есть, вероятно, более "поэтические" способы сделать это].

Имейте в виду, что внешние ключи также должны быть построены на этой таблице соединений, которая ссылалась бы на таблицы цветов и фигур, которые также помогли бы идентифицировать отношения.

Ответ 24

Соглашение, которое я вижу много для присоединения к таблицам, которые мне лично нравятся, это "Colour_v_Shape", которые я слышал, когда народ ссылается на разговоры как "против таблиц".

Очень ясно, что таблица представляет собой отношение "многие ко многим" и помогает избежать этой (хотя и редкой) запутанной ситуации, когда вы пытаетесь объединить два слова, которые могли бы в противном случае образовать составное слово, например "Масло" и "Молоко" могут стать "ButterMilk", но что, если вам также нужно представлять объект под названием "Buttermilk"?

Сделав это, у вас будет "Butter_v_Milk" и "Buttermilk" - нет путаницы.

Кроме того, мне нравится думать, что в исходном вопросе есть ссылка Foo Fighters.