 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Serguei Tarassov 2:5020/400 23 Jan 2002 01:44:12 To : Ilya Zvyagin Subject : Re: Проблемы persistent layers -------------------------------------------------------------------------------- Дорогой наш товарищ Ilya Hа запрос в комитет от 22 января 2002 года, отправленного тов. Ilya Zvyagin по поводу предыдущего запроса тов. Serguei Tarassov со всей партийной прямотой отвечаем: >> Hо фокусы начинаются, когда надо этими объектами управлять, а именно >> передавать дальше и "выше" по _произвольным_ запросам - это >> требование к любой ИС. IZ> Сергей, ты не мог бы привести пример такой "передачи" , а то я IZ> что-то никак не могу понять, о чем речь. Имеется в виду, что для манипуляции _объектами_ нужен некий декларативный язык. В общем виде persistent layer (PL) должен состоять из парсера этого языка, оптимизатора запросов и, собственно, исполнителя созданного оптимизатором сценария (императивный код). Hа PL запросы приходят от надсистемы, то есть он всегда возвращает результат "выше". Подсистемой хранения объектов для PL является, как правило, некая РСУБД, расположенная в сети. PL работает примерно по такому алгоритму: 1. Разбор запроса 2. Определение (непонятно как) с каких коллекций объектов надо начинать фильтрацию выборки. 3. Инициализация этой коллекции 4. Вызов методов для объектов коллекции и отсеивание не подходящих по условию. 5. Если есть другие коллекции, то переход к п.3. Тут, конечно, возможны варианты, но в любом случае аналог в РСУБД всегда выглядел бы как FULL SCAN по всем таблицам, участвующим в запросе. select Сотрудник_Collection where Сотрудник.ОтработаноЧасов() < 40 and Сотрудник.Зарплата.Размер(текущий_месяц()) >= Сотрудник.Зарплата.Размер(текущий_месяц() - 1) and Сотрудник.Контракт.Длительность() < Сотрудник.Проекты.СрокОкончания() and Сотрудник.Проекты.Участники.Количество() > 1 Проблемы уровня PL: 1. Оптимизация методов практически невозможна 2. Для вызова метода требуется сначал инициализировать объект А вот простенький пример. Имеем некий запрос на выборку коллекции объектов и правила проверки прав доступа. В результате должны остаться только те объекты, на которые есть права доступа у текущего пользователя (считаем его однозначно идентифицируемым данной сессией). Имеем persistent layer (PL) и его клиент-приложение (APP). Это вовсе не обязательно конечное клиентское приложение, а может быть приложением на AppServer или сервером CORBA. 1. От APP на PL приходит запрос на выборку коллекции объектов. 2. PL выполняет запрос и возвращает все объекты в APP 3. APP выполняет для каждого объекта правило, определяющеее видимость объекта данным пользователем и отсеивает все недоступные для данного пользователя объекты 4. Готово По моим представлениям, такой сценарий требует недопустимо больших временных затрат даже при наличии всех трех подсистем (хранилища, PL и APP) на одной ЭВМ. А главный интерес-то в данном подходе в том, чтобы масштабировать решение, размещая подсистемы на узлах в сети. -- с коминтерновским приветом участникам съезда тов. Сергей (Тарасов) mailto:serge@arbinada.com Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/64887f606d29.html, оценка из 5, голосов 10
|
|
|