Как мне назвать таблицу, которая отображает две таблицы вместе? [закрыто]

Допустим, у меня есть две таблицы:

Table: Color
Columns: Id, ColorName, ColorCode

Table: Shape
Columns: Id, ShapeName, VertexList

Как мне назвать таблицу, которая отображает цвет в форму?

Table: ???
Columns: ColorId, ShapeId

В компьютерных науках есть только две сложные вещи: аннулирование кэша и присвоение имен
- Фил Карлтон

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

Пример: Readerа Newspaper.

А Newspaperимеет много Readersи Readerимеет многоNewspapers

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

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

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

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

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

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

С точки зрения соглашений об именах, большинство людей дают имя, которое является объединением двух таблиц в отношении «многие ко многим». Так что в этом случае « ColorShape» или « ShapeColor.» Но я считаю, что это выглядит искусственно и неловко.

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

Shape <-- ColoredBy --> Color

И наоборот, вы можете сказать, что Color окрашивает Shape:

Color <-- Colors --> Shape

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

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

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

COLOR_SHAPE_XREF

С точки зрения модели, эта таблица называется таблицей соединения / следования / перекрестной ссылки. Я сохранил привычку использовать _XREFв конце, чтобы сделать отношения очевидными.

Это ассоциативная организация, и сама по себе она часто имеет большое значение.

Например, отношение «многие ко многим» между ПОЕЗДАМИ и ВРЕМЕНИМИ порождает РАСПИСАНИЕ.

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

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

ColorToShape
ColorToShapeMap

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

Colour_Shape довольно типично - если только отношение не имеет явного доменно-специфического имени.

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

Junction table

ИЛИ Bridge Table

ИЛИ Join Table

ИЛИ Map Table

ИЛИ Link Table

ИЛИ Cross-Reference Table

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

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

В твоем случае:

Color + Shape = ColorsShapes

Промежуточный Стол или Стол Соединения

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

Я также слышал термин « ассоциативная таблица».

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

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

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

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

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

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

• или понравилась таблица: purposename_ LNK

Я всегда был неравнодушен к термину «Таблица гамбургеров». Не знаю почему - это звучит просто хорошо.

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

Стол «Много-Много». Я бы назвал это «ColourShape» или наоборот.

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

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

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

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

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

Может просто ColoredShape?

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

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

В дополнение к тому, что разработчик Art связан,

ColorShape

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

Назовите это перекрестной справочной таблицей.

XREF_COLOR_SHAPE
(
     XCS_ID INTEGER
     C_ID   INTEGER
     S_ID   INTEGER
)

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

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

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

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

Я часто вижу соглашение о присоединении к таблицам, которое мне лично нравится, «Colour_v_Shape», которое, как я слышал, в народе называют «против таблиц».

С первого взгляда становится ясно, что таблица представляет отношение «многие ко многим», и помогает избежать этой (хотя и редкой) запутанной ситуации, когда вы пытаетесь объединить два слова, которые в противном случае могли бы образовать составное слово, например «Масло». и «Молоко» может стать «Молочным молоком», но что, если вам также необходимо представить сущность под названием «Пахта»?

Делая это таким образом, вы получите «Butter_v_Milk» и «Buttermilk» - без путаницы.

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