вопрос по структуре БД и правам пользователей в MySQL

rsv

Новичок
вопрос по структуре БД и правам пользователей в MySQL

есть некая база
в ней товары и цены на товары в разных
магазинах

есть таблица эталонных товаров (название характеристики и тд.)
etalon_tovary_table
{etalon_tovar_id, tovar_name, tovar_description}
есть таблица магазинов
shops_table
{chop_id, shop_name,shop_address}
есть таблица товаров с ценами
shops_tovary_table
{id, etalon_tovar_id, shop_id, price}
есть веб интерфейс через который все пользователи могут посмотреть на цены, товары всех магазинов. Магазины могут через веб интерфейс менять цены на свои товары, добавлять свои товары (выбирая их из списка эталонных), удалять свои товары.

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

Сразу возник вопрос о том как ограничить магазин в правах, так что бы он мог менять цены только на свои товары.
Если открывать внешний доступ к мускулу для клиентов то теоретически они смогут посылать любые sql запросы к таблице shops_tovary_table, значит и менять не только свои цены.
Если в мускуле завести пользователя и дать ему права на insert, update и delete и проверять клиентом чтобы он не лез не к своим товарам, это не дает гарантии что магазин не сделает конект под этим юзером не из нашего клиента а например прямо через mysql.exe
Напрашивается вывод. Нужно переделать структуру таким образом чтобы таблица shops_tovary_table была у каждого магазина своя, и только на нее у мускульного юзера будут права.

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

По этому поводу почитал вот что
http://dev.mysql.com/doc/mysql/en/MERGE.html
и теперь сижу и думаю поможет ли мне это? На первый взгляд это то что нужно. Но может я чего то не учитываю?
В общем все что я хочу это чтобы Вы глянули на мои размышления и если есть в них косяки то меня бы ткнули носом в них
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
тыкаю носом: в полноценной СУБД подобная вещь реализуется через представления (VIEW).
 

Demiurg

Guest
Sad Spirit
может лучше говорить "в субд, которые ближе к стандарту, чем mysql" ?
 

chira

Новичок
MySQL:
для изменений, каждому заводиться своя база с одинаковым набором таблиц
для показа если версия MySQL 4, используем UNION ALL
при этом, чем больше магазинов, тем больше SQL будет выполняться для отображения товаров.

или переходим c MySQL на другую субд, где это можно реализовать в одной базе
 

rembo

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

http://dev.mysql.com/doc/mysql/ru/ANSI_diff_Views.html
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: rsv
про VIEW в других СУБД я слышал;) , но сейчас как раз разговор о mysql
Выбирать надо средство под задачу, а не подгонять задачу под средство.

Ну не можешь ты внутренними средствами мыскля сделать разделение доступа по строкам. Ну никак.

Автор оригинала: Demiurg
может лучше говорить "в субд, которые ближе к стандарту, чем mysql"?
Политически корректная лексика? :D

MySQL --- альтернативно одарённая СУБД.
 

Demiurg

Guest
А зачем делать такое ограничение на уровне базы ?
В веб интерфейсе же у тебя права разграничиваются ну уровне скриптов. Почему не заставить клиента работать с теми же скриптами по http ?
 

rsv

Новичок
Если писать клиента под win32, и писать его например на delphi. Там есть специальные компоненты для доступа к mysql серверу на прямую. Аналогично тому как это делает php.
Если же я буду между delphi и mysql еще делать прокладку в виде своих php скриптов, то мне это не кажется правильным.
В самом клиенте проверять права смысла не имеет, поскольку, как я уже говорил, никто не помешает магазину использовать не моего клиента а простой файлик mysql.exe, логиниться под своим именем и творить что хочешь.
 

Demiurg

Guest
rsv
mysql открывать наружу смысла нет, а права проверять можно и в скриптах.
 

chira

Новичок
Автор оригинала: rsv
а что в этом плохого?
http://dev.mysql.com/doc/mysql/en/MERGE.html
Сейчас у меня mysql 3.хх.хх работает.
хотя бы
MERGE_table_problems
что мешает сделать upgrade и использовать дополнительные возможности?

Demiurg
mysql открывать наружу смысла нет
зачем открывать наружу? может быть какой нибудь вариант с VPN.
 

rsv

Новичок
Если mysql не открывать наружу то win32 клиент как с ним будет работать?
Через скрипты? IMHO это как то не правильно
Короче из всего выше сказанного я понял что раз вьюх нету то и нормального win32 клиента к мускулу тоже неполучится и пусть магазины обламываются через веб интерфейс :)

-~{}~ 01.07.04 16:05:

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

Demiurg

Guest
> IMHO это как то не правильно
необоснованое IMHO
 

fixxxer

К.О.
Партнер клуба
Можно сделать прослойку на php/perl/... и работать с mysql не напрямую, а через оную.

mysql вообще не предназначен для работы с одной базой кучей юзверей непосредственно.
 

rsv

Новичок
Вот блин
Всегда считал что надо избегать всяческих прослоек, сделанных на коленке можно сказать :)
А тут два уважаемых человека прямо таки меня к этому призывают.

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

Или может быть я слишклм усложняю задачу прослойки?
 

Demiurg

Guest
прослойка то как раз пишется давольнопросто, с клиента приходит запрос, перенаправляем его в бд с ограничениями и отдаем обратно клиенту(xml, cvs)
 

rsv

Новичок
эх блин
я уже почти согласен на прослойку
вот название придумаю чего нибудь типа mysql_guardian.php
и вообще соглашусь :cool:

тему наверно можно на этом закрывать
 
Сверху