SERG1257Злой Бобр Присоединяюсь к ответу выше - для разграничения такого рода доступа мускул вам неподходит. Почему? RLS на вьюхах вполне реализуется (со своими особенностями и ограничениями).
create view my_view as
1.
2.
3.
4.
select * from my_table m
where security_function(SYSTEM_USER,m.дополнительные параметры)=1
grant select on my_view to ordinary_user
revoke select on my_table from ordinary_user
SERG1257MCoder Прямой коннект к MySQL я отметаю из соображений безопасностиА можно сюда эти соображения.
а. Ну чтобы не знали где все хранится и не пытались ломать. (а могут ведь)
б. Как я писал выше, возможен переход на другую БД (уже не с моей стороны) и тогда придется переписывать клиента.
SERG1257MCoder Соответственно, я хочу организовать вебсервис на стороне сервераНе можешь поднять штангу в 100кг? Не вопрос подними штангу 200кг у нее гриф удобнее.
Если удобнее, то реально можно больше поднять.
SERG1257MCoder Но однако я не совсем понимаю как лучше организовать саму работу с БД на стороне клиента
3. Сделать постраничную разбивку и грузить только то что видно
+1
По хорошему этой рутинной работой должен заниматься грид.
Ну грид это хорошо, но грузить в него все данные при каждом запуске программы ?
SERG1257MCoder Но тут сложность в том, что чтобы прокрутить куда то список, надо 50 раз нажать на кнопку "далее" и т.п.Тут пользователь сам себе злобный буратино. Надо ужесточать критерии запроса.
Да, планируется быстрый поиск по названию + сортировка.
SERG1257MCoder .И кнопки прокрутки будут место на экране занимать...Это действительно серьезное возражение.
Реально серьезное, ибо у многих будут экраны 10"-12". Много ли туда влезает ?
SERG1257MCoder Непонятно, как синхронизировать таблицу, не скачивая ее зановоА также обеспечить непротиворечивость данных. Ведь оба пользователя скачавших себе по локальной базе будут свято уверены, что их изменения правильные.
Нет. Скорее то, что юзер мог дома и на работе вносить изменения в БД. Юзеры не смогу влезать не в свои данные.
