Соглашения об именах таблиц для справочных таблиц и таблиц хранения

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

Например:

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

Затем у меня есть таблица «роли», в которой содержится информация о ролях, это таблица типов, так как для каждой роли много пользователей.

Затем у меня есть таблица «профилей», которая поддерживает отношения один к одному с таблицей «пользователей».

Теперь я пробовал это:

  • Пользователь
  • роль пользователя
  • Профиль пользователя

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

Как люди обычно называют таблицы для семантических целей в описанном мною примере?


database database-design naming convention
person Flosculus    schedule 27.10.2012    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Здесь хорошо работает соглашение Oracle.

  • множественное число для обычных таблиц (Пользователи для таблицы пользователей. Сама таблица является хранилищем многих пользователей, поэтому я называю ее так, как я бы описал данные в ней)
  • User_Roles будет отдельным списком ролей.
  • User_Role_Assignments список ролей для пользователей. Я предполагаю, что вам нужно здесь много ко многим, если у пользователя может быть любая роль, и роль может быть назначена любому пользователю.
  • User_Profiles - это отдельный список профилей.
  • User_Profile_Assignments для таблицы, которая представляет собой отношение "многие ко многим" между пользователями и профилями.

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

person dseibert    schedule 27.10.2012
comment
Я отредактировал свой вопрос, так как у ролей один ко многим с пользователями, а не много ко многим, моя ошибка. также в отношении: Роли - это отдельный список возможных ролей. Я все же хотел бы, чтобы имя таблицы указывало на то, что это список ролей «пользователя», поскольку могут быть другие сущности с термином «роль», которые будут применяться к - person Flosculus; 28.10.2012
comment
мне действительно нужны соединительные столы для этого? - person Flosculus; 28.10.2012
comment
В этом случае можно использовать User_Roles. Если вы в конечном итоге захотите, чтобы таблица связала User_Roles и Users, я предлагаю что-то вроде User_Role_Assignments. Теперь, когда я думаю об этом, мне нравится представлять, что вы описывали все элементы в таблице, выбирая имя. - person dseibert; 28.10.2012
comment
какой это уровень нормализации? Я предполагал, что пользователи будут хранить только идентификаторы, один из которых является ролью, и, поскольку профиль не будет требоваться «сразу» после создания пользователя, но впоследствии он будет содержать идентификатор пользователя, в отличие от пользователя, владеющего идентификатором профиля. пока для этого не требуется отношений "много ко многим". - person Flosculus; 28.10.2012
comment
Если каждому пользователю может быть назначена только одна роль, а у каждого пользователя может быть только один профиль, вы захотите поместить profile_id и role_id в таблицу Users. Я представлял сценарий, в котором вы хотите, чтобы несколько ролей и профилей были связаны с человеком. - person dseibert; 28.10.2012