Разделение пользователей и аднимистраторов на сайте по разным таблицам?

Question

[Денис Казаченков]

Здравствуйте. Пишу небольшой интернет магазин (велосипедю так сказать). Возник такой вот абсурдный вопрос. Нужно ли разделять по разным таблицам клиентов и администраторов (модераторов, менеджеров)? С точки зрения безопасности мне кажется проще их держать в разных таблицах иначе появляется возможность у простого клиента повысить привилегии(роль) до админа. Ну и набор данных у этих лиц конечно разный из чего тоже напрашивается 2 разделение. Правильно ли это будет? И если да то может это кто то реализовывал на kohana может есть примеры?
Заранее спасибо большое!

Answer 1

[timathecue]

А если менеджер захочет сделать заказ или администратор - надо регистрироваться?
В kohana при использовании модуля Auth все пользователи хранятся в users, роли - в roles, связи - roles_users. Соответственно если у пользователя будет роль admin, то это еще и администратор.

Comments

[Игорь Воротнёв]

разумное замечание

[Алексей Кулешов]

В данном конкретном случае мы имеем дело с интернет-магазином, процессом купли-продажи, следовательно есть 2 стороны: продавец и покупатель. Конечно можно хранить всех вместе, давая пометки admin или moderator, но я не вижу практического смысла от оформления заказа сотрудником магазина с правами администратора (для проверки имитируется роль покупателя). Однозначно разнести по разным таблицам ещё на этапе проектирования БД.

[timathecue]

Это ваше видение. И оно достаточно упрощенное. Допустим, под товаром будут комментарии, оставлять которые могут все. Соответственно для комментариев надо 2 таблицы создавать или 3? Для менеджеров, администраторов и покупателей?
А я не вижу смысла создавать под логин и пароль разные таблицы, поэтому однозначно - это Вы погорячились.

[Денис Казаченков]

Если я вас правильно понял то можно сделать так. В таблице users все пользователи в куче разделенные по ролям (админ, менеджер, клиент). С общей для них информацией (логин, пароль, мыло, etc). А для хранения данных специфичных для конкретных групп пользователей будь то клиент или менеджер можно создать таблицы clients, managers и связывать их по ключю user_id. Будет ли такой подход правильным и оправданым? Или я опять что то мудрю?

[timathecue]

В kohane храните логины, емейлы и пароли в таблице users, связи с ролями - в roles_users. Вы можете создавать таблицы 1 к 1 для хранения специфической информации по клиентам и менеджерам, но пока не понятно, какая это будет инфа. Возможно просто расширить таблицу users новыми полями и все

[Алексей Кулешов]

@timathecue если "под товаром будут комментарии, оставлять которые могут все", то мы уже говорим о доске объявлений, форуме, соц.сети, но никак не об интернет-магазине. Первоначально рассматривается отделение "рабочего персонала" в целях смены статусов заказов, ведения лога действий сотрудников (изменения контента/цен/настроек системы) - этот функционал предназначен исключительно для сотрудников определенных ролей (не клиенты). Следуя Вашей логике, Компания 1С в своих продуктах семейства Битрикс практиковала (и продолжает) хранить ВСЕ инфоблоки в одной таблице. В какой-то степени это удобно, до определенного момента... Есть понятие нормализации БД на этапе её проектирования, но ведь простую логику тоже никто не отменял: клиент - не сотрудник Вашей фирмы => выносим в отдельную таблицу, и используем как отдельную сущность.

[timathecue]

Вот про упрощенное мнение я и говорил... Слушайте, возьмите любой интернет магазин, везде можно оставлять комментарии. Не знаю, где Вы нашли принципиальные отличия между магазином и всем остальным - везде есть те, кто пишет, объявляет и т. п. и те кто ставят какие-то галочки и могут видеть что-то другое.
Очень хорошо, что Вы упомянули нормализацию БД, хотя к своей схеме ее не применили (одни и теще сущности хранятся в разных таблицах). Битрикс - это не авторитетный для меня CMS, я не разделяю его философию и архитектуру. В ворпрессе, например, в одной.
И последнее - речь ведь шла про реализацию в kohana, поверьте там это решение из коробки и оно прекрасно работает.

[Алексей Кулешов]

@timathecue не уходя далеко от истины прямо с оф.сайта: "WordPress является идеальной платформой для публикации" - о чем я уже писал (форумы, доски объявлений, новостные сайты).

"принципиальные отличия между магазином и всем остальным" я вижу каждый день в структуре нескольких крупных интернет-магазинов электроники, да и в мелких тоже. Есть список клиентов (или обычных пользователей) у которых есть определенные поля для хранения, данные для сортировка - такие как пол, возраст, адрес проживания и т.п. А теперь внимание - вопрос: если цель нахождения на сайте у этих групп никак не пересекается по функционалу и хранимым данным, какого черта их хранить в одной таблице и относиться к ним как к одной сущности "пользователь"?

Тип сайта/проекта/системы сильно влияет на некоторые принципы разработки - нет на 100% универсальных решений и полностью готовых реализаций.

P.S. Парадокс читать в одном абзаце: "Битрикс - это не авторитетный для меня CMS..." и "...в kohana... это решение из коробки и оно прекрасно работает". Если Вы считаете нормальным использование "решения из коробки" не особо вдумываясь в особенности своего проекта - Вам все же стоит задуматься о карьере в роли разработчика 1С-Битрикс - они единственные кто довели до абсурда "коробочность" своего продукта.

[timathecue]

У мужчин и женщин зачастую тоже разные цели, однако я не считаю, что для них надо создавать разные таблицы, цель не имеет отношения к нормализации БД.

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

А в unix системах тоже есть группы ролей, там тоже разные цели, но хранится считайте в одной базе по моему представлению.

P.S. Я вообще считаю, что надо вдумываться в любом случае. Спасибо за рекомендацию

Answer 2

[Алексей Кулешов]

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

Comments

[Денис Казаченков]

Ну собственно как я и думал. А не посоветуете материал для почитать на эту тему? Честно говоря сталкиваюсь чуть ли не в первые именно с такими процессами.

[Алексей Кулешов]

Лучший совет для "изобретателя велосипеда" - установить на локальную машину любую из известных CMS (WordPress/phpBB/Joomla), и своими глазами убедиться "как" огромное количество специалистов решила эту проблему/задачу.

[Игорь Воротнёв]

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

[timathecue]

и уж точно в CMS они не решали это проблему тысячей таблиц - менеджер, покупатель, администратор, кладовщик и т п

[Денис Казаченков]

Это понятно мой вопрос был только о разделении администрации( менеджеры и т.д.) в одной таблице и клиенты собственно в другой. А не о создании для каждого по таблице.