У меня есть 2 таблицы: пользователи и роли, и у меня есть таблица, которая объединяет их вместе. Единственная вещь в таблице соединений - это идентификаторы, которые связывают две таблицы.
Что я должен назвать этой таблицей? Я никогда не видел хорошего соглашения об именах для этого.
Соглашения, которые я видел раньше:
Пример:
Users:
Id
Name
Roles:
Id
Name
TableThatJoinsTheTwo:
Id
UserId
RoleId
Кажется, что таблица сопоставления хранит все роли, в которые входит каждый пользователь. Если это правильно, я бы назвал таблицу UserRoles.
Это правильно (IMO) плюрализует цель таблицы, а не UsersRoles, которая просто звучит нечетно.
Я бы назвал таблицу users User, таблицу ролей Role и таблицу соединений UserRoles.
Кстати, pk Id на самом деле не требуется в таблице соединений. Лучше сделайте UserId и RoleId вместе pk или просто uk (уникальный ключ), чтобы обеспечить уникальные отношения User - Role.
Я бы предложил просто UserRoles, так как это то, что он держит.
Я бы назвал таблицу ссылок:
Remove_The_Surrogate_Primary_Key_From_The_Link_Table_Unless_You_Can_Prove_That_You_Really_Need_One
User или Users? Что происходит с вещами, которые заканчиваются на S?" (я бы изменил это сейчас, если вы только что начали проект)User, Role и таблица xref: UserRole.UserRole имеет гораздо больше смысла, чем RoleUser.User_X_Role или UserXRole, если вам нравится дополнительная многословиеМы имеем ту же структуру и вызываем таблицу ссылок UserRoles.
База данных представляет собой предприятие, не так ли? Итак, что люди на этом предприятии называют отношениями?
Вот некоторые из них:
employee сообщает line manager == org chart
student принимает course == регистрация
woman женится man == браки
В случае сомнений спросите эксперта домена на предприятии.
Это соглашение на моем рабочем месте:
UsersXRoles
У меня всегда было что-то вроде: rel_user_roles или relUserRoles. Какая таблица идет сначала, как правило, просто зависит от того, где она находится в модели данных.
У меня есть соглашение, которое мне легко увидеть сразу:
User
Role
User2Role
RoleUser - Я использую буквенное упорядочение (т.е. Role предшествует User). Таким образом, когда вы пишете запрос, вам не придется пытаться запомнить, какой заказ вы использовали для имени таблицы соединений.
Я также использую единственное, как упоминалось выше, - вам не нужно пытаться запомнить! Работает на меня.
2 подходит:
где у вас будет только одна связь между таблицами: join table может быть RoleUser или Role_User. Идите в алфавитном порядке с вашим порядком имен, Роль 1-й, затем Пользователь, тогда вам не нужно пытаться запомнить!
где у вас будет несколько отношений между таблицами: connectionname - например. у вас может быть список регулярных ролей для пользователей, и у вас может быть список потенциальных или прошлых ролей для пользователей. Та же 2 таблицы, но разные отношения. Тогда у вас могут быть RoleUser_Current и RoleUser_Past.
Мы всегда использовали имена двух таблиц, за которыми следует слово "Ссылки". Поэтому в вашем примере имя нашей таблицы будет "UsersRolesLinks".
Вы можете украсть страницу у Microsoft и назвать ее UserInRoles.
Я тщательно об этом подумал, и я бы привязал таблицу User и таблицу Role к таблице UsersRoles. Я считаю, что это хорошо, потому что это указывает на то, что отношения "многие ко многим" можно рассматривать как связывание многих ролей с одним пользователем или даже с множеством пользователей для одной роли (так что оба имеют множественное число). Его также можно читать как "Роли пользователей", указывая на то, что обычный способ мышления о взаимоотношениях - это "роли, которые пользователь имеет".
Я стараюсь держать вещи простыми, но также описать:
user_role_join
В самом деле, используйте псевдонимы таблиц и выберите столбцы с одинаковыми именами, кроме селектора AS.
например. SELECT user.id AS user_id