Это хороший дизайн базы данных, чтобы пользователи с правами администратора находились в одной таблице с внешними пользователями?

Question

У меня есть пользователи, которые могут войти на интерфейсную страницу, и администраторы, которые могут войти на страницу администратора.

Должны ли пользователи и администраторы быть "пользователями" с разными ролями или они должны быть разделены на разные таблицы?

Answer 1

Роли должны отслеживаться отдельно от учетных записей пользователей, потому что кто-то может быть повышен (или понижен) со временем. Имеет ли смысл в этой ситуации иметь две разные учетные записи пользователей в двух разных таблицах? Я думаю, что нет.

Вот базовая структура, которую я бы использовал -

ПОЛЬЗОВАТЕЛИ

• user_id (первичный ключ)
• user_name

РОЛИ

• role_id (первичный ключ)
• role_name

USER_ROLES

• user_id (первичный ключ, внешний ключ для USERS.user_id)
• role_id (первичный ключ, внешний ключ к ROLES.role_id)

Answer 2

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

Но, с другой стороны, оба государства и города имеют имя. И оба места. Должны ли они всегда идти за одним столом? Иногда они делают в рекурсивных моделях. Иногда они отдельные.

Мое мышление ...... Администратор считается "типом" пользователя в вашей системе? Или это что-то действительно другое, когда к нему не относится ничего типа "пользователь"? Это зависит от того, что на самом деле означает админ в вашей системе. Является ли общая структура похожей на город / штат? Или общая структура похожа на "вы - пользователь ТИПА"?

Но если сомневаетесь, добавьте администраторов в пользовательскую таблицу, потому что я сомневаюсь, что они действительно разделены. Возможно, вы захотите поделиться системой аутентификации для обоих. Возможно, вы захотите поделиться созданием аккаунта для обоих. Если админ не является чем-то особенным, что только разработчики используют на заднем плане.

Answer 3

Да, все пользователи принадлежат таблице пользователей.Вам также нужно иметь стол с ролями и FK между ними.

Answer 4

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

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

Answer 5

Я бы лично держал «Пользователи» в одной таблице.То, как вы решите представлять роли (например, в виде статического бита в самой таблице User или через расширенные права RBAC), зависит от того, насколько сложна ваша система.Но пользователь есть пользователь.

Answer 6

Создайте отдельную таблицу ролей и отдельную таблицу User_Roles.В первом определите роли, во втором присоедините пользователей к их соответствующим ролям (возможно, они могут иметь более одной?)

Answer 7

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

Answer 8

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

На самом деле было бы лучше держать оба на одной и той же таблице, так как они содержаттот же тип данных.

Answer 9

Полагаю, в вашем вопросе нет абсолютной истины, это зависит от вашего заявления.

Две причины, по которым пользовательские типы могут находиться в разных таблицах:

• Типы различаются по структуре данных (подробности / адрес и т. Д.)
• Хорошего сна. Если вы вручную редактируете свои значения FK (указывая на пользователя), вы исключаете риск указания чего-либо на интерфейсного пользователя.