Соглашение об объединении имен в SQL

Ответ 1

Кажется, что таблица сопоставления хранит все роли, в которые входит каждый пользователь. Если это правильно, я бы назвал таблицу UserRoles.

Это правильно (IMO) плюрализует цель таблицы, а не UsersRoles, которая просто звучит нечетно.

Ответ 2

Я бы назвал таблицу users User, таблицу ролей Role и таблицу соединений UserRoles.

Кстати, pk Id на самом деле не требуется в таблице соединений. Лучше сделайте UserId и RoleId вместе pk или просто uk (уникальный ключ), чтобы обеспечить уникальные отношения User - Role.

Ответ 3

Я бы предложил просто UserRoles, так как это то, что он держит.

Ответ 4

Я бы назвал таблицу ссылок:

Remove_The_Surrogate_Primary_Key_From_The_Link_Table_Unless_You_Can_Prove_That_You_Really_Need_One

Ответ 5

• Названия таблиц всегда должны быть единичными, так что позже вам не обязательно быть похожими на "это User или Users? Что происходит с вещами, которые заканчиваются на S?" (я бы изменил это сейчас, если вы только что начали проект)
• Общим соглашением будет: User, Role и таблица xref: UserRole.
• Самая важная таблица, или та, которая существовала раньше, идет первым. Это особенно верно, если таблица "role" не имеет реального использования вне пользовательских разрешений. поэтому UserRole имеет гораздо больше смысла, чем RoleUser.
• Я видел такие вещи, как User_X_Role или UserXRole, если вам нравится дополнительная многословие

Ответ 6

Мы имеем ту же структуру и вызываем таблицу ссылок UserRoles.

Ответ 7

База данных представляет собой предприятие, не так ли? Итак, что люди на этом предприятии называют отношениями?

Вот некоторые из них:

• employee сообщает line manager == org chart

• student принимает course == регистрация

• woman женится man == браки

В случае сомнений спросите эксперта домена на предприятии.

Ответ 8

Это соглашение на моем рабочем месте:

UsersXRoles

Ответ 9

У меня всегда было что-то вроде: rel_user_roles или relUserRoles. Какая таблица идет сначала, как правило, просто зависит от того, где она находится в модели данных.

Ответ 10

У меня есть соглашение, которое мне легко увидеть сразу:

User
Role
User2Role

Ответ 11

RoleUser - Я использую буквенное упорядочение (т.е. Role предшествует User). Таким образом, когда вы пишете запрос, вам не придется пытаться запомнить, какой заказ вы использовали для имени таблицы соединений.

Я также использую единственное, как упоминалось выше, - вам не нужно пытаться запомнить! Работает на меня.

Ответ 12

2 подходит:

• где у вас будет только одна связь между таблицами: join table может быть RoleUser или Role_User. Идите в алфавитном порядке с вашим порядком имен, Роль 1-й, затем Пользователь, тогда вам не нужно пытаться запомнить!

• где у вас будет несколько отношений между таблицами: connectionname - например. у вас может быть список регулярных ролей для пользователей, и у вас может быть список потенциальных или прошлых ролей для пользователей. Та же 2 таблицы, но разные отношения. Тогда у вас могут быть RoleUser_Current и RoleUser_Past.

Ответ 13

Мы всегда использовали имена двух таблиц, за которыми следует слово "Ссылки". Поэтому в вашем примере имя нашей таблицы будет "UsersRolesLinks".

Ответ 14

Вы можете украсть страницу у Microsoft и назвать ее UserInRoles.

Ответ 15

Я тщательно об этом подумал, и я бы привязал таблицу User и таблицу Role к таблице UsersRoles. Я считаю, что это хорошо, потому что это указывает на то, что отношения "многие ко многим" можно рассматривать как связывание многих ролей с одним пользователем или даже с множеством пользователей для одной роли (так что оба имеют множественное число). Его также можно читать как "Роли пользователей", указывая на то, что обычный способ мышления о взаимоотношениях - это "роли, которые пользователь имеет".

Ответ 16

Я стараюсь держать вещи простыми, но также описать:

user_role_join

Ответ 17

В самом деле, используйте псевдонимы таблиц и выберите столбцы с одинаковыми именами, кроме селектора AS.

например. SELECT user.id AS user_id