Проблемы persistent layers

11 просмотров
Перейти к первому непрочитанному сообщению

Serguei Tarassov

не прочитано,
18 янв. 2002 г., 16:20:3618.01.2002
Дорогие товарищи эхотажники!

Хочется обсудить проблему, связанную с управлением долгоживущими объектами.
Поскольку создать объект где-то в приложении, проинициализировать его
данными из БД - это не фокус, а ловкость рук и "мошенство" всяких
корпоративных (а потому нестандартных) persistent layers AKA Object
Relational Framework (про CORBA пока разговора нет, как и массовых всех
устраивающих реализаций PersistenService). Но фокусы начинаются, когда надо
этими объектами управлять, а именно передавать дальше и "выше" по
_произвольным_ запросам - это требование к любой ИС.
Итак, предлагаемые решения представляют собой:
1. Надстройку/среду/фреймворк над уже существующими СУБД, как правило
реляционного типа
2. Так называемые "объектные" СУБД.
Начнем с первого.
Сразу на ум приходит древняя аналогия со встроенным SQL в файл-серверных
приложениях типа фокспро/клиппер: там SQL разбирался подсистемой приложения,
прозрачной для программиста, превращался во внутренние циклы, поиски и и
сканы по файлам и выполнялся с использованием примитовов разделяемого
доступа к файлам конкретной сетевой ОС. Проблемы такого подхода не обсуждаем
(транзакционнность-то и в нетвари можно было обеспечивать на уровне файлов),
важен сам принцип.
Ситуация в надстройке/фреймворке принципиально та же. Имеем некий
_нестандартный_ язык запросов к объектам. В общем случае он интерпретирует
запрос на этом языке в сиквельные запросы, вытаскивает датасеты,
инициализирует по ним объекты и далее фильтрует уже их если, например, в
запросе используется вызов метода (проблемы тут тоже пока не обсуждаем,
например, если в этом методе еще один запрос "спрятан").
Честно говоря, даже при том, что это дает более высокий уровень абстракции,
такие механизмы работы с БД со стороны надстройки/фреймворка вызывают при
взгляде "с низов" (то есть "из БД" на клиента) серъезные опасения в здравом
уме этого клиента.
А что думает съезд по поводу клиента?


--
с коминтерновским приветом участникам съезда
тов. Сергей (Тарасов)
mailto:se...@arbinada.com

Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

Vladimir Pavlikov

не прочитано,
19 янв. 2002 г., 19:40:4019.01.2002

Hello! "Serguei Tarassov" <tem...@arbinada.com> wrote:

> Честно говоря, даже при том, что это дает более высокий уровень абстракции,
> такие механизмы работы с БД со стороны надстройки/фреймворка вызывают при
> взгляде "с низов" (то есть "из БД" на клиента) серъезные опасения в здравом
> уме этого клиента.
> А что думает съезд по поводу клиента?

"Съезд" думает по разному : Метелица, похоже, считает это вершиной мироздания,
я склоняюсь к твоему мнению, а есть (т.е. может быть )еще куча промежуточных...
Только такие вопросы голосованием не решаются.
--

Владимир Павликов.


Andrei N.Sobchuck

не прочитано,
20 янв. 2002 г., 09:16:0120.01.2002
Vladimir Pavlikov wrote:

VP> Hello! "Serguei Tarassov" <tem...@arbinada.com> wrote:

>> Честно говоря, даже при том, что это дает более высокий уровень абстракции,
>> такие механизмы работы с БД со стороны надстройки/фреймворка вызывают при

Такие, это какие?

>> взгляде "с низов" (то есть "из БД" на клиента) серъезные опасения в здравом
>> уме этого клиента.
>> А что думает съезд по поводу клиента?

VP> "Съезд" думает по разному : Метелица, похоже, считает это вершиной мироздания,
Вообще то, Метелица за объектную (без кавычек) СУБД.
(Он в пример приводит Gemstone/S - www.gemstone.com).

VP> я склоняюсь к твоему мнению, а есть (т.е. может быть )еще куча промежуточных...
VP> Только такие вопросы голосованием не решаются.

--
Андрей Собчук
E-mail: and...@itware.com.ua

Serguei Tarassov

не прочитано,
20 янв. 2002 г., 11:18:1620.01.2002
Дорогой наш товарищ Andrei
На запрос в комитет от 20 января 2002 года, отправленного тов. Andrei
N.Sobchuck по поводу предыдущего запроса тов. "Vladimir Pavlikov"
<p...@soil.msu.ru> со всей партийной прямотой отвечаем:

AN> Такие, это какие?
Читем исходное посьмо.

AN> Вообще то, Метелица за объектную (без кавычек) СУБД.
AN> (Он в пример приводит Gemstone/S - www.gemstone.com).
Я тоже не против. А кавычки уберем, когда они смогут хотя бы теоретически
составлять оптимальный план выполнения декларативного объектного запроса (с
участием в нем вызовов методов объектов).

Andrei N.Sobchuck

не прочитано,
20 янв. 2002 г., 11:55:0720.01.2002
Serguei Tarassov wrote:
AN>> Такие, это какие?
ST> Читем исходное посьмо.
Это ты про выборку данных и "дофильтровывание" на клиенте?
По-твоему, это проблема "object-relational frameworks"?

AN>> Вообще то, Метелица за объектную (без кавычек) СУБД.
AN>> (Он в пример приводит Gemstone/S - www.gemstone.com).

ST> Я тоже не против. А кавычки уберем, когда они смогут хотя бы теоретически
ST> составлять оптимальный план выполнения декларативного объектного запроса (с
ST> участием в нем вызовов методов объектов).
А какие RDBMS оптимизируют запросы с функциями?

Serguei Tarassov

не прочитано,
20 янв. 2002 г., 18:48:1520.01.2002
Дорогой наш товарищ Andrei
На запрос в комитет от 20 января 2002 года, отправленного тов. Andrei
N.Sobchuck по поводу предыдущего запроса тов. "Serguei Tarassov"
<tem...@arbinada.com> со всей партийной прямотой отвечаем:

AN> Это ты про выборку данных и "дофильтровывание" на клиенте?
AN> По-твоему, это проблема "object-relational frameworks"?
Не выборка, а выборки, причем в одной атомарной транзакции и при отсутствии
каких-либо критериев оценки порядка проведения выборок и "дофильтрации" (а
вдруг как "дофильтрация" окажется на 100% селективна), _требущей_
инициализации объектов (весьма недешевая операция) по этим выборкам.

AN> А какие RDBMS оптимизируют запросы с функциями?
В RDBMS функция не является артефактом модели. В ООП метод - является.

Andrei N.Sobchuck

не прочитано,
21 янв. 2002 г., 00:57:2521.01.2002
Serguei Tarassov wrote:
AN>> Это ты про выборку данных и "дофильтровывание" на клиенте?
AN>> По-твоему, это проблема "object-relational frameworks"?
ST> Не выборка, а выборки, причем в одной атомарной транзакции и при отсутствии
ST> каких-либо критериев оценки порядка проведения выборок и "дофильтрации" (а
ST> вдруг как "дофильтрация" окажется на 100% селективна), _требущей_
Честно говоря, не понял. :) Ну, да, ладно :)

ST> инициализации объектов (весьма недешевая операция) по этим выборкам.

AN>> А какие RDBMS оптимизируют запросы с функциями?

ST> В RDBMS функция не является артефактом модели. В ООП метод - является.
А откуда требование соптимизировать то, что невозможно соптимизировать
даже теоретически?

Eugene Karataev

не прочитано,
21 янв. 2002 г., 04:35:4121.01.2002
Приветствую.

> Хочется обсудить проблему, связанную с управлением долгоживущими
объектами.
> Поскольку создать объект где-то в приложении, проинициализировать его
> данными из БД - это не фокус, а ловкость рук и "мошенство" всяких
> корпоративных (а потому нестандартных) persistent layers AKA Object
> Relational Framework (про CORBA пока разговора нет, как и массовых всех
> устраивающих реализаций PersistenService). Но фокусы начинаются, когда
надо
> этими объектами управлять, а именно передавать дальше и "выше" по
> _произвольным_ запросам - это требование к любой ИС.
> Итак, предлагаемые решения представляют собой:
> 1. Надстройку/среду/фреймворк над уже существующими СУБД, как правило
> реляционного типа
> 2. Так называемые "объектные" СУБД.

Да...
Почитал я тут про ужасы реляционок, и как в анекдоте -
хорошо, хорошо, хорошо что у меня этого нет.
Короче, ставь Cache и забудь проблемы.

Евгений.

Vladimir Pavlikov

не прочитано,
21 янв. 2002 г., 07:01:3221.01.2002

Hello! "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote:

> >> Честно говоря, даже при том, что это дает более высокий уровень абстракции,
> >> такие механизмы работы с БД со стороны надстройки/фреймворка вызывают при

> Такие, это какие?

Вопросы по тексту желательно адресовать автору текста.

> Вообще то, Метелица за объектную (без кавычек) СУБД.
> (Он в пример приводит Gemstone/S - www.gemstone.com).

Таких в природе не существует, Gemstone не исключение.
Соответственно, его предпочтения я оценивал по его же
текстам, к Gemstone отношения не имеющим. И - не будем
о персоналях. Зачем из ремарки пытаться раздуть [никому
не интересную] тему?
--
Владимир Павликов.

Ilya Zvyagin

не прочитано,
22 янв. 2002 г., 05:11:1022.01.2002

"Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote in message news:eudg2a...@server1.mart.cherkassy.ua...

> AN>> А какие RDBMS оптимизируют запросы с функциями?
> ST> В RDBMS функция не является артефактом модели. В ООП метод - является.
> А откуда требование соптимизировать то, что невозможно соптимизировать
> даже теоретически?

А на кой фиг тогда ООСУБД нужны, если они такие же как и реляционные ?

Ilya Zvyagin

не прочитано,
22 янв. 2002 г., 10:50:1722.01.2002

"Serguei Tarassov" <tem...@arbinada.com> wrote in message news:a2a3hb$t6n$1...@host.talk.ru...

> Хочется обсудить проблему, связанную с управлением долгоживущими объектами.
> Поскольку создать объект в приложении ...

(одним словом просто).

> Но фокусы начинаются, когда надо этими объектами управлять, а именно передавать
> дальше и "выше" по
> _произвольным_ запросам - это требование к любой ИС.

Сергей, ты не мог бы привести пример такой "передачи" , а то я
что-то никак не могу понять, о чем речь.

Serguei Tarassov

не прочитано,
22 янв. 2002 г., 16:44:1222.01.2002
Дорогой наш товарищ Ilya
На запрос в комитет от 22 января 2002 года, отправленного тов. Ilya Zvyagin
по поводу предыдущего запроса тов. Serguei Tarassov со всей партийной
прямотой отвечаем:

>> Но фокусы начинаются, когда надо этими объектами управлять, а именно


>> передавать дальше и "выше" по _произвольным_ запросам - это
>> требование к любой ИС.

IZ> Сергей, ты не мог бы привести пример такой "передачи" , а то я
IZ> что-то никак не могу понять, о чем речь.
Имеется в виду, что для манипуляции _объектами_ нужен некий декларативный
язык. В общем виде persistent layer (PL) должен состоять из парсера этого
языка, оптимизатора запросов и, собственно, исполнителя созданного
оптимизатором сценария (императивный код).
На 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) на одной
ЭВМ. А главный интерес-то в данном подходе в том, чтобы масштабировать
решение, размещая подсистемы на узлах в сети.

Andrei N.Sobchuck

не прочитано,
23 янв. 2002 г., 01:12:5023.01.2002
Ilya Zvyagin wrote:

IZ> "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote in message news:eudg2a...@server1.mart.cherkassy.ua...

>> AN>> А какие RDBMS оптимизируют запросы с функциями?
>> ST> В RDBMS функция не является артефактом модели. В ООП метод - является.
>> А откуда требование соптимизировать то, что невозможно соптимизировать
>> даже теоретически?

IZ> А на кой фиг тогда ООСУБД нужны, если они такие же как и реляционные ?
То есть, единственное, чего тебе не хватает в СУБД, это оптимизации
запросов с процедурами?

Хотя, твой вопрос хороший :)

Victor Metelitsa

не прочитано,
23 янв. 2002 г., 04:09:2523.01.2002

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-запрос.

Например, мы имеем класс 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'

Строки, считанные из базы, превращаются в объекты. Никакого FULLSCAN нет.

Тут есть еще масса интереснейших подробностей (поддержка идентичности, к
примеру; если мы выполним запрос второй раз, будут ли считаны те же
объекты или их копии?), я их опущу.


По-моему, тут есть два подхода.

Первый из них утверждает, что реляционная СУБД "существует". Тогда
проверка делается во VIEW (или хранимой процедуре, если СУБД не
позволяет), обращение идет через VIEW/SP.

Второй утверждает, что никакой реляционной СУБД "нет". Мы уславливаемся
считать, что PL+APP - это и есть СУБД (а реляционка, которая
используется для хранения, мысленно низводится до уровня "умной дисковой
подсистемы"). Все данные (объекты) по возможности загружены в
оперативную память. Мне этот подход кажется наиболее симпатичным (пускай
и требует много оперативки, и не всегда применим).


--

Ilya Zvyagin

не прочитано,
23 янв. 2002 г., 08:22:5823.01.2002

"Serguei Tarassov" <tem...@arbinada.com> wrote in message news:a2kme4$r40$1...@host.talk.ru...

> Дорогой наш товарищ Ilya
> На запрос в комитет от 22 января 2002 года, отправленного тов. Ilya Zvyagin
> по поводу предыдущего запроса тов. Serguei Tarassov со всей партийной
> прямотой отвечаем:

Ты что, Сергей, ностальгией по коммунизму заболел ?

> А вот простенький пример. Имеем некий запрос на выборку коллекции объектов и

> По моим представлениям, такой сценарий требует недопустимо больших временных


> затрат даже при наличии всех трех подсистем (хранилища, PL и APP) на одной

А по моим представлениям это нужно запихать в РСУБД в виде запроса.
Конечно, не все запросы на твоем PL могут быть преобразованы в SQL.
Вот, кстати, если хочешь - идея, хотя и довольно корявая. Путь объекты
в PL выдают по каждому из критериев (свойств объекта) запрос на SQL
(view например), по которому можно искать объекты уже в РСУБД.

> ЭВМ. А главный интерес-то в данном подходе в том, чтобы масштабировать
> решение, размещая подсистемы на узлах в сети.

Можно и сервер РСУБД в виде кластера держать, в отношении
масштабируемости это практически ничем не уступает нескольким
машинам, собственно, несколько машин и есть.

Ilya Zvyagin

не прочитано,
23 янв. 2002 г., 08:29:0723.01.2002

"Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote in message news:qpml2a...@server1.mart.cherkassy.ua...

> >> А откуда требование соптимизировать то, что невозможно соптимизировать
> >> даже теоретически?
> IZ> А на кой фиг тогда ООСУБД нужны, если они такие же как и реляционные ?
> То есть, единственное, чего тебе не хватает в СУБД, это оптимизации
> запросов с процедурами?

В РСУБД мне не хватает _МЕТОДОВ_ объектов. Но метод подразумевает под собой
инкапсуляцию данных, т.е. сокрытие внутренней структуры объектов и его
данных. Производительность РСУБД строится в основном на применении индексов,
т.е. специальной организации хранящихся данных. Тут как бы противоречие
намечается - как данные организовывать , если они скрыты ? Вот и получается,
что никак. А ежели и ООСУБД этого не умеют, то их применение в чем-то отличном
от организации тривиального persistent storage для объектов приложения
достаточно ограничено, т.е. попросту ООСУБД слабо полезны в, скажем,
бизнес-задачах. Я буду лучше использовать РСУБД и OOtoR mapping.

Ilya Zvyagin

не прочитано,
23 янв. 2002 г., 08:55:5123.01.2002

"Victor Metelitsa" <v...@cssc.tat.ru> wrote in message news:3C4E7DFB...@cssc.tat.ru...

> > 2. Определение (непонятно как) с каких коллекций объектов надо начинать
> > фильтрацию выборки.
> Для TOPLink'а/S: ты создаешь описатель запроса, в котором указываешь
> класс и условия выборки. После исполнения получаешь на клиенте коллекцию
> объектов этого класса (или объектов подклассов этого класса).

Это как-то оптимизируется, или же перебираются все объекты этого класса ?

> Когда мы работаем с persistent-коллекцией, это выглядит так:
> someSesssion
> readAllFor: TEmployee
> where: [:eachEmployee | eachEmployee firstName = 'Dennis'].
> и запрос транслируется в
> SELECT какие-то поля
> FROM EMPLOYEE T1
> WHERE T1.FNAME = 'Dennis'
> Строки, считанные из базы, превращаются в объекты. Никакого FULLSCAN нет.

А для чего-то отличного от тривиального свойства объекта как это будет выглядеть ?
Если firstName не соответствует напрямую полю РСУБД, а есть результат
некоей операции над полями ?

> По-моему, тут есть два подхода.

...


> Второй утверждает, что никакой реляционной СУБД "нет". Мы уславливаемся
> считать, что PL+APP - это и есть СУБД (а реляционка, которая
> используется для хранения, мысленно низводится до уровня "умной дисковой
> подсистемы"). Все данные (объекты) по возможности загружены в
> оперативную память. Мне этот подход кажется наиболее симпатичным (пускай
> и требует много оперативки, и не всегда применим).

и - перебор ВСЕХ объектов. Я понимаю, конечно, что и для РСУБД
такие нетриыиальные запросы тяжелы, но ...

Кстати, можно совмещать первый и второй. Наверное это наиболее
реалистично.

Victor Metelitsa

не прочитано,
23 янв. 2002 г., 09:36:5723.01.2002

Ilya Zvyagin wrote:
[..]

>
> В РСУБД мне не хватает _МЕТОДОВ_ объектов. Но метод подразумевает под собой
> инкапсуляцию данных, т.е. сокрытие внутренней структуры объектов и его
> данных. Производительность РСУБД строится в основном на применении индексов,
> т.е. специальной организации хранящихся данных. Тут как бы противоречие
> намечается - как данные организовывать , если они скрыты ? Вот и получается,
> что никак. А ежели и ООСУБД этого не умеют, то их применение в чем-то отличном
> от организации тривиального persistent storage для объектов приложения
> достаточно ограничено, т.е. попросту ООСУБД слабо полезны в, скажем,
> бизнес-задачах. Я буду лучше использовать РСУБД и OOtoR mapping.
>


Почему же никак?

Чем в данном контексте обсуждения вызов метода объекта отличается от обращения к полю записи таблицы? Тремя вещами: фиксированным временем доступа и "детерминированностью" (т.е. если строка не подверглась модификации, то всегда получаешь один и тот же результат), а также "сравниваемостью" (две строки легко можно сравнить между собой, а как сравнить два объекта класса Employee?). Для метода это в общем случае не так. Но если ты выделишь определенное подмножество методов, то индексы и оптимизаторы a la РСУБД вполне возможны.

А ежели и ООСУБД этого не умеют, то их применение в чем-то отличном
от организации тривиального persistent storage для объектов приложения
достаточно ограничено, т.е. попросту ООСУБД слабо полезны в, скажем,
бизнес-задачах. Я буду лучше использовать РСУБД и OOtoR mapping.

Во-первых, ОО СУБД позволяют|ет (единственное число может быть, потому что для меня не факт, что есть более одной ООСУБД) делать _очень сложные_ структуры, прямо-таки немыслимые для РСУБД, простым и легким образом. Во-вторых, важность индексов тобой преувеличена - понятно, почему (потому что ты с ОО СУБД не знаком).

Пример: X связан с Y отнощением 1:N. Типичное для РСУБД решение - две таблицы, foreign key, без индекса работа немыслима (чудовищные тормоза). У ОО СУБД экземпляр X попросту содержит ссылку на коллекцию экземпляров Y, с которыми связан. Таким образом, мы получаем искомые Y немедленно, без поиска по индексам.

Еще одна чудесная штука - словарь (иначе называемый ассоциативным массивом). В нотации Java

myDictionary[myIndex]

myIndex - необязательно число, это может быть объект _любого_ класса.

>
>
>


--

Victor Metelitsa

не прочитано,
23 янв. 2002 г., 09:45:0823.01.2002

Ilya Zvyagin wrote:

> "Victor Metelitsa" <v...@cssc.tat.ru> wrote in message news:3C4E7DFB...@cssc.tat.ru...
>
>
>>>2. Определение (непонятно как) с каких коллекций объектов надо начинать
>>>фильтрацию выборки.
>>>
>>Для TOPLink'а/S: ты создаешь описатель запроса, в котором указываешь
>>класс и условия выборки. После исполнения получаешь на клиенте коллекцию
>>объектов этого класса (или объектов подклассов этого класса).
>>
>
> Это как-то оптимизируется, или же перебираются все объекты этого класса ?
>

Я же объяснил ниже - перебираются записи в реляционке.


>
>>Когда мы работаем с persistent-коллекцией, это выглядит так:
>>someSesssion
>> readAllFor: TEmployee
>> where: [:eachEmployee | eachEmployee firstName = 'Dennis'].
>>и запрос транслируется в
>>SELECT какие-то поля
>>FROM EMPLOYEE T1
>>WHERE T1.FNAME = 'Dennis'
>>Строки, считанные из базы, превращаются в объекты. Никакого FULLSCAN нет.
>>
>
> А для чего-то отличного от тривиального свойства объекта как это будет выглядеть ?
> Если firstName не соответствует напрямую полю РСУБД, а есть результат
> некоей операции над полями ?
>


Какую операцию ты хочешь?

[:eachEmployee | eachEmployee firstName asUppercase = 'DENNIS' &
eachEmployee lastName asUppercase = 'SMITH']

оттранслируются (в случае DB2)
WHERE UCASE(fname)='DENNIS' AND UCASE(lname)='SMITH'

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


>
>>По-моему, тут есть два подхода.
>>

> ....


>
>>Второй утверждает, что никакой реляционной СУБД "нет". Мы уславливаемся
>>считать, что PL+APP - это и есть СУБД (а реляционка, которая
>>используется для хранения, мысленно низводится до уровня "умной дисковой
>>подсистемы"). Все данные (объекты) по возможности загружены в
>>оперативную память. Мне этот подход кажется наиболее симпатичным (пускай
>>и требует много оперативки, и не всегда применим).
>>
>
> и - перебор ВСЕХ объектов. Я понимаю, конечно, что и для РСУБД
> такие нетриыиальные запросы тяжелы, но ...
>


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


> Кстати, можно совмещать первый и второй. Наверное это наиболее
> реалистично.
>

Наверное...

Andrei N.Sobchuck

не прочитано,
23 янв. 2002 г., 09:53:2023.01.2002
Ilya Zvyagin wrote:
IZ> В РСУБД мне не хватает _МЕТОДОВ_ объектов. Но метод подразумевает под собой
IZ> инкапсуляцию данных, т.е. сокрытие внутренней структуры объектов и его
IZ> данных. Производительность РСУБД строится в основном на применении индексов,
IZ> т.е. специальной организации хранящихся данных. Тут как бы противоречие
IZ> намечается - как данные организовывать , если они скрыты ? Вот и получается,
IZ> что никак. А ежели и ООСУБД этого не умеют, то их применение в чем-то отличном
Если метод не имеет побочных эфектов, и не принимает параметров, то проиндексировать,
имхо, можно. (indexed views делают именно это. Так?)

IZ> от организации тривиального persistent storage для объектов приложения
IZ> достаточно ограничено, т.е. попросту ООСУБД слабо полезны в, скажем,
IZ> бизнес-задачах. Я буду лучше использовать РСУБД и OOtoR mapping.
Я не уверен что проще - использовать OOtoR или нет.

btw, как OOtoR соотносится с использованием SP?
Лучше без SP совсем или изредка можна?

Ilya Zvyagin

не прочитано,
23 янв. 2002 г., 11:29:4023.01.2002

"Victor Metelitsa" <v...@cssc.tat.ru> wrote in message news:3C4ECB16...@cssc.tat.ru...

> Во-первых, ОО СУБД позволяют|ет (единственное число может быть, потому что для меня не факт, что есть более одной ООСУБД)

А как зовут эту единственную ?

делать _очень сложные_ структуры, прямо-таки немыслимые для РСУБД, простым и легким образом.
Во-вторых, важность индексов тобой преувеличена - понятно, почему (потому что ты с ОО СУБД не знаком).

> Пример: X связан с Y отнощением 1:N. Типичное для РСУБД решение - две таблицы, foreign key, без индекса работа немыслима
(чудовищные тормоза). У ОО СУБД экземпляр X попросту содержит ссылку на коллекцию экземпляров Y, с которыми связан. Таким образом,
мы получаем искомые Y немедленно, без поиска по индексам.

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

Ilya Zvyagin

не прочитано,
23 янв. 2002 г., 11:31:4223.01.2002

"Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote in message news:bqlm2a...@server1.mart.cherkassy.ua...

> btw, как OOtoR соотносится с использованием SP?

Никак. Обсолютно ортогонально, как говориться.

> Лучше без SP совсем или изредка можна?

Можно вообще с SP , можно вообще без SP, можно и так, и так.

Victor Metelitsa

не прочитано,
24 янв. 2002 г., 06:44:2824.01.2002

Ilya Zvyagin wrote:

> "Victor Metelitsa" <v...@cssc.tat.ru> wrote in message news:3C4ECB16...@cssc.tat.ru...
>
>
>>Во-первых, ОО СУБД позволяют|ет (единственное число может быть, потому что для меня не факт, что есть более одной ООСУБД)
>>
>
> А как зовут эту единственную ?
>


GemStone/S, конечно ;-).

Я не говорю, что других не существует - я просто не в курсе. Часть я
просто "забраковал" - Objectivity и VOSS, к примеру, используют file
sharing (хотя это не значит, что они совсем негодны для использования),
с частью не знаком, но GemStone имеет все атрибуты "настоящей" СУБД.


[...]

> Да нет, ты наверное не прав. Как раз это-то я и не подразумевал. Я имел в виду обработку
> каких-то запросов типа аналитических вроде "какие сотрудники получают зарплату выше средней
> по данной фирме". А так понятно как это делать - заводить специальную коллекцию у фирмы
> и - вперед, на каждое изменение зарплаты ее изменять.


И этот механизм сокрыть внутри Home Collection.


В отличие от традиционных РСУБД, мы можем создавать свои типы таблиц и индексов (на основе словариков или как-то иначе), а не довольствоваться теми, что дали разработчики.

Victor Metelitsa

не прочитано,
24 янв. 2002 г., 06:50:3924.01.2002

Ilya Zvyagin wrote:


Не-е-е. Плохому OOtoR (типа Object Extender) действительно без разницы
(там ведь и SQL-запросы вручную приходится писать), хорошему (TOPLink
или в будущем - GLORP) - разница огромная. TOPLink ведь создает
SQL-запросы сам; огромное количество вариаций; для каждого возможного
SQL создать процедуру и описать ее в дескрипторах TOPLink'а - нет, это
практически невозможно.


--

Vladimir Pavlikov

не прочитано,
24 янв. 2002 г., 07:55:3624.01.2002

Hello! "Victor Metelitsa" <v...@cssc.tat.ru> wrote:

> Пример: X связан с Y отнощением 1:N. Типичное для РСУБД решение - две таблицы,
foreign key, без индекса работа немыслима (чудовищные тормоза). У ОО СУБД экземпляр X
попросту содержит ссылку на коллекцию экземпляров Y, с которыми связан. Таким
образом, мы получаем искомые Y немедленно, без поиска по индексам.

Это механизм сетевых субд. Никакого отношения к ОО-шности не имеет.
--
Владимир Павликов.

Andrei N.Sobchuck

не прочитано,
24 янв. 2002 г., 07:59:4424.01.2002
Ilya Zvyagin wrote:

IZ> "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote in message news:bqlm2a...@server1.mart.cherkassy.ua...


>> btw, как OOtoR соотносится с использованием SP?

IZ> Никак. Обсолютно ортогонально, как говориться.

>> Лучше без SP совсем или изредка можна?

IZ> Можно вообще с SP , можно вообще без SP, можно и так, и так.

Я почему спрашиваю - в SP обычно держат логику.
С объектами - это ни к чему. Так?

Victor Metelitsa

не прочитано,
24 янв. 2002 г., 08:07:5524.01.2002

Vladimir Pavlikov wrote:

> Hello! "Victor Metelitsa" <v...@cssc.tat.ru> wrote:
>
>
>>Пример: X связан с Y отнощением 1:N. Типичное для РСУБД решение - две таблицы,
>>
> foreign key, без индекса работа немыслима (чудовищные тормоза). У ОО СУБД экземпляр X
> попросту содержит ссылку на коллекцию экземпляров Y, с которыми связан. Таким
> образом, мы получаем искомые Y немедленно, без поиска по индексам.
>
> Это механизм сетевых субд. Никакого отношения к ОО-шности не имеет.

Я говорю о том, как должна быть устроена ОО СУБД. Как, спрашивается, ОО
СУБД (в которых, разумеется, есть только объекты и ничего кроме
объектов) могут быть иначе устроены? Скопление объектов - внутри
коллекции (это следует по определению коллекции, таблица один из частных
случаев коллекции). То, что похожий механизм есть в сетевых СУБД, не
имеет никакого отношения к делу.


--

Vladimir Pavlikov

не прочитано,
24 янв. 2002 г., 10:13:2724.01.2002

Ну и как с тобой вести обсуждение? Сколько раз убеждался - стоит
только затронуть "священных коров" - и соображалка начисто отказы-
вает даже тем, у кого она есть :(
Еще раз - ОО - это _методология_, а провязка ссылок - это _реализа-
ционный_ механизм. Можешь почитать о нем в спецификациях CODASYL,
в разделе, посвященном механизмам организации наборов - это один
из базовых механизмов сети. Еще можешь поискать его же в ОО-источ-
никах. Только не в доке по _конкретной реализации_ "ООСУБД", в
которой писано и про механизмы реализации. Если (ну а вдруг?)
найдешь - очччень интересно будет познакомится, уж не откажи...
Ну а то, что ровно то же самое можно получить использованием
тех же индексов (т.е. "традиционными" реализациями) ОО-шности не
прибавит, и не убавит... Так что - см. выше.
--
Владимир Павликов.

Ilya Zvyagin

не прочитано,
24 янв. 2002 г., 13:09:4424.01.2002

"Victor Metelitsa" <v...@cssc.tat.ru> wrote in message news:3C4FF566...@cssc.tat.ru...

> или в будущем - GLORP) - разница огромная. TOPLink ведь создает
> SQL-запросы сам; огромное количество вариаций; для каждого возможного
> SQL создать процедуру и описать ее в дескрипторах TOPLink'а - нет, это
> практически невозможно.

Но если МОЖНО хотя бы в некоторых случаях, тогда, я думаю, это хорошо.

Кстати, TopLink - это что ? Как с GemStone соотносится ?


Ilya Zvyagin

не прочитано,
24 янв. 2002 г., 13:11:4924.01.2002

"Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote in message

> Я почему спрашиваю - в SP обычно держат логику.


> С объектами - это ни к чему. Так?

Логика в СП , возможно, ни к чему. СП - вожможно и к чему-то
пригодится.

Andrei N.Sobchuck

не прочитано,
25 янв. 2002 г., 04:09:4725.01.2002
Ilya Zvyagin wrote:
IZ> Кстати, TopLink - это что ? Как с GemStone соотносится ?
Это O/R mapping framework.
В текущий момент только для жабы.
Не соотносится с GemStone никак.

Serguei Tarassov

не прочитано,
27 янв. 2002 г., 06:55:1027.01.2002
Дорогой наш товарищ Ilya
На запрос в комитет от 23 января 2002 года, отправленного тов. Ilya Zvyagin

по поводу предыдущего запроса тов. Serguei Tarassov со всей партийной
прямотой отвечаем:

IZ> Ты что, Сергей, ностальгией по коммунизму заболел ?
Пребывание на родине "Интернационала" располагает :-) Админ конторы, с
которой я сейчас сотрудничаю (мужик лет 50, кстати) пропел мне пару куплетов
в оригинале. Я пока только припев выучил - он простой :-)

IZ> А по моим представлениям это нужно запихать в РСУБД в виде запроса.
IZ> Конечно, не все запросы на твоем PL могут быть преобразованы в SQL.
В этом я и вижу главную беду. Если подход объектный, то вообще никакой
запрос не может быть преобразован в SQL, поскольку в ОП открытых полей в
объекте быть не должно - все через get/set методы. Вот и получаем, что
каждый объект как-то "умеет" инициализировать свое состяние из хранилища, а
дальше надо их обрабатывать уже самому PL. Хранилище в этом подходе не
должно ничего обрабатывать. В гибридном подходе получаем, что подсистема
выполнения запросов "размазана" между PL и СУБД.

Ilya Zvyagin

не прочитано,
28 янв. 2002 г., 02:58:0328.01.2002

"Serguei Tarassov" <tem...@arbinada.com> wrote in message news:a30pq6$hul$1...@host.talk.ru...

> IZ> А по моим представлениям это нужно запихать в РСУБД в виде запроса.
> IZ> Конечно, не все запросы на твоем PL могут быть преобразованы в SQL.
> В этом я и вижу главную беду. Если подход объектный, то вообще никакой
> запрос не может быть преобразован в SQL, поскольку в ОП открытых полей в
> объекте быть не должно - все через get/set методы. Вот и получаем, что

Угу.

> каждый объект как-то "умеет" инициализировать свое состяние из хранилища, а
> дальше надо их обрабатывать уже самому PL. Хранилище в этом подходе не
> должно ничего обрабатывать. В гибридном подходе получаем, что подсистема
> выполнения запросов "размазана" между PL и СУБД.

Тебе кажется в сторону чистых ООСУБД смотреть надо и в сторону OQL.
Так вроде бы именно такой подход и используется - если надо, объект
загружается из хранилища и к его методам обращаются, и кажется,
на "родном" языке объекта, например, на С++.


Andrei N.Sobchuck

не прочитано,
28 янв. 2002 г., 07:37:3428.01.2002
Ilya Zvyagin wrote:
IZ> Тебе кажется в сторону чистых ООСУБД смотреть надо и в сторону OQL.
У "чистых ООСУБД", к сожалению, проблемы с запросами, имхо.
Gemstone - не оптимизирует запросы, в которых участвуют
полноценные выражения (вызовы методов и т.д.). Оптимизируеются только
запросы на "кастрированом" языке. Во-первых, запрос
должен быть только по данным (вызов методов не допустим),
во-вторых, допустимы только операции типа "больше", "меньше", "равно".
У Objectiviti (которая не клиент-серверная) еще
есть регэкспы для строковых типов.
Плюс в запросе у Objectiviti могут быть только поля "примитивных"
типов. Поле с неопределённым типом не может участвовать в условии запроса.

Тут товарисч за Cache вспоминал. Хотелось бы увидеть пример запроса,
который возвращает, набор объектов какого-то класса (любого).

IZ> Так вроде бы именно такой подход и используется - если надо, объект
IZ> загружается из хранилища и к его методам обращаются, и кажется,
IZ> на "родном" языке объекта, например, на С++.
В 1С такой подход используется ;)

Ilya Zvyagin

не прочитано,
28 янв. 2002 г., 10:21:4828.01.2002

"Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote in message news:msj33a...@server1.mart.cherkassy.ua...

> Тут товарисч за Cache вспоминал. Хотелось бы увидеть пример запроса,
> который возвращает, набор объектов какого-то класса (любого).

Cache в ряд ли можно назвать объектно ориентированной СУБД.

> IZ> Так вроде бы именно такой подход и используется - если надо, объект
> IZ> загружается из хранилища и к его методам обращаются, и кажется,
> IZ> на "родном" языке объекта, например, на С++.
> В 1С такой подход используется ;)

Ну так рулит же 1С по всей России !! А ежели это все еще на
какой-нибудь сервер приложений взгромоздить - во вещь получится !!

Andrei N.Sobchuck

не прочитано,
28 янв. 2002 г., 11:04:5228.01.2002
Ilya Zvyagin wrote:

IZ> "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote in message news:msj33a...@server1.mart.cherkassy.ua...

>> Тут товарисч за Cache вспоминал. Хотелось бы увидеть пример запроса,
>> который возвращает, набор объектов какого-то класса (любого).

IZ> Cache в ряд ли можно назвать объектно ориентированной СУБД.
Ошибся. На ихнем СДюке написано "Post-Relational".
Впрочем, мой вопрос остаётся в силе.
Я нашел пример на жабе, как вытащить один конкретный объект (по ключу?), но
не нашел, как _запросом_ вытащить несколько объектов.

>> IZ> Так вроде бы именно такой подход и используется - если надо, объект
>> IZ> загружается из хранилища и к его методам обращаются, и кажется,
>> IZ> на "родном" языке объекта, например, на С++.
>> В 1С такой подход используется ;)

IZ> Ну так рулит же 1С по всей России !! А ежели это все еще на
IZ> какой-нибудь сервер приложений взгромоздить - во вещь получится !!
Terminal Server и вперёд ;)

Ilya Zvyagin

не прочитано,
28 янв. 2002 г., 13:59:3728.01.2002

"Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote in message news:e8043a...@server1.mart.cherkassy.ua...

> IZ> Cache в ряд ли можно назвать объектно ориентированной СУБД.
> Ошибся. На ихнем СДюке написано "Post-Relational".

Написать можно что угодно. Это не значит, что оно так и есть.
Я, к сожалению, не могу ни доказать, ни опровергнуть , является
ли CACHE ООСУБД , поскольку специалистом ни по CACHE ни по ООСУБД
не являюсь. Но фактически у них есть некое ядро, которое хранит
данные, и к нему есть адаптеры SQL и его родного язычка. Есть
еще наверное и CORBA - адаптер, что-то они там такое говорили.
Это вобщем ничем не лучше / хуже мапинга ОО на релационную базу,
хотя конечно если ее сравнивать скажем с тем же MSSQL, то она
более ОО, чем MS.


Andrei N.Sobchuck

не прочитано,
28 янв. 2002 г., 14:09:5328.01.2002
Ilya Zvyagin wrote:

IZ> "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote in message news:e8043a...@server1.mart.cherkassy.ua...


>> IZ> Cache в ряд ли можно назвать объектно ориентированной СУБД.
>> Ошибся. На ихнем СДюке написано "Post-Relational".

IZ> Написать можно что угодно. Это не значит, что оно так и есть.
Тьфу :) _Я_ ошибся.

IZ> Я, к сожалению, не могу ни доказать, ни опровергнуть , является
IZ> ли CACHE ООСУБД , поскольку специалистом ни по CACHE ни по ООСУБД
Post-Relational != OO. Postgres вон тоже Post-Relational ;)

IZ> не являюсь. Но фактически у них есть некое ядро, которое хранит
IZ> данные, и к нему есть адаптеры SQL и его родного язычка. Есть
IZ> еще наверное и CORBA - адаптер, что-то они там такое говорили.
IZ> Это вобщем ничем не лучше / хуже мапинга ОО на релационную базу,
IZ> хотя конечно если ее сравнивать скажем с тем же MSSQL, то она
IZ> более ОО, чем MS.

Sergey Pratch

не прочитано,
28 янв. 2002 г., 15:15:5028.01.2002
Hi!

"Ilya Zvyagin" <z...@fct.ru> сообщил/сообщила в новостях следующее:
news:10122312...@gatekeeper.fct.ru...


> > В 1С такой подход используется ;)
>
> Ну так рулит же 1С по всей России !! А ежели это все еще на
> какой-нибудь сервер приложений взгромоздить - во вещь получится !!

Илья, не режь по живому. У меня есть контора, которую я админю, они на
1С переходят, не смотря на все мои уговоры. :-/


--
С уважением,
Сергей Прач

=================
Please, send you private mail to: s_pr...@mail.ru

Victor Metelitsa

не прочитано,
29 янв. 2002 г., 02:29:0229.01.2002

Vladimir Pavlikov wrote:

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

Есть человек A, у него в голове имеется определение "XXX - это YYY".
Есть человек B, у него в голове имеется определение "XXX - это ZZZ".
Вопрос: у кого из них определение правильней? А может, XXX - это на
самом деле TTT? Как мы будем это решать? Посмотреть в книжках? Их, в
конце концов, писали тоже люди, и они нередко противоречат друг другу;
разные вещи, называемые одними и теми же словами, обычное явление.

Ответ, по-моему, совершенно прост. Правильных и неправильных определений
не существует. Определение просто _дается_. В неформальных разговорах,
увы, оно обычно "за кадром", что приводит к многочисленным
недоразумениям, однако каждый раз формализовывать все эти вещи просто
немыслимо.

Итак. То, что _я_ называю ОО СУБД, это СУБД, где, кроме всего прочего,
все данные - это объекты, там вообще нет ничего, кроме объектов, эти
объекты знают друг о друге и посылают друг другу сообщения. Индексы,
стало быть, тоже объекты (разновидность коллекций).


--

Victor Metelitsa

не прочитано,
29 янв. 2002 г., 02:49:4029.01.2002

Andrei N.Sobchuck wrote:

> Ilya Zvyagin wrote:
> IZ> Кстати, TopLink - это что ? Как с GemStone соотносится ?
> Это O/R mapping framework.
> В текущий момент только для жабы.
> Не соотносится с GemStone никак.


Э, не надо. Когда я говорю TOPLink, я не имею в виду TL/J (ср. "I
invented the term Object-Oriented, and I can tell you I did not have C++
in mind." Alan Kay); он существует хотя бы потому, потому что я с ним
работаю; он реинкарнируется в GLORP'е не позднее, чем через год; у него
есть слой для работы с GemStone/S. Главная его польза - возможность
абстрагироваться от SQL СУБД, как будто работаем с ОО СУБД (SQL СУБД при
таком подходе становится "умной" дисковой подсистемой; при этом
реализация вполне эффективна).

Andrei N.Sobchuck

не прочитано,
29 янв. 2002 г., 03:24:4029.01.2002
Victor Metelitsa wrote:
VM> работаю; он реинкарнируется в GLORP'е не позднее, чем через год; у него
"Свежо предание..." :(
Хотя там реально не много доделать осталось.

--
Андрей Собчук
E-mail: and...@itware.com.ua

Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

Victor Metelitsa

не прочитано,
29 янв. 2002 г., 04:13:5229.01.2002

Andrei N.Sobchuck wrote:

> Ilya Zvyagin wrote:
> IZ> Тебе кажется в сторону чистых ООСУБД смотреть надо и в сторону OQL.
> У "чистых ООСУБД", к сожалению, проблемы с запросами, имхо.
> Gemstone - не оптимизирует запросы, в которых участвуют
> полноценные выражения (вызовы методов и т.д.). Оптимизируеются только
> запросы на "кастрированом" языке. Во-первых, запрос
> должен быть только по данным (вызов методов не допустим),
> во-вторых, допустимы только операции типа "больше", "меньше", "равно".

Эту штуку в реальной работе лучше понимать не как готовую СУБД, а как
framework. Её индексами лучше не пользоваться вообще (впрочем, это про
5.1.5; доки к 6.0 я еще не читал). Надо сделать свои собственные
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')

(запятая, напоминаю для незнающих, здесь конкатенация).
....

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


--

Andrei N.Sobchuck

не прочитано,
29 янв. 2002 г., 06:27:1929.01.2002
Victor Metelitsa wrote:
[...]
_сложно_. имхо.

--
Андрей Собчук
E-mail: and...@itware.com.ua

Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

Vladimir Pavlikov

не прочитано,
29 янв. 2002 г., 06:41:3829.01.2002

Hello! "Victor Metelitsa" <v...@cssc.tat.ru> wrote:

> Вопрос сводится к правильности определений. Вот маленькая задачка:
> Есть человек A, у него в голове имеется определение "XXX - это YYY".
> Есть человек B, у него в голове имеется определение "XXX - это ZZZ".
> Вопрос: у кого из них определение правильней? А может, XXX - это на
> самом деле TTT? Как мы будем это решать? Посмотреть в книжках? Их, в
> конце концов, писали тоже люди, и они нередко противоречат друг другу;
> разные вещи, называемые одними и теми же словами, обычное явление.
> Ответ, по-моему, совершенно прост. Правильных и неправильных определений
> не существует. Определение просто _дается_. В неформальных разговорах,
> увы, оно обычно "за кадром", что приводит к многочисленным
> недоразумениям, однако каждый раз формализовывать все эти вещи просто
> немыслимо.

Напоминаю, что сабж поднял именно ты. Определения "давать" не стал,
существование б.м. устойчивых определений не признаешь... Следует
понимать так, что флейм ты завел, чтобы "привести к многочисленным
недоразумениям"?
Я уже задавал вопрос, повторю :"Это что, неудачная попытка выкрутится
типа "я пошутил""? Ты на него не ответил, что-то про манию величия
начал плести. Наверное, это тебе очень близко... Сейчас опять сказал
глупость, а когда тебя прижали - начал рассуждать про определения.
Поздновато, не находишь? Да и как полноценная замена не катит. Что,
совсем не способен признавать собственные ошибки?

> Итак. То, что _я_ называю ОО СУБД, это СУБД, где, кроме всего прочего,
> все данные - это объекты, там вообще нет ничего, кроме объектов, эти
> объекты знают друг о друге и посылают друг другу сообщения. Индексы,
> стало быть, тоже объекты (разновидность коллекций).

Мне малоинтересны ООСУБД. Просто потому, что ОО я считаю ограниченной
технологией, к СУБД применимой в целом тоже ограниченно. Т.е. некая
часть ОО-шности будет полезной, но не более. Соответственно, "чистА
ООСУБД" - скорее всего, плохо. Поэтому обсуждать эту тему мне неинте-
ресно.
Но, так и быть - расскажи нам (чисто для интереса), как работает
механизм посылки сообщений между ОО-аналогами кортежей в твоей
любимой ООСУБД (которая, без сомнения - с твоей точки зрения -
существует).

Но если и на этот раз "сольешь", перейдя на общие (и к делу не от-
носящиеся) рассуждения - поставлю на тебя фильтр. Так дешевле будет...
--
Владимир Павликов.

Michael Demichev

не прочитано,
29 янв. 2002 г., 13:21:5829.01.2002
Привет, Victor!

Hамедни Victor Metelitsa писал Andrei N.Sobchuck:
VM> Эту штуку в реальной работе лучше понимать не как готовую СУБД, а как
VM> framework. Её индексами лучше не пользоваться вообще (впрочем, это про
VM> 5.1.5; доки к 6.0 я еще не читал). Hадо сделать свои собственные
VM> HomeCollection с собственной реализацией индексов (ими могут быть,
VM> например, словари). Что-то по этому поводу было на
VM> http://wiki.cs.uiuc.edu/.
Вот он клипперист. Все сделаем свое и будет тип-топ.

Берегите себя! Michael

Ilya Zvyagin

не прочитано,
29 янв. 2002 г., 09:07:2729.01.2002

" Sergey Pratch" <slto...@kot.poltava.ua> wrote in message > > Ну так рулит же 1С по всей России !! А ежели это все еще на

> > какой-нибудь сервер приложений взгромоздить - во вещь получится !!
>
> Илья, не режь по живому. У меня есть контора, которую я админю, они на
> 1С переходят, не смотря на все мои уговоры. :-/

Не, ну идея-то у них хорошая , в этом им нельзя отказать.
Исполнение, возможно, не очень.

Andrei N.Sobchuck

не прочитано,
29 янв. 2002 г., 09:29:5829.01.2002
Vladimir Pavlikov wrote:
VP> Но, так и быть - расскажи нам (чисто для интереса), как работает
VP> механизм посылки сообщений между ОО-аналогами кортежей в твоей

В любом Smalltalk-е (и, соответсвенно, Gemstone/S, как один из диалектов ST)
методы объектов вызываются при помощи отправки
этим объектам сообщений. Сообщение - читай запрос на действие.
Сообщения могут иметь параметры и всегда что то возвращают.
Все Smalltalk-и, оптимизируют отправку сообщений, путём
кеширования (читай индексирования) методов, которые должны исполнятся в ответ
на определённые сообщения.
Но ни один диалект (включая Gemstone/S)
не кеширует _результат_ _исполнения_ метода.
Таким образом, сейчас, Gemstone/S выполняет выборку
'aCollection select: [:eachElement |
eachElement someAttribute anotherCollection
anySatisfy: [ :a | a = myObject ] ]'
Путём последовательного перебора элементов коллекции и отправки
каждому элементу сообщения #someAttribute, результату -
сообщения #anotherCollection, затем #anySatisfy: .
Если бы разработчики подсуетились и реализовали кеширование результата
(индексацию объектов по результату метода),
приделали оптимизатор, то в результате бы имели реальную СУБД
_следующего_ поколения.
А так, приходится лепить всякие O/R mappings (ну или без них).
А всё для того, чтобы упростить работу серверу
(или разработчикам серверов).

Вот интересная аналогия.
http://www.chimu.com/publications/short/spms.html
http://wiki.cs.uiuc.edu/VisualWorks/SQL+Database+Metaphor+(%22Scenes%22+Thread)


PS Какашками друг в друга кидайтесь в другом месте ;)
Например мылом ;)

Vladimir Pavlikov

не прочитано,
29 янв. 2002 г., 10:04:5329.01.2002

Hello! "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote:

> VP> Но, так и быть - расскажи нам (чисто для интереса), как работает
> VP> механизм посылки сообщений между ОО-аналогами кортежей в твоей

> В любом Smalltalk-е (и, соответсвенно, Gemstone/S, как один из диалектов ST)

...


> Все Smalltalk-и, оптимизируют отправку сообщений, путём

...


> А так, приходится лепить всякие O/R mappings (ну или без них).
> А всё для того, чтобы упростить работу серверу
> (или разработчикам серверов).

1. Вопрос был вполне _конкретный_.
2. Относящийся не к ST, и не к O/R mappings, а к "ООСУБД".
3. Не тебе, а тому, кто утверждает о существовании ООСУБД.

Ну а нафига ты это все написал? К вопросу не относящееся...
Или ради нижеидущего :


> PS Какашками друг в друга кидайтесь в другом месте ;)

Ну так и адресуй кому следует, для которого все г.
Можешь мылом.

Andrei N.Sobchuck

не прочитано,
29 янв. 2002 г., 10:38:0129.01.2002
Vladimir Pavlikov wrote:
VP> 1. Вопрос был вполне _конкретный_.
Ты б еще спросил как процессор команды выполняет.

VP> 2. Относящийся не к ST, и не к O/R mappings, а к "ООСУБД".
Нет _принципиальной_ разницы.

VP> 3. Не тебе, а тому, кто утверждает о существовании ООСУБД.
Ну это ж эха. Личная переписка - мылом.

VP> Ну а нафига ты это все написал? К вопросу не относящееся...
относящееся. Перечитай еще раз.

VP> Или ради нижеидущего :


>> PS Какашками друг в друга кидайтесь в другом месте ;)

VP> Ну так и адресуй кому следует, для которого все г.
VP> Можешь мылом.
без меня

Tolik Tentser

не прочитано,
29 янв. 2002 г., 11:15:1129.01.2002