Имеется ли преимущество использования специального соглашения об именах для таблицы «многие ко многим» (таблица соединений) при проектировании таблиц базы данных?

Question

Всякий раз, когда существует отношение «многие ко многим», я думаю, что немедленно понадобится таблица «многие ко многим» (также называемая соединительной таблицей). Есть ли какое-либо преимущество использования специального соглашения об именах для этих таблиц, в отличие от других таблиц от 1 до многих? Или существуют ли специальные специальные соглашения об именах, используемые компаниями, разрабатывающими таблицы базы данных?

Answer 1

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

После многих лет разработки различных схем именования моя последняя из них оказалась наиболее интуитивной (в отношении SQL Server):

• имена таблиц в регистре Паскаля без подчеркивания

• имена соединительных таблиц объединяют имена объединенных таблиц с подчеркиванием

В результате получаются таблицы Foo, FooType, Bar, BarType, FooType_BarType и Foo_Bar.

Oracle не обеспечивает (удобную) чувствительность к регистру, поэтому вам нужно выяснить что-то еще.

Answer 2

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

Английский США
Канада Английский
Франция Французский

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

Американский английский
Канада Английский
Канада Французский
Франция Французский

Если я увижучто есть три таблицы:

Языки
Страны
Languages_Countries

Мне не нужно смотреть на внешние ключи, чтобы понять базовый дизайн.Сравните это с:

Языками
Странами
Languages_Spoken или LC_JOIN или JOIN002

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

Answer 3

Я склонен следовать такой схеме:

1. Table names are singular nouns
2. Link tables are nouns connected by underscore
3. a synonym can be created for the reverse order of the nouns

, например

ADDRESS
ORGANIZATION
ORGANIZATION_ADDRESS
synonym: ADDRESS_ORGANIZATION

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