Проектирование базы данных нескольких пользователей

Question

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

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

Я не совсем уверен, как мне следует проектировать базу данных между этими двумя решениями:

1) одна таблица с именем 'users' с атрибутом 'role', объясняющая, что пользователь может делать, а что нет, а разрешениями управляются через php

2) каждого пользователя приложения.пользователь базы данных, созданный с помощью запроса «CREATE ROLE» (это база данных postgres), и у него есть разрешения на некоторые таблицы, предоставленные с помощью оператора «GRANT»

Следует учитывать, что проект предназначен для базы данныхэкзамен ..

спасибо

Answer 1

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

A) Вы никогда не сможете перейти на другую базу данных без перестройки всего приложения.

B) Типы вещей, которые вы хотите предоставить пользователям в приложении, могут отличаться от того, что позволяет система ACL БД.

И самое главное:

C) Вы не хотите давать пользователю приложения возможность делать что-либо непосредственно с вашей базой данных. Когда-либо.

Так что ваш вариант № 2 прямо не подходит. Таким образом, сохраняйте поле типа пользователя с каждой записью пользователя, и тогда «то, что позволяет этот тип пользователя», становится частью вашей бизнес-логики, рассчитанной в PHP.

Answer 2

Переходите к первому варианту (управляйте разрешениями с помощью PHP). Вот причины:

1. База данных не дает вам достаточного выбора и детализации в разрешениях, которыми вы должны управлять (кому разрешено отправлять электронные письма, в какие группы людям разрешен доступ и т.
2. Как правило, соединения с базой данных довольно дороги, поэтому вам нужно подключиться один раз и оставаться на связи как можно дольше (с тем же пользователем базы данных)
3. Все базы данных не созданы равными в способе обработки учетных записей пользователей. Создавая свою собственную пользовательскую систему выше SQL, вы можете надеяться на большую независимость от базы данных
4. В реальном мире задачи администрирования базы данных и разработки программ выполняются совершенно разными людьми, и программа не имеет права создавать или изменять пользователей базы данных

Answer 3

Перейдите к варианту 1. В долгосрочной перспективе он будет намного более гибким, возможно, его проще будет кодировать, и вы не захотите слишком тесно привязывать логику приложения к конкретной реализации.Что если позже вы захотите перенести приложение на SQL-сервер?Если пользователи базы данных реализованы по-другому, вариант 2 может причинить вам серьезные страдания.

Answer 4

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