 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Victor Metelitsa 2:5020/400 29 Jan 2002 13:13:52 To : Andrei N.Sobchuck Subject : Re: Проблемы persistent layers -------------------------------------------------------------------------------- a> From: Victor Metelitsa <vvm@cssc.tat.ru> Andrei N.Sobchuck wrote: > Ilya Zvyagin wrote: > IZ> Тебе кажется в сторону чистых ООСУБД смотреть надо и в сторону OQL. > У "чистых ООСУБД", к сожалению, проблемы с запросами, имхо. > Gemstone - не оптимизирует запросы, в которых участвуют > полноценные выражения (вызовы методов и т.д.). Оптимизируеются только > запросы на "кастрированом" языке. Во-первых, запрос > должен быть только по данным (вызов методов не допустим), > во-вторых, допустимы только операции типа "больше", "меньше", "равно". Эту штуку в реальной работе лучше понимать не как готовую СУБД, а как framework. Её индексами лучше не пользоваться вообще (впрочем, это про 5.1.5; доки к 6.0 я еще не читал). Hадо сделать свои собственные HomeCollection с собственной реализацией индексов (ими могут быть, например, словари). Что-то по этому поводу было на http://wiki.cs.uiuc.edu/. Для поддержки индексов сделать свой оповещательный механизм (обычный сообщает лишь о том, что атрибут изменился; максимум - говорит еще новое значение; для поддержки индексов надо же еще сообщать старое); впрочем, можно просто передавать двухэлементный массив из старого и нового значений атрибутов. Проиллюстрирую примером. У нас есть Employee с firstName и lastName, есть "вычисляемый" атрибут fullName, представляющий собой конкатенацию firstName, пробела и lastName. (я не помню GemStone'вский механизм оповещения, потому написал по-VAST'овски) Employee>>fullName ^ firstName, ' ', lastName (запятая - конкатенация у коллекций; строка - коллекция символов) Employee>>firstName: newFirstName oldFullName := self fullName. firstName := newFirstName. self signalEvent: #fullName old: oldFullName new: self fullName или Employee>>firstName: newFirstName oldFullName := self fullName. firstName := newFirstName. self signalEvent: #fullName with: (Array with: oldFullName with: self fullName) Когда мы вставили экземпляр Employee, его Home-коллекция зарегстрировала себя как получателя #fullName от него. Когда firstName изменился, изменился и fullName, оповещение прислало старое и новое значение, и теперь легко перестроить индекс. И т.д. Т.е. для реальной GemStone/S (в отличие от идеальной) требуется "доработка напильником", но все это не так страшно. После доработки же должно получится вполне прилично. Скажем, запрос для ИЛИ (в том, что я имею в виду) будет формулироваться не как myCollection select: [:eachEmployee|eachEmployee firstName = 'X' | eachEmployee firstName = 'Y'] а myHomeCollection executeQuery: (SelectQuery new expression: (OrCondition new add: #(firstName equals 'X'); add: #(firstName equals 'Y') ) внутри объекта выполнится примерно как ((myHomeCollection indexes at: #firstName) at: 'X'), ((myHomeCollection indexes at: #firstName) at: 'Y') (запятая, напоминаю для незнающих, здесь конкатенация). .... в общем, о реализации можно много чего наговорить. Регекспы от Василя Быкова, кажется, уже кто-то адаптировал, а если нет, никто не мешает это сделать самостоятельно. И т.д. -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/53643e183510.html, оценка из 5, голосов 10
|
|
|