У нас есть 2 типа объектов и мы хотим их подключить N: N. Например, статьи & авторов.Именование N: N таблиц подключения
Кто-то, вероятно, признает этот вопрос глупым. Я так не думаю, потому что я ищу идеальное соглашение об именах.
спасибо.
Выберите any
, но, пожалуйста, не используйте '2' заменить 'на', который так 1970.
Я лично предпочитаю Junction: AuthorsArticlesJunction, AuthorsBooksJunction. Я положил Authors, потому что без автора ни статьи, ни книги не существовало. Это несколько метафизично, но работает для меня.
1) article_has_author (только мое «приватное» соглашение) m или ArticleAuthor 2) в отношениях n: m нормаль не имеет значения.
Я предпочитаю карту - так что-то вроде AUTHOR_ARTICLE_MAP, когда используется последовательно, объясняет, как используется таблица.
Я бы использовал AuthorArticle. Как правило, первичный объект должен идти первым (если можно определить), но упорядочение не имеет большого значения.
В зависимости от логических отношений, например:
Единственная проблема, которую я с этим подходом заключается в том, что он не идентифицирует таблицу как нечто особенное, поэтому мне нравятся мои «специальные» таблицы с общим концом - т.е. MAP, JOIN и т. д. Я нахожу, что это помогает, особенно когда вы должны вернуться к чему-то через 6 месяцев. – chris
Да, это правда, добавление некоторого общего значения может помочь идентифицировать таблицу как одну из «N: N»/ассоциативных таблиц. Для меня я привык к тому, что одна из этих таблиц называется с синтаксисом Object1_Object2. Даже если имя таблицы не идентифицируется как таблица «N: N» (которая должна быть, когда она состоит из двух основных объектов), быстрый просмотр структуры таблицы и просмотр полей author_id и article_id должны сделать это Чисто. Это просто сводится к личным предпочтениям в именовании. – rosscj2533