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

Ответ 1

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

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

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

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

РОЛИ

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

USER_ROLES

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

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