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

137

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

Table: Color
Columns: Id, ColorName, ColorCode

Table: Shape
Columns: Id, ShapeName, VertexList

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

Table: ???
Columns: ColorId, ShapeId
devuxer
источник
ColorShape и ShapeColor псевдоним для симметрии.
LukLed
2
Я только что натолкнулся на похожий вопрос, которого раньше не видел: stackoverflow.com/questions/1764483/… . Некоторые другие идеи из этого потока: Shape2Color, ShapeXColor, ShapeColorLink.
devuxer
Если бы существовал стандарт именования соединительных таблиц - тогда это не было бы основано на мнениях. Тогда это был бы ответ на вопрос. Закрывая вопрос, вы закрываете возможность для кого-то вроде меня узнать, существуют ли стандартные способы именования ваших соединительных таблиц или нет. Пожалуйста, пересмотрите - те, кто закрыл это ...
Лило

Ответы:

187

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

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

Пример: Readerа Newspaper.

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

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

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

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

вздор
источник
10
+1: хорошо сказано - тщательно выбранное имя сейчас значительно упростит ремонтопригодность.
Прит Сангха
115
«В компьютерных науках есть только две сложные вещи: аннулирование кэша, присвоение имен и ошибки« один на один »
Нил Макгиган
1
скажем, если есть категория для продуктов и другая категория для рецепта. для обеих таблиц у нас будут recipe_categories и product_categories, и, поскольку мы не можем просто «именовать» имя таблицы для обеих таблиц, во избежание конфликта соединительными таблицами для product и recipe будут «recipe_recipe_categories» и «product_product_categories»
c9s
3
Строго логически говоря, соединительная информация не означает добавления новой информации. Я думаю, это то, что происходит, когда вы пытаетесь найти подходящее слово для соединительных таблиц. Люди, читающие газеты, не делают их подписчиками, и нет форм без цвета. Использование «подписчиков» - это добавление новой информации (смысл) при подключении читателей к газетам. И нет слов, чтобы описать связь формы и цвета - никогда не было чего-то противоположного, поэтому и нет названия. Помните, что в таблице соединений нет новых атрибутов.
Лало
35

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

Ник Дандулакис
источник
5
+1 за то, что придумал что-то более изящное, чем просто объединение имен столов
tosh
22

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

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

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

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

Shape <-- ColoredBy --> Color

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

Color <-- Colors --> Shape

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

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

Билл Карвин
источник
Билл, спасибо. Очень интересный ответ.
devuxer
@Bill: все о синонимах, и предпочтение синонимов влияет на соглашение об именах.
OMG Ponies
2
Я полагаю, HasColorможет быть другое возможное имя для таблицы пересечений, которая использует естественный язык.
Билл Карвин
1
@ Билл: у меня проблема с этим соглашением об именах hasColour/ ColouredByдля чего? Это побеждает цель именования, чтобы использовать, DESCRIBEчтобы выяснить отношения.
OMG Ponies
5
Подобно комментарию OMG Ponies, что произойдет, если другие вещи могут иметь цвет? Если у меня есть другая таблица, которая отображает текст в цвет, мне нужно уникальное имя. Может ShapeHasColorи TextHasColor?
devuxer
20

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

COLOR_SHAPE_XREF

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

OMG пони
источник
1
Я тоже использую _XREF ... это всегда имело смысл для меня.
Джеймс Кронен
Я понимаю эту идею, но как пользователь AutoCAD мне нужно найти суффикс, отличный от _XREF ...
Майк
7

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

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

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

Эд Гинесс
источник
6

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

ColorToShape
ColorToShapeMap

источник
На самом деле, термин Mapping обычно используется, когда отношения однонаправлены (один к одному или много). Является ли это caswe? Если это так, то, как правило, вам не нужен другой стол. Если цвет всегда определяет форму, добавьте столбец формы в таблицу цветов или наоборот. Дополнительная таблица обычно нужна только тогда, когда отношение много ко многим. И в этом случае термин «отображение» не подходит.
Чарльз Бретана
В этом случае любая форма может быть подобрана к любому цвету, так что это многие ко многим.
devuxer
2
КСТАТИ, будь то таблица сопоставления или нет, мне нравится идея использовать Toв названии. Что делать, если у вас есть форма с HighlightColor. Если вы это называете ShapeHighlightColor, это будет немного двусмысленно, будь то ShapeHighlight, сопоставленный с цветом, или Shape, сопоставленный с цветом подсветки. Так что, ShapeToHighlightColorможет быть, более понятно.
devuxer
К вашему сведению: Oracle (9i / 10g в любом случае) имеет ограничение в 32 символа для имен таблиц, поэтому вы не можете получить слишком многословно.
OMG Ponies
Я использовал ответ выше, но немного по-другому. то есть Color_Shape_Map. Соглашение: Table1_Table2_Map
Золотая рыбка
6

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

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

Дафидд Рис
источник
1
Мне не нравятся подчеркивания, потому что они конфликтуют с соглашениями об именах внешних ключей, так что в итоге вы получите неприятные имена, такие как Colour_Shape_Colourи Colour_Shape_Shape.
Дэн Бешард
4

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

Билл Ящерица
источник
4

Junction table

ИЛИ Bridge Table

ИЛИ Join Table

ИЛИ Map Table

ИЛИ Link Table

ИЛИ Cross-Reference Table

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

priyanka.sarkar
источник
4

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

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

Color + Shape = ColorsShapes

Palindromer
источник
Если вы идете по маршруту «имена таблиц», это лучше, поскольку единственная версия «обычно» будет таблицей с пространством имен.
Эндрю Хауст
3

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

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

Нил Н
источник
3

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

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

Чарльз Бретана
источник
Но как бы вы назвали настоящую таблицу?
devuxer
Это зависит от того, что описывает таблица. Если там написано «что-нибудь оранжевое, должно быть, ромб», «что-то фиолетовое, должно быть, кружок» и т. Д., То вы можете назвать это одной вещью (возможно, Colour_of_Shape). Если это более слабое определение - известные цвета для фигур, позволяющие одной фигуре появляться много раз - тогда, возможно, Shape_Colour_Map.
Джонатан Леффлер
2

В целом, большинство баз данных имеют своего рода соглашение об именах для индексов, первичного ключа и так далее. В 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
Франкенштейн
источник
1
Хорошая старая венгерская запись, мы встречаемся снова.
Дэн Бешард
1

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

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

узда
источник
1

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

ГБН
источник
1

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

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

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

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

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

Джо Холлоуэй
источник
1

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

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

Mafu
источник
0

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

ДОК
источник
0

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

ColorShape

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

jaestevan
источник
0

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

XREF_COLOR_SHAPE
(
     XCS_ID INTEGER
     C_ID   INTEGER
     S_ID   INTEGER
)
EvilTeach
источник
0

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

Мариус Бурз
источник
0

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

Магнус
источник
0

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

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

monojohnny
источник
0

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

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

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

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

Breeno
источник