2017-01-17 2 views
-1

Я делаю небольшой проект, в котором есть 2 типа пользователей.Пользователи проекта базы данных

2 типа пользователей будут иметь разные уровни доступа при доступе к различным контроллерам и представлениям.

Сказать user_type 1 является обычным клиентом. user_type 2 будет клиентом, который немного больше, чем обычный клиент. Как обычный человек против владельца бизнеса, покупки в торговом центре будут на разных уровнях.

Любой случай, у меня есть таблица пользователей с перевалы, как,

user_id (PK)

имя пользователя

пароль

электронной

user_type

is_logged_in

и в моей голове, должно быть 2 других таблиц в отношении пользователей, они должны быть,

customer_profile и client_profile.

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

Как настроить отношения?

ли я сделать имени как на customer_profile и client_profile стола ПК и сделать имя пользователя на столе пользователей FK?

Кстати, любые мысли на ion auth?

после того, как парень сказал мне о laravel, имеющем собственную аутентификацию, я искал один для ci3, и я нашел эту библиотеку аутентификации.

+1

** ПРЕДУПРЕЖДЕНИЕ **: Дать свой собственный слой управления доступом не легко, и есть много возможностей, чтобы получить это серьезно неправильно. Пожалуйста, не пишите свою собственную систему аутентификации, если какая-либо современная [инфраструктура разработки] (http://codegeekz.com/best-php-frameworks-for-developers/), например [Laravel] (http://laravel.com/) поставляется с надежной системой аутентификации (https://laravel.com/docs/5.3/authentication). В абсолютном порядке следуйте рекомендациям по безопасности (http://www.phptherightway.com/#security) и ** никогда не храните пароли в виде обычного текста **. – tadman

+0

Столбец типа 'is_logged_in' будет очень сложно поддерживать. Обычно что-то вроде 'last_logged_in_at', которое является значением DATETIME. – tadman

+0

@ladman duely отметил также, у меня нет много времени, чтобы узнать laravel, и я использую CI3, так как мне удобно ci3. Я буду менять is_logged_in на last_logged_in –

ответ

0

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

Но для простого сценария, о котором вы указали, не рекомендуется начинать с имени пользователя или электронной почты как внешних ключей. Вы можете начать с создания столбца users_id в качестве внешнего ключа в таблице clients_profile и client_profile. Опять же, в зависимости от того, какие общие атрибуты вы хотите сохранить для клиента или клиента, вы можете нормализовать таблицы customers_profile и client_profile в одном user_profile вызывающего пользователя таблицы и использовать столбец user_type в этой таблице, чтобы указать, какой тип профиля он есть.

Вы также можете добавить таблицу групп и добавить всех пользователей в одну или несколько групп. Предположим, что вы создаете таблицу групп с различными группами, такими как Клиент, Клиент, Администратор, Продажи и т. Д. Чтобы назначить пользователей группам, вам понадобится таблица отношений «многие ко многим» между группами и пользователями. Это можно сделать, имея таблицу mmr_user_group с тремя столбцами (mmr_user_group_id, user_id, group_id), где user_id является внешним ключом из таблицы users, а group_id - это внешний ключ из таблицы групп. Это позволит вам назначить нескольких пользователей одной группе и одному пользователю нескольким группам. Затем вы можете назначить привилегии в своем приложении группе, а не на уровне пользователя.

+0

«user_type столбец в этой таблице, чтобы указать, какой тип профиля он» - это будет redundat для 'users.user_type'. –

0

Что об этом проекте:

users(id PK, username UK, pass, email, user_type, last_logged_in) 
user_profiles(id, user_id, ...) 
Смежные вопросы