Исходя из опыта, и личных наблюдений - это хорошо для систем, которые постоянно дорабатываются, или для создания впечатления постоянной занятости..   
А если серьёзно - это будет требовать постоянного контроля БД, наличия грамотного специалиста, дополнительных ограничений в масштабируемости.. Если серьёзно, мало верю, что так можно будет сделать решение "под ключ", даже простое.

DimW, 


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

берем какую-нибудь тулзу для работы с БД, подключаемся через нее к серверу MySQL, и кто нам запретит выполнить запрос вида 

п.с. Возможно, в новых версиях MySQL и есть варианты защиты, но раньше их точно не было.

назовите хоть одну систему уровня предприятия которая не доробатывается?


имхо это кросплатформенное явление   


что в вашем понимании "контроль БД"? не уж то администрирование?


а в случае с реализацией БЛ на сервере приложений отсутствие таковых это норма?   


и как же БЛ на стороне БД сказывается на маштабируемости приложения? на этот вопрос обязательно ответьте, уж больно интересно стало


ваша вера пропорциональна вашему опыту и наблидениям.

Добавлено через 7 минут и 46 секунд
Vasay, вы все верно говорите про то, что в случае с десктопом, овладеть не легальным доступом к БД проще чем в случае с сервером приложений.
вот только я вам не про то толкую, я ведь про разграничение доступа в приложении, а не про наглое овладевание паролем к БД. 
 

Да банально - не разу не встречался с масштабированием БД на практике - единственный способ повышения производительности был - покупка нового сервака.
В свою очередь интересно услышать, какие есть варианты?

DimW, 
может я изначально не ясно выражался - но я и имел ввиду именно "наглое овладевание паролем".  Который, в случае с десктоп приложением, вполне доступен для "плохого" менеджера, если конечно это приложение общается с БД напрямую, а не через сервер. 

Кроме того трехзвенная архитектура дает много плюсов в сравнении с двухзвенной. 




Это сообщение отредактировал(а) Vasay - 10.12.2009, 18:45

так я и думал...

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


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

Добавлено через 11 минут и 17 секунд

все ясно было по поводу овладевания паролем - с этим все ясно.

просто помимо этого вы упоменули:

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


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

Спасибо за разъяснение - понял. Честно говоря, теперь не совсем понятно, чем же они всё же различаются в реальной жизни? Именно на уровне БД.

DimW, 



Это я упомянул, как единственный известный мне способ в MySQL защитить данные второго менеджера от первого, если первый подключается к БД напрямую. а не через программу.

Ну т.е. у каждого менеджера своя БД  со своим паролем и логином  

Понятно, что это изврат   


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

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

Добавлено @ 19:49

зачем своя бд? просто свой логин\пароль. и данные между пользователями не шарятся.



Это сообщение отредактировал(а) v2v - 10.12.2009, 19:50

Мы решали проблему доступа на уровне БД за счет того, что ВСЕ данные получались/менялись ТОЛЬКО через хранимые процедуры.
По сути слой бизнес-логики был вынесен в БД на уровен хранимых процедур.

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

Как только нужен Интернет-доступ - сразу появится сервер приложений (пусть даже очень просто в виде Томката+Spring).
Правда и в этом случае можно сделать доступ через хранимые процедуры.

v2v, 

Вы правы есть такая возможность (честно - не знал что в MySQL можно устанавливать права на представления)

Это вариант, хотя и накладывающий некоторые ограничения на работу с БД

serger, понимаете, каким бы мега маштабированным приложение не было, маштабированней СУБД оно быть не может, ведь механизмы блокировок, формирования rollback сегментов, кеширования используемых данных, и .т.д. - реализованы в СУБД. Не позволят они приложению повлиять на маштабируемость и производительность в лучшею сторону, только в худшую.


Vasay, ваше понимание и объективная реальность различаются, может стоит не уператься, а раз и навсегда заполнить этот пробел?!


именно так и поступили, десятки филиалов по всей стране активно работают с системой и преград для расширений мы не видим. 

Это сообщение отредактировал(а) DimW - 11.12.2009, 10:26

Ну я бы сказал, мое понимание понятия "масштабируемости" не дальше от объективной реальности чем Ваше    :






http://ru.wikipedia.org/wiki/%D0%9C%D0%B0%...%81%D1%82%D1%8C



Это сообщение отредактировал(а) Vasay - 11.12.2009, 12:02

да наверное Вы правы, первое не исключает второе, правильный выбор СУБД и грамотная разработка БЛ скорее отсрочит потребность в расширении аппаратной платформы, но ни как не исключит ее расширение при бурном развитии функциональности и числа пользователей приложения.  

Красиво написано,   , 
Мне интересно, как всё-таки как базы "масштабируются" в реальной жизни. Те как увеличить производительность только за счёт увеличения количества "машин".