 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Victor Metelitsa 2:5020/400 23 Jan 2002 13:09:25 To : Serguei Tarassov Subject : Re: Проблемы persistent layers -------------------------------------------------------------------------------- Serguei Tarassov wrote: [...] Попробуй почитать вот это - вдруг понравится? http://cssc.tat.ru/toplink/TLS_Reference.pdf (7 мегов) Это руководство по TOPLink for Smalltalk. Serguei Tarassov wrote: [...] > PL работает примерно по такому алгоритму: > 1. Разбор запроса Для TOPLink'а/S: Специальный язык запросов не нужен. Пишется _обыкновенный_ блок кода на Smalltalk'е. Его (блок кода) можно выполнять и на клиенте; но TOPLink декомпилирует (!) его. Декомпиляция проводится хитрым (но обычным для Smalltalk'а любого диалекта) способом. Поскольку в Smalltalk'е есть объекты и ничего, кроме объектов, и любому объекту можно послать любое сообщение, и если нет метода с соответствующим селектором, то сообщение передается методу #doesNotUnderstand:. Таким образом, мы подсовываем блоку в качестве аргумента объект, который "ничего не понимаем", и трассируем выполнение. > 2. Определение (непонятно как) с каких коллекций объектов надо начинать > фильтрацию выборки. Для TOPLink'а/S: ты создаешь описатель запроса, в котором указываешь класс и условия выборки. После исполнения получаешь на клиенте коллекцию объектов этого класса (или объектов подклассов этого класса). > 3. Инициализация этой коллекции > 4. Вызов методов для объектов коллекции и отсеивание не подходящих по > условию. Для TOPLink'а/S: не так. Во-первых, мы знаем класс, а в TOPLink-системе должен существовать объект-сеанс с дескрипторами классов, а дескриптор знает, в каких таблицах экземпляр класса хранится, каким полям атрибуты соответствуют и т.д. Во-вторых, мы разобрали блок кода. Из этого собирается SQL-запрос. Hапример, мы имеем класс TEmployee с атрибутом firstName. Мы имеем в базе данных таблицу EMPLOYEE с атрибутом FNAME. Мы создали дескриптор, в котором сказали, что классу TEmployee соответствует таблица EMPLOYEE, а атрибут firstName - в поле EMPLOYEE.FNAME. Если бы мы работали с "родной" Smalltalk-коллекцией, выборка всех Денисов выглядела бы как someCollection select: [:eachEmployee | eachEmployee firstName = 'Dennis']. Здесь someCollection - это переменная, указывающая на коллекцию, select: - селектор сообщения, посылаемого коллекции, [:eachEmployee | eachEmployee firstName = 'Dennis'] - блок кода. :eachEmployee - описание параметра после вертикальной черты идет выражение; на Java оно выглядело бы как eachEmployee.firstName().equals('Dennis') В этом примере блок кода выполняется для каждого элемента someCollection, и если блок возвращает true, то элемент добавляется к результату. Когда мы работаем с persistent-коллекцией, это выглядит так: someSesssion readAllFor: TEmployee where: [:eachEmployee | eachEmployee firstName = 'Dennis']. и запрос транслируется в SELECT какие-то поля FROM EMPLOYEE T1 WHERE T1.FNAME = 'Dennis' Строки, считанные из базы, превращаются в объекты. Hикакого FULLSCAN нет. Тут есть еще масса интереснейших подробностей (поддержка идентичности, к примеру; если мы выполним запрос второй раз, будут ли считаны те же объекты или их копии?), я их опущу. > 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) на одной > ЭВМ. А главный интерес-то в данном подходе в том, чтобы масштабировать > решение, размещая подсистемы на узлах в сети. По-моему, тут есть два подхода. Первый из них утверждает, что реляционная СУБД "существует". Тогда проверка делается во VIEW (или хранимой процедуре, если СУБД не позволяет), обращение идет через VIEW/SP. Второй утверждает, что никакой реляционной СУБД "нет". Мы уславливаемся считать, что PL+APP - это и есть СУБД (а реляционка, которая используется для хранения, мысленно низводится до уровня "умной дисковой подсистемы"). Все данные (объекты) по возможности загружены в оперативную память. Мне этот подход кажется наиболее симпатичным (пускай и требует много оперативки, и не всегда применим). -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/536427976242.html, оценка из 5, голосов 10
|
|
|