Проблемы persistent layers
Serguei Tarassov
Хочется обсудить проблему, связанную с управлением долгоживущими объектами.
Поскольку создать объект где-то в приложении, проинициализировать его
данными из БД - это не фокус, а ловкость рук и "мошенство" всяких
корпоративных (а потому нестандартных) persistent layers AKA Object
Relational Framework (про CORBA пока разговора нет, как и массовых всех
устраивающих реализаций PersistenService). Но фокусы начинаются, когда надо
этими объектами управлять, а именно передавать дальше и "выше" по
_произвольным_ запросам - это требование к любой ИС.
Итак, предлагаемые решения представляют собой:
1. Надстройку/среду/фреймворк над уже существующими СУБД, как правило
реляционного типа
2. Так называемые "объектные" СУБД.
Начнем с первого.
Сразу на ум приходит древняя аналогия со встроенным SQL в файл-серверных
приложениях типа фокспро/клиппер: там SQL разбирался подсистемой приложения,
прозрачной для программиста, превращался во внутренние циклы, поиски и и
сканы по файлам и выполнялся с использованием примитовов разделяемого
доступа к файлам конкретной сетевой ОС. Проблемы такого подхода не обсуждаем
(транзакционнность-то и в нетвари можно было обеспечивать на уровне файлов),
важен сам принцип.
Ситуация в надстройке/фреймворке принципиально та же. Имеем некий
_нестандартный_ язык запросов к объектам. В общем случае он интерпретирует
запрос на этом языке в сиквельные запросы, вытаскивает датасеты,
инициализирует по ним объекты и далее фильтрует уже их если, например, в
запросе используется вызов метода (проблемы тут тоже пока не обсуждаем,
например, если в этом методе еще один запрос "спрятан").
Честно говоря, даже при том, что это дает более высокий уровень абстракции,
такие механизмы работы с БД со стороны надстройки/фреймворка вызывают при
взгляде "с низов" (то есть "из БД" на клиента) серъезные опасения в здравом
уме этого клиента.
А что думает съезд по поводу клиента?
--
с коминтерновским приветом участникам съезда
тов. Сергей (Тарасов)
mailto:se...@arbinada.com
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Vladimir Pavlikov
Hello! "Serguei Tarassov" <tem...@arbinada.com> wrote:
> Честно говоря, даже при том, что это дает более высокий уровень абстракции,
> такие механизмы работы с БД со стороны надстройки/фреймворка вызывают при
> взгляде "с низов" (то есть "из БД" на клиента) серъезные опасения в здравом
> уме этого клиента.
> А что думает съезд по поводу клиента?
"Съезд" думает по разному : Метелица, похоже, считает это вершиной мироздания,
я склоняюсь к твоему мнению, а есть (т.е. может быть )еще куча промежуточных...
Только такие вопросы голосованием не решаются.
--
Владимир Павликов.
Andrei N.Sobchuck
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 года, отправленного тов. Andrei
N.Sobchuck по поводу предыдущего запроса тов. "Vladimir Pavlikov"
<p...@soil.msu.ru> со всей партийной прямотой отвечаем:
AN> Такие, это какие?
Читем исходное посьмо.
AN> Вообще то, Метелица за объектную (без кавычек) СУБД.
AN> (Он в пример приводит Gemstone/S - www.gemstone.com).
Я тоже не против. А кавычки уберем, когда они смогут хотя бы теоретически
составлять оптимальный план выполнения декларативного объектного запроса (с
участием в нем вызовов методов объектов).
Andrei N.Sobchuck
AN>> Такие, это какие?
ST> Читем исходное посьмо.
Это ты про выборку данных и "дофильтровывание" на клиенте?
По-твоему, это проблема "object-relational frameworks"?
AN>> Вообще то, Метелица за объектную (без кавычек) СУБД.
AN>> (Он в пример приводит Gemstone/S - www.gemstone.com).
ST> Я тоже не против. А кавычки уберем, когда они смогут хотя бы теоретически
ST> составлять оптимальный план выполнения декларативного объектного запроса (с
ST> участием в нем вызовов методов объектов).
А какие RDBMS оптимизируют запросы с функциями?
Serguei Tarassov
На запрос в комитет от 20 января 2002 года, отправленного тов. Andrei
<tem...@arbinada.com> со всей партийной прямотой отвечаем:
AN> Это ты про выборку данных и "дофильтровывание" на клиенте?
AN> По-твоему, это проблема "object-relational frameworks"?
Не выборка, а выборки, причем в одной атомарной транзакции и при отсутствии
каких-либо критериев оценки порядка проведения выборок и "дофильтрации" (а
вдруг как "дофильтрация" окажется на 100% селективна), _требущей_
инициализации объектов (весьма недешевая операция) по этим выборкам.
AN> А какие RDBMS оптимизируют запросы с функциями?
В RDBMS функция не является артефактом модели. В ООП метод - является.
Andrei N.Sobchuck
AN>> Это ты про выборку данных и "дофильтровывание" на клиенте?
AN>> По-твоему, это проблема "object-relational frameworks"?
ST> каких-либо критериев оценки порядка проведения выборок и "дофильтрации" (а
ST> вдруг как "дофильтрация" окажется на 100% селективна), _требущей_
Честно говоря, не понял. :) Ну, да, ладно :)
ST> инициализации объектов (весьма недешевая операция) по этим выборкам.
AN>> А какие RDBMS оптимизируют запросы с функциями?
ST> В RDBMS функция не является артефактом модели. В ООП метод - является.
А откуда требование соптимизировать то, что невозможно соптимизировать
даже теоретически?
Eugene Karataev
> Хочется обсудить проблему, связанную с управлением долгоживущими
объектами.
> Поскольку создать объект где-то в приложении, проинициализировать его
> данными из БД - это не фокус, а ловкость рук и "мошенство" всяких
> корпоративных (а потому нестандартных) persistent layers AKA Object
> Relational Framework (про CORBA пока разговора нет, как и массовых всех
> устраивающих реализаций PersistenService). Но фокусы начинаются, когда
надо
> этими объектами управлять, а именно передавать дальше и "выше" по
> _произвольным_ запросам - это требование к любой ИС.
> Итак, предлагаемые решения представляют собой:
> 1. Надстройку/среду/фреймворк над уже существующими СУБД, как правило
> реляционного типа
> 2. Так называемые "объектные" СУБД.
Да...
Почитал я тут про ужасы реляционок, и как в анекдоте -
хорошо, хорошо, хорошо что у меня этого нет.
Короче, ставь Cache и забудь проблемы.
Евгений.
Vladimir Pavlikov
Hello! "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote:
> >> Честно говоря, даже при том, что это дает более высокий уровень абстракции,
> >> такие механизмы работы с БД со стороны надстройки/фреймворка вызывают при
> Такие, это какие?
Вопросы по тексту желательно адресовать автору текста.
> Вообще то, Метелица за объектную (без кавычек) СУБД.
> (Он в пример приводит Gemstone/S - www.gemstone.com).
Таких в природе не существует, Gemstone не исключение.
Соответственно, его предпочтения я оценивал по его же
текстам, к Gemstone отношения не имеющим. И - не будем
о персоналях. Зачем из ремарки пытаться раздуть [никому
не интересную] тему?
--
Владимир Павликов.
Ilya Zvyagin
"Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote in message news:eudg2a...@server1.mart.cherkassy.ua...
> AN>> А какие RDBMS оптимизируют запросы с функциями?
> ST> В RDBMS функция не является артефактом модели. В ООП метод - является.
> А откуда требование соптимизировать то, что невозможно соптимизировать
> даже теоретически?
А на кой фиг тогда ООСУБД нужны, если они такие же как и реляционные ?
Ilya Zvyagin
"Serguei Tarassov" <tem...@arbinada.com> wrote in message news:a2a3hb$t6n$1...@host.talk.ru...
> Хочется обсудить проблему, связанную с управлением долгоживущими объектами.
(одним словом просто).
> Но фокусы начинаются, когда надо этими объектами управлять, а именно передавать
> дальше и "выше" по
> _произвольным_ запросам - это требование к любой ИС.
Сергей, ты не мог бы привести пример такой "передачи" , а то я
что-то никак не могу понять, о чем речь.
Serguei Tarassov
На запрос в комитет от 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
IZ> "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote in message news:eudg2a...@server1.mart.cherkassy.ua...
>> AN>> А какие RDBMS оптимизируют запросы с функциями?
>> ST> В RDBMS функция не является артефактом модели. В ООП метод - является.
>> А откуда требование соптимизировать то, что невозможно соптимизировать
>> даже теоретически?
IZ> А на кой фиг тогда ООСУБД нужны, если они такие же как и реляционные ?
То есть, единственное, чего тебе не хватает в СУБД, это оптимизации
запросов с процедурами?
Хотя, твой вопрос хороший :)
Victor Metelitsa
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
"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
"Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote in message news:qpml2a...@server1.mart.cherkassy.ua...
> >> А откуда требование соптимизировать то, что невозможно соптимизировать
> >> даже теоретически?
> IZ> А на кой фиг тогда ООСУБД нужны, если они такие же как и реляционные ?
> То есть, единственное, чего тебе не хватает в СУБД, это оптимизации
> запросов с процедурами?
В РСУБД мне не хватает _МЕТОДОВ_ объектов. Но метод подразумевает под собой
инкапсуляцию данных, т.е. сокрытие внутренней структуры объектов и его
данных. Производительность РСУБД строится в основном на применении индексов,
т.е. специальной организации хранящихся данных. Тут как бы противоречие
намечается - как данные организовывать , если они скрыты ? Вот и получается,
что никак. А ежели и ООСУБД этого не умеют, то их применение в чем-то отличном
от организации тривиального persistent storage для объектов приложения
достаточно ограничено, т.е. попросту ООСУБД слабо полезны в, скажем,
бизнес-задачах. Я буду лучше использовать РСУБД и OOtoR mapping.
Ilya Zvyagin
"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
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
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
IZ> В РСУБД мне не хватает _МЕТОДОВ_ объектов. Но метод подразумевает под собой
IZ> инкапсуляцию данных, т.е. сокрытие внутренней структуры объектов и его
IZ> данных. Производительность РСУБД строится в основном на применении индексов,
IZ> т.е. специальной организации хранящихся данных. Тут как бы противоречие
IZ> намечается - как данные организовывать , если они скрыты ? Вот и получается,
IZ> что никак. А ежели и ООСУБД этого не умеют, то их применение в чем-то отличном
Если метод не имеет побочных эфектов, и не принимает параметров, то проиндексировать,
имхо, можно. (indexed views делают именно это. Так?)
IZ> от организации тривиального persistent storage для объектов приложения
IZ> достаточно ограничено, т.е. попросту ООСУБД слабо полезны в, скажем,
IZ> бизнес-задачах. Я буду лучше использовать РСУБД и OOtoR mapping.
Я не уверен что проще - использовать OOtoR или нет.
btw, как OOtoR соотносится с использованием SP?
Лучше без SP совсем или изредка можна?
Ilya Zvyagin
"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
"Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote in message news:bqlm2a...@server1.mart.cherkassy.ua...
> btw, как OOtoR соотносится с использованием SP?
Никак. Обсолютно ортогонально, как говориться.
> Лучше без SP совсем или изредка можна?
Можно вообще с SP , можно вообще без SP, можно и так, и так.
Victor Metelitsa
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
Ilya Zvyagin wrote:
Не-е-е. Плохому OOtoR (типа Object Extender) действительно без разницы
(там ведь и SQL-запросы вручную приходится писать), хорошему (TOPLink
или в будущем - GLORP) - разница огромная. TOPLink ведь создает
SQL-запросы сам; огромное количество вариаций; для каждого возможного
SQL создать процедуру и описать ее в дескрипторах TOPLink'а - нет, это
практически невозможно.
--
Vladimir Pavlikov
Hello! "Victor Metelitsa" <v...@cssc.tat.ru> wrote:
> Пример: X связан с Y отнощением 1:N. Типичное для РСУБД решение - две таблицы,
foreign key, без индекса работа немыслима (чудовищные тормоза). У ОО СУБД экземпляр X
попросту содержит ссылку на коллекцию экземпляров Y, с которыми связан. Таким
образом, мы получаем искомые Y немедленно, без поиска по индексам.
Это механизм сетевых субд. Никакого отношения к ОО-шности не имеет.
--
Владимир Павликов.
Andrei N.Sobchuck
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
Vladimir Pavlikov wrote:
> Hello! "Victor Metelitsa" <v...@cssc.tat.ru> wrote:
>
>
>>Пример: X связан с Y отнощением 1:N. Типичное для РСУБД решение - две таблицы,
>>
> foreign key, без индекса работа немыслима (чудовищные тормоза). У ОО СУБД экземпляр X
> попросту содержит ссылку на коллекцию экземпляров Y, с которыми связан. Таким
> образом, мы получаем искомые Y немедленно, без поиска по индексам.
>
> Это механизм сетевых субд. Никакого отношения к ОО-шности не имеет.
Я говорю о том, как должна быть устроена ОО СУБД. Как, спрашивается, ОО
СУБД (в которых, разумеется, есть только объекты и ничего кроме
объектов) могут быть иначе устроены? Скопление объектов - внутри
коллекции (это следует по определению коллекции, таблица один из частных
случаев коллекции). То, что похожий механизм есть в сетевых СУБД, не
имеет никакого отношения к делу.
--
Vladimir Pavlikov
Ну и как с тобой вести обсуждение? Сколько раз убеждался - стоит
только затронуть "священных коров" - и соображалка начисто отказы-
вает даже тем, у кого она есть :(
Еще раз - ОО - это _методология_, а провязка ссылок - это _реализа-
ционный_ механизм. Можешь почитать о нем в спецификациях CODASYL,
в разделе, посвященном механизмам организации наборов - это один
из базовых механизмов сети. Еще можешь поискать его же в ОО-источ-
никах. Только не в доке по _конкретной реализации_ "ООСУБД", в
которой писано и про механизмы реализации. Если (ну а вдруг?)
найдешь - очччень интересно будет познакомится, уж не откажи...
Ну а то, что ровно то же самое можно получить использованием
тех же индексов (т.е. "традиционными" реализациями) ОО-шности не
прибавит, и не убавит... Так что - см. выше.
--
Владимир Павликов.
Ilya Zvyagin
"Victor Metelitsa" <v...@cssc.tat.ru> wrote in message news:3C4FF566...@cssc.tat.ru...
> или в будущем - GLORP) - разница огромная. TOPLink ведь создает
> SQL-запросы сам; огромное количество вариаций; для каждого возможного
> SQL создать процедуру и описать ее в дескрипторах TOPLink'а - нет, это
> практически невозможно.
Но если МОЖНО хотя бы в некоторых случаях, тогда, я думаю, это хорошо.
Кстати, TopLink - это что ? Как с GemStone соотносится ?
Ilya Zvyagin
"Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote in message
> Я почему спрашиваю - в SP обычно держат логику.
> С объектами - это ни к чему. Так?
Логика в СП , возможно, ни к чему. СП - вожможно и к чему-то
пригодится.
Andrei N.Sobchuck
IZ> Кстати, TopLink - это что ? Как с GemStone соотносится ?
Это O/R mapping framework.
В текущий момент только для жабы.
Не соотносится с GemStone никак.
Serguei Tarassov
На запрос в комитет от 23 января 2002 года, отправленного тов. Ilya Zvyagin
по поводу предыдущего запроса тов. Serguei Tarassov со всей партийной
прямотой отвечаем:
IZ> Ты что, Сергей, ностальгией по коммунизму заболел ?
Пребывание на родине "Интернационала" располагает :-) Админ конторы, с
которой я сейчас сотрудничаю (мужик лет 50, кстати) пропел мне пару куплетов
в оригинале. Я пока только припев выучил - он простой :-)
IZ> А по моим представлениям это нужно запихать в РСУБД в виде запроса.
IZ> Конечно, не все запросы на твоем PL могут быть преобразованы в SQL.
В этом я и вижу главную беду. Если подход объектный, то вообще никакой
запрос не может быть преобразован в SQL, поскольку в ОП открытых полей в
объекте быть не должно - все через get/set методы. Вот и получаем, что
каждый объект как-то "умеет" инициализировать свое состяние из хранилища, а
дальше надо их обрабатывать уже самому PL. Хранилище в этом подходе не
должно ничего обрабатывать. В гибридном подходе получаем, что подсистема
выполнения запросов "размазана" между PL и СУБД.
Ilya Zvyagin
"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
IZ> Тебе кажется в сторону чистых ООСУБД смотреть надо и в сторону OQL.
У "чистых ООСУБД", к сожалению, проблемы с запросами, имхо.
Gemstone - не оптимизирует запросы, в которых участвуют
полноценные выражения (вызовы методов и т.д.). Оптимизируеются только
запросы на "кастрированом" языке. Во-первых, запрос
должен быть только по данным (вызов методов не допустим),
во-вторых, допустимы только операции типа "больше", "меньше", "равно".
У Objectiviti (которая не клиент-серверная) еще
есть регэкспы для строковых типов.
Плюс в запросе у Objectiviti могут быть только поля "примитивных"
типов. Поле с неопределённым типом не может участвовать в условии запроса.
Тут товарисч за Cache вспоминал. Хотелось бы увидеть пример запроса,
который возвращает, набор объектов какого-то класса (любого).
IZ> Так вроде бы именно такой подход и используется - если надо, объект
IZ> загружается из хранилища и к его методам обращаются, и кажется,
IZ> на "родном" языке объекта, например, на С++.
В 1С такой подход используется ;)
Ilya Zvyagin
"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
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
"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
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
"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
Vladimir Pavlikov wrote:
Вопрос сводится к правильности определений. Вот маленькая задачка:
Есть человек A, у него в голове имеется определение "XXX - это YYY".
Есть человек B, у него в голове имеется определение "XXX - это ZZZ".
Вопрос: у кого из них определение правильней? А может, XXX - это на
самом деле TTT? Как мы будем это решать? Посмотреть в книжках? Их, в
конце концов, писали тоже люди, и они нередко противоречат друг другу;
разные вещи, называемые одними и теми же словами, обычное явление.
Ответ, по-моему, совершенно прост. Правильных и неправильных определений
не существует. Определение просто _дается_. В неформальных разговорах,
увы, оно обычно "за кадром", что приводит к многочисленным
недоразумениям, однако каждый раз формализовывать все эти вещи просто
немыслимо.
Итак. То, что _я_ называю ОО СУБД, это СУБД, где, кроме всего прочего,
все данные - это объекты, там вообще нет ничего, кроме объектов, эти
объекты знают друг о друге и посылают друг другу сообщения. Индексы,
стало быть, тоже объекты (разновидность коллекций).
--
Victor Metelitsa
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
VM> работаю; он реинкарнируется в GLORP'е не позднее, чем через год; у него
"Свежо предание..." :(
Хотя там реально не много доделать осталось.
--
Андрей Собчук
E-mail: and...@itware.com.ua
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Victor Metelitsa
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
[...]
_сложно_. имхо.
--
Андрей Собчук
E-mail: and...@itware.com.ua
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Vladimir Pavlikov
Hello! "Victor Metelitsa" <v...@cssc.tat.ru> wrote:
> Вопрос сводится к правильности определений. Вот маленькая задачка:
> Есть человек A, у него в голове имеется определение "XXX - это YYY".
> Есть человек B, у него в голове имеется определение "XXX - это ZZZ".
> Вопрос: у кого из них определение правильней? А может, XXX - это на
> самом деле TTT? Как мы будем это решать? Посмотреть в книжках? Их, в
> конце концов, писали тоже люди, и они нередко противоречат друг другу;
> разные вещи, называемые одними и теми же словами, обычное явление.
> Ответ, по-моему, совершенно прост. Правильных и неправильных определений
> не существует. Определение просто _дается_. В неформальных разговорах,
> увы, оно обычно "за кадром", что приводит к многочисленным
> недоразумениям, однако каждый раз формализовывать все эти вещи просто
> немыслимо.
Напоминаю, что сабж поднял именно ты. Определения "давать" не стал,
существование б.м. устойчивых определений не признаешь... Следует
понимать так, что флейм ты завел, чтобы "привести к многочисленным
недоразумениям"?
Я уже задавал вопрос, повторю :"Это что, неудачная попытка выкрутится
типа "я пошутил""? Ты на него не ответил, что-то про манию величия
начал плести. Наверное, это тебе очень близко... Сейчас опять сказал
глупость, а когда тебя прижали - начал рассуждать про определения.
Поздновато, не находишь? Да и как полноценная замена не катит. Что,
совсем не способен признавать собственные ошибки?
> Итак. То, что _я_ называю ОО СУБД, это СУБД, где, кроме всего прочего,
> все данные - это объекты, там вообще нет ничего, кроме объектов, эти
> объекты знают друг о друге и посылают друг другу сообщения. Индексы,
> стало быть, тоже объекты (разновидность коллекций).
Мне малоинтересны ООСУБД. Просто потому, что ОО я считаю ограниченной
технологией, к СУБД применимой в целом тоже ограниченно. Т.е. некая
часть ОО-шности будет полезной, но не более. Соответственно, "чистА
ООСУБД" - скорее всего, плохо. Поэтому обсуждать эту тему мне неинте-
ресно.
Но, так и быть - расскажи нам (чисто для интереса), как работает
механизм посылки сообщений между ОО-аналогами кортежей в твоей
любимой ООСУБД (которая, без сомнения - с твоей точки зрения -
существует).
Но если и на этот раз "сольешь", перейдя на общие (и к делу не от-
носящиеся) рассуждения - поставлю на тебя фильтр. Так дешевле будет...
--
Владимир Павликов.
Michael Demichev
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
" Sergey Pratch" <slto...@kot.poltava.ua> wrote in message > > Ну так рулит же 1С по всей России !! А ежели это все еще на
> > какой-нибудь сервер приложений взгромоздить - во вещь получится !!
>
> Илья, не режь по живому. У меня есть контора, которую я админю, они на
> 1С переходят, не смотря на все мои уговоры. :-/
Не, ну идея-то у них хорошая , в этом им нельзя отказать.
Исполнение, возможно, не очень.
Andrei N.Sobchuck
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
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
VP> 1. Вопрос был вполне _конкретный_.
Ты б еще спросил как процессор команды выполняет.
VP> 2. Относящийся не к ST, и не к O/R mappings, а к "ООСУБД".
Нет _принципиальной_ разницы.
VP> 3. Не тебе, а тому, кто утверждает о существовании ООСУБД.
Ну это ж эха. Личная переписка - мылом.
VP> Ну а нафига ты это все написал? К вопросу не относящееся...
относящееся. Перечитай еще раз.
VP> Или ради нижеидущего :
>> PS Какашками друг в друга кидайтесь в другом месте ;)
VP> Ну так и адресуй кому следует, для которого все г.
VP> Можешь мылом.
без меня
Tolik Tentser
В чреве акулы, пойманной Tue, 29 Jan 2002 11:41:38 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: Проблемы persistent
layers':
>Мне малоинтересны ООСУБД. Просто потому, что ОО я считаю ограниченной
>технологией, к СУБД применимой в целом тоже ограниченно. Т.е. некая
>часть ОО-шности будет полезной, но не более. Соответственно, "чистА
>ООСУБД" - скорее всего, плохо. Поэтому обсуждать эту тему мне неинте-
>ресно.
К слову сказать - забавно было почитать последнее издание Дейта. Там
он начинает рассуждать о ООСУБД. И вышел пшик. Получилась глава о
базовых принципах ОО (инкапсуляция, наследование...), на уровне
наиболее хреновых на эту тему книжек и никаких практически параллелей
с БД и тем, как это все к БД вообще прикрутить. Максимум чего он родил
- предложил (кривой донельзя, на мой личный взгляд) синтаксис для
описания ОО типов.
Bye ...
Тенцер А.Л.
to...@katren.nsk.ru
ICQ 15925834
Vladimir Pavlikov
Hello! "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote:
> VP> 2. Относящийся не к ST, и не к O/R mappings, а к "ООСУБД".
> Нет _принципиальной_ разницы.
Она именно принципиальна. Обертка и СУБД - сильно отличаются.
> без меня
"Ты сам не знаешь, чего хочешь"(С) :)
Vladimir Pavlikov
Hello! "Tolik Tentser" <to...@katren.ru> wrote:
> К слову сказать - забавно было почитать последнее издание Дейта. Там
> он начинает рассуждать о ООСУБД. И вышел пшик. Получилась глава о
> базовых принципах ОО (инкапсуляция, наследование...), на уровне
> наиболее хреновых на эту тему книжек и никаких практически параллелей
> с БД и тем, как это все к БД вообще прикрутить. Максимум чего он родил
> - предложил (кривой донельзя, на мой личный взгляд) синтаксис для
> описания ОО типов.
У меня сложилось такое же впечатление.
Andrei N.Sobchuck
VP> Hello! "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote:
>> VP> 2. Относящийся не к ST, и не к O/R mappings, а к "ООСУБД".
>> Нет _принципиальной_ разницы.
VP> Она именно принципиальна. Обертка и СУБД - сильно отличаются.
Смаллтоковый образ - это именно ООБД, а не обёртка.
В традиционном исполнении - in memory.
Чего не хватает, чтобы отказаться от РСУБД в качестве
подложки для хранения данных, я написал.
То, что сейчас _реально_ есть - это конь, уже не в вакууме, но
всё еще сферический.
Serguei Tarassov
На запрос в комитет от 29 января 2002 года, отправленного тов. Victor
Metelitsa по поводу предыдущего запроса тов. Andrei N.Sobchuck со всей
партийной прямотой отвечаем:
VM> год; у него есть слой для работы с GemStone/S. Главная его польза -
VM> возможность абстрагироваться от SQL СУБД, как будто работаем с ОО
VM> СУБД (SQL СУБД при таком подходе становится "умной" дисковой
VM> подсистемой; при этом реализация вполне эффективна).
Вот здесь мне и кажется, что абстрагирование от SQL является ошибкой.
Почему бы не абстрагироваться сразу от "умной" подсистемы хранения? Зачем
тебе там сиквел: данные читать и записывать? Так ведь декларативный сиквел
для этого не нужен, всего несколько императивных функций хватит.
--
с коминтерновским приветом участникам съезда
тов. Сергей (Тарасов)
mailto:se...@arbinada.com
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Serguei Tarassov
На запрос в комитет от 29 января 2002 года, отправленного тов. Andrei
N.Sobchuck по поводу предыдущего запроса тов. "Vladimir Pavlikov"
<p...@soil.msu.ru> со всей партийной прямотой отвечаем:
AN> Таким образом, сейчас, Gemstone/S выполняет выборку 'aCollection
AN> select: [:eachElement |
AN> eachElement someAttribute anotherCollection
AN> anySatisfy: [ :a | a = myObject ] ]'
AN> Путём последовательного перебора элементов коллекции и отправки
AN> каждому элементу сообщения #someAttribute, результату -
AN> сообщения #anotherCollection, затем #anySatisfy: .
AN> Если бы разработчики подсуетились и реализовали кеширование
Ну конечно, просто супероптимизация - вместо full scan по дискам - то же по
мозгам :-)
AN> результата (индексацию объектов по результату метода), приделали
AN> оптимизатор, то в результате бы имели реальную СУБД _следующего_
Оптимизатор? А он теоретически возможен?
AN> поколения.
AN> А так, приходится лепить всякие O/R mappings (ну или без них).
Вот они-то и вызывают у меня чувство глубокого неудовлетворения.
AN> А всё для того, чтобы упростить работу серверу (или разработчикам
AN> серверов).
Скорее, усложнить. Упростить получается только на примитивных OLTP
приложениях. Первый же интерфейс пользователя в стиле "хочу делать
разнообразные выборки по доступным критериям и их комбинациям" должен будет
обходить этот mappings далеко и стороной.
AN> --
AN> Андрей Собчук
AN> E-mail: and...@itware.com.ua
--
с коминтерновским приветом участникам съезда
тов. Сергей (Тарасов)
mailto:se...@arbinada.com
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Andrei N.Sobchuck
ST> Оптимизатор? А он теоретически возможен?
Что мешает закешировать (проиндексировать по...)
вызов и результат процедуры без параметров и побочных эффектов?
AN>> А всё для того, чтобы упростить работу серверу (или разработчикам
AN>> серверов).
ST> Скорее, усложнить. Упростить получается только на примитивных OLTP
ST> приложениях. Первый же интерфейс пользователя в стиле "хочу делать
ST> разнообразные выборки по доступным критериям и их комбинациям" должен будет
ST> обходить этот mappings далеко и стороной.
Всё зависит от mappings ;)
Serguei Tarassov
На запрос в комитет от 29 января 2002 года, отправленного тов. Andrei
<tem...@arbinada.com> со всей партийной прямотой отвечаем:
ST>> Оптимизатор? А он теоретически возможен?
AN> Что мешает закешировать (проиндексировать по...)
AN> вызов и результат процедуры без параметров и побочных эффектов?
Вызов процедуры без параметров? :-))
Знаешь, единственную процедуру, которую вообще можно закешировать это вывод
"Неllo, world!" в возвращаемую строку :-) Вызов метода всегда приводит к
изменению состояния объекта, от которого, в свою очередь зависят результаты
вызовов других методов. И т.д.
ST>> Скорее, усложнить. Упростить получается только на примитивных OLTP
ST>> приложениях. Первый же интерфейс пользователя в стиле "хочу делать
ST>> разнообразные выборки по доступным критериям и их комбинациям"
ST>> должен будет обходить этот mappings далеко и стороной.
AN> Всё зависит от mappings ;)
Если методов в запросах нет, а одни поля - то маппинг возможен. Однако, это
структурный подход, а не объектный, а потому интереса не представляет.
Andrei N.Sobchuck
ST>>> Оптимизатор? А он теоретически возможен?
AN>> Что мешает закешировать (проиндексировать по...)
AN>> вызов и результат процедуры без параметров и побочных эффектов?
ST> Знаешь, единственную процедуру, которую вообще можно закешировать это вывод
ST> "Неllo, world!" в возвращаемую строку :-) Вызов метода всегда приводит к
Ну. Indexed views существуют.
ST> изменению состояния объекта, от которого, в свою очередь зависят результаты
Не всегда ;)
Если после выполнения запроса состояние объекта изменится и он
перестанет удовлетворять условию запроса, то это... ммм...
глупая ситуация.
ST> вызовов других методов. И т.д.
ST>>> Скорее, усложнить. Упростить получается только на примитивных OLTP
ST>>> приложениях. Первый же интерфейс пользователя в стиле "хочу делать
ST>>> разнообразные выборки по доступным критериям и их комбинациям"
ST>>> должен будет обходить этот mappings далеко и стороной.
AN>> Всё зависит от mappings ;)
ST> Если методов в запросах нет, а одни поля - то маппинг возможен. Однако, это
ST> структурный подход, а не объектный, а потому интереса не представляет.
Не объектный, но и не структурный (абсолютно).
[я перестал понимать, что тебе не нравится.
Предлагаю закруглиться.]
Belugin Max
среда, 30 января 2002 г., you wrote:
ST> "Неllo, world!" в возвращаемую строку :-) Вызов метода всегда приводит к
ST> изменению состояния объекта, от которого, в свою очередь зависят результаты
ST> вызовов других методов. И т.д.
Не всегда.
--
Best regards,
Max
http://belugin.newmail.ru
ICQ:9406811
Dmitry V. Liseev
Hi!
> >> Тут товарисч за Cache вспоминал. Хотелось бы увидеть пример запроса,
> >> который возвращает, набор объектов какого-то класса (любого).
>
> IZ> Cache в ряд ли можно назвать объектно ориентированной СУБД.
> Ошибся. На ихнем СДюке написано "Post-Relational".
> Впрочем, мой вопрос остаётся в силе.
> Я нашел пример на жабе, как вытащить один конкретный объект (по ключу?),
> но
> не нашел, как _запросом_ вытащить несколько объектов.
В КАШЕ есть разные виды запросов.
1. Если тебя интересует именно SQL, то любой запрос на встроенном SQL
транслируется оптимизатором на встроенный язык (ObjectScript), а затем
в некий аналог жабовского байт-кода. Если этот запрос встроен в код метода,
то это происходит на этапе компилляции метода. Если этот запрос пришел
по ODBC, это делается в рантайме и кешируется. Поскольку в описании
объекта ты можешь указать, как именно хранить объект и по каким свойствам
индексировать, то оптимизатор эту информацию имеет уже на этапе компилляции
кода. Созданный оптимизатором код можно всегда посмотреть и поправить
ручками. Этот код запроса, сгенерированный оптимизатором шарится по диску
(не создавая в памяти экземпляров объектов, что очень быстро) и выдает
тебе нужные данные:
&sql(SELECT LastName INTO :LastName FROM Person WHERE FirstName='Dennis')
Если объекты индексированы по полю FirstName, то никакого фуллскана
не происходит. Если тебе нужно не только LastName, а весь объект, то
просто находишь идентификаторы нужных объектов и создаешь в памяти
их экземпляры:
&sql(SELECT ID INTO :id FROM Person WHERE FirstName='Dennis')
Set obj=##class(Person).%OpenId(id)
Опять-же нужна индексация по полю FirstName. Если индекс выключить и
перекомпиллировать этот код, то оптимизатор создаст код, который будет
действительно делать фуллскан.
Если нужен не один, а несколько объектов - никаких проблем.
Просто создаешь курсор и в цикле поднимаешь в память найденные
объекты, после чего возвращаешь их одним списком на клиента. Клиенту
уже приезжает коллекция IDispatch интерфейсов на эти объекты.
New id,ChildId,SQLCODE,ChildDesignsList,Child
; Получим идентификатор текущего объекта
Set id=..%Id(),ChildDesignsList=""
; Запросим все дочерние объекты, которые на нас ссылаются.
&sql(DECLARE ChildDesigns CURSOR FOR SELECT ID INTO :ChildId
FROM Design
WHERE ParentDesign=:id)
&sql(OPEN ChildDesigns)
; Поднимем в память экземпляры объектов и засунем их в список.
For &sql(FETCH ChildDesigns) Quit:SQLCODE'=0 Do
. Set Child=##class(Design).%OpenId(ChildId)
. Set ChildDesignsList=ChildDesignsList_$ListBuild(Child)
&sql(CLOSE ChildDesigns)
; Вернем список
Quit ChildDesignsList
2. Запросы можно писать руками на языке ObjectScript. Это делается, если
требуется очень высокая производительность и нет надежды на оптимизатор.
Например, у меня так сделана проверка прав доступа. На каждый объект,
любого типа (если его класс унаследовать от класса SecurableObject)
существующий в базе можно создать списки прав доступа на разные
типы операций. Соответственно, при чтении такого объекта с диска,
модификации или удалении проверяются права доступа приконнекченного
юзера и генерятся соответствующие исключения. Различных классов,
для которых требуется проверка прав доступа у меня достаточно много.
Для ее реализации достаточно эти классы просто унаследовать
от SecurableObject. Никакого заметного падения производительности
при проверках прав доступа не происходит.
Разумеется, никто не собирается оптимизировать запросы, в которых
есть вызовы методов. Для выполнения запроса используются не экземпляры
объектов в памяти, а их хранящиеся на диске свойства. А для вызова метода
объекта, необходимо сначала прочитать его с диска - это достаточно
длительная операция (она загрузит в память все свойства, даже если
они не используются в запросах, а свойство может являться другим
встроенным объектом или вообще коллекцией). Эта оптимизация легко
делается вручную - можно перекрыть метод сохранения объекта, и когда
кто-то захочет сохранить экземпляр объекта на диске, то вызовется твой код,
где ты можешь построить собственные индексы на любой цвет и вкус,
по которым потом и будешь искать.
ЗЫ: Это действительно не ООСУБД, она просто обладает дополнительными
возможностями по сравнению с реляционными, потому и Post-Relational.
Это просто сервер СУДБ и сервер приложений вместе с PL в одном флаконе.
Ибо я не сторонник чистоты ОО-идей и предпочитаю C++ вместо ST и
удобную в разработке систему вместо чистой ООСУБД.
Вернее наоборот, это в первую очередь сервер приложений с достаточно
эффективным языком разработки, похожим на VisualBasic (его называют
ObjectScript), основанный на уже давно существующей "М-технологии".
Основное отличие состоит в том, что переменные этого языка не просто
скалярные или массивы, а индексированные массивы с произвольным
количеством индексов. С математической точки зрения каждая
переменная - дерево. Например два человека выглядят так:
Set Person(1,"FirstName")="Alex"
Set Person(2,"FirstName")="Peter"
Set Person(2,"LastName")="Allan"
Причем для второго человека мы храним как имя, так и фамилию.
В РСУБД нельзя создать таблицу, в которой первая строка имеет
одно поле, а вторая - два.
Причем к первому можно добавить список имен детей:
Set Person(1,"Childs",1,"Name")="John"
Set Person(1,"Childs",2,"Name")="Michael"
Set Person(1,"Childs",3,"Name")="Ann"
В терминах РСУБД это означает появление в первой строке таблицы
поля, которое также является таблицей.
А уже потом - это сервер СУБД, поскольку это переменные могут
быть не только локальными, но и глобальными, т.е. хранится
на диске и быть доступными сразу всем процессам. Т.е. на самом
низком уровне физически на диске хранятся не таблицы, а эти
деревья (в оптимизированном виде). PL там реализован в виде
библиотеки классов (на манер MFC) и при желании ты можешь
даже не знать, каким именно образом и где хранятся твои
объекты, но этим можно (и нужно) управлять. Можно
и собственный PL написать.
В рекламе написано про три вида доступа: реляционный, объектный
и прямой. Реляционные запросы транслируются в код на ObjectScript,
который ползает по этим деревьям на диске, объектный доступ
через методы PL делает тоже самое, а прямой доступ - это когда
ты сам ручками пишешь на ObjectScript код, работающий
с глобальными переменными.
_Такая_ реализация PL меня более чем устраивает _в работе_.
Те сабж, которые там есть для меня представляют скорее
академический интерес (как тема диссертации), чем реально
мешают работать.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73
Serguei Tarassov
На запрос в комитет от 30 января 2002 года, отправленного тов. Belugin Max
по поводу предыдущего запроса тов. Serguei Tarassov со всей партийной
прямотой отвечаем:
ST>> "Неllo, world!" в возвращаемую строку :-) Вызов метода всегда
ST>> приводит к изменению состояния объекта, от которого, в свою очередь
ST>> зависят результаты вызовов других методов. И т.д.
BM> Не всегда.
"Не всегда" тождественно равно "иногда". То есть очередное частное решение.
--
с коминтерновским приветом участникам съезда
тов. Сергей (Тарасов)
mailto:se...@arbinada.com
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Serguei Tarassov
На запрос в комитет от 29 января 2002 года, отправленного тов. Andrei
N.Sobchuck по поводу предыдущего запроса тов. "Serguei Tarassov"
<tem...@arbinada.com> со всей партийной прямотой отвечаем:
AN> Ну. Indexed views существуют.
Это структура, а не алгоритм.
AN> Не всегда ;)
"Не всегда" == "иногда".
AN> Если после выполнения запроса состояние объекта изменится и он
AN> перестанет удовлетворять условию запроса, то это... ммм...
AN> глупая ситуация.
Это ситуация, о которой я не могу знать наверняка. Или ты предлагаешь
закладываться на реализацию объекта???
AN> Не объектный, но и не структурный (абсолютно).
Если ты знаешь структуру объекта - то структурный :-)
В ОО-языках программирования уже давно всем понятно, почему надо
использовать get/set вместо открытых полей. А в СУБД, по-твоему можно???
AN> [я перестал понимать, что тебе не нравится.
Из того что сейчас реально предлагается - ничего.
Vladimir Pavlikov
Hello! "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote:
> >> VP> 2. Относящийся не к ST, и не к O/R mappings, а к "ООСУБД".
> >> Нет _принципиальной_ разницы.
> VP> Она именно принципиальна. Обертка и СУБД - сильно отличаются.
> Смаллтоковый образ - это именно ООБД, а не обёртка.
Хорошо, скажу иначе - из другого языка (С++, к примеру) можно
использовать эту "СУБД" именно как ОО? Из "Смаллтоковый образ"
видна пока только обертка.
Есть такая СУБД - dbVista. Нынче она Velocis'ом именуется.
Сетевая _навигационная_ БД. Да, сейчас уже вполне SQL-ая,
но я не об этом. Работал с ней посредством ROM - это некий
Object manager, т.е. именно обертка, в чистом виде. Она плю-
совая, и ни на каком другом языке к СУБД обратиться как к ОО
нельзя. При этом при использовании ROM даже трудно догадаться,
что работа идет вообще с СУБД, хоть какой.
> В традиционном исполнении - in memory.
> Чего не хватает, чтобы отказаться от РСУБД в качестве
> подложки для хранения данных, я написал.
Вот и ответ. СУБД есть обычное _Р_. Плюс обертка. Скрывающая
некие _полезные_ свойства РСУБД....
А in memory - это вообще не субд, а игрушка. И как-то трудно
представить ее в виде клиент-сервера - другие пользователи
тоже в ту же memory смотрят? :)
> То, что сейчас _реально_ есть - это конь, уже не в вакууме, но
> всё еще сферический.
"СУБД для..." - это не СУБД. Речь о ОО/неОО уже просто не идет.
А сама СУБД вполне реляционная. Какой это для вас, ST-щиков, конь -
в вакууме ли, в пальто ли, или еще где - решать вам. Для остальных
достаточно того, что это... неэхотажный офтопик :))
--
Владимир Павликов.
Andrei N.Sobchuck
DVL> В КАШЕ есть разные виды запросов.
[...]
Понятно. Спасибо.
Belugin Max
среда, 30 января 2002 г., you wrote:
ST> ST>> "Неllo, world!" в возвращаемую строку :-) Вызов метода всегда
ST> ST>> приводит к изменению состояния объекта, от которого, в свою очередь
ST> ST>> зависят результаты вызовов других методов. И т.д.
ST> BM> Не всегда.
ST> "Не всегда" тождественно равно "иногда". То есть очередное частное решение.
Что не частное решение?
--
Best regards,
Max
http://belugin.newmail.ru
ICQ:9406811
Serguei Tarassov
На запрос в комитет от 31 января 2002 года, отправленного тов. Belugin Max
по поводу предыдущего запроса тов. Serguei Tarassov со всей партийной
прямотой отвечаем:
BM> Что не частное решение?
Реляционная модель и РСУБД, к примеру.
Тоже не панацея, но для очень многих случаев подходит не будучи притянутой
за уши.
--
с коминтерновским приветом участникам съезда
тов. Сергей (Тарасов)
mailto:se...@arbinada.com
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Victor Metelitsa
Andrei N.Sobchuck wrote:
> Victor Metelitsa wrote:
> [...]
> _сложно_. имхо.
>
>
В каком месте сложно? То, что словари и есть индексы (один из видов),
или использование стандартного notification mechanizm, или то, что (если
не использовать multikey dictionary, что соответствует индексу по
нескольким полям) OrOperator предполагает конкатенацию, а AndOperator -
пересечение? Все эти вещи вполне стандартные.
--
Andrei N.Sobchuck
VM> Andrei N.Sobchuck wrote:
>> Victor Metelitsa wrote:
>> [...]
>> _сложно_. имхо.
>>
>>
VM> В каком месте сложно? То, что словари и есть индексы (один из видов),
Оптимизация "руками" - анахронизм.
VM> или использование стандартного notification mechanizm, или то, что (если
VM> не использовать multikey dictionary, что соответствует индексу по
VM> нескольким полям) OrOperator предполагает конкатенацию, а AndOperator -
VM> пересечение? Все эти вещи вполне стандартные.
--
Андрей Собчук
E-mail: and...@itware.com.ua
Victor Metelitsa
Andrei N.Sobchuck wrote:
> Vladimir Pavlikov wrote:
[...]
> Но ни один диалект (включая Gemstone/S)
> не кеширует _результат_ _исполнения_ метода.
Разумеется.
> Таким образом, сейчас, Gemstone/S выполняет выборку
> 'aCollection select: [:eachElement |
> eachElement someAttribute anotherCollection
> anySatisfy: [ :a | a = myObject ] ]'
> Путём последовательного перебора элементов коллекции и отправки
> каждому элементу сообщения #someAttribute, результату -
> сообщения #anotherCollection, затем #anySatisfy: .
> Если бы разработчики подсуетились и реализовали кеширование результата
> (индексацию объектов по результату метода),
Я предложил реальный механизм. На самом деле - стандартное решение. Нам
нужно только гарантировать детерминированность (т.е. если состояние
объекта не изменилось, то метод должен вернуть тот же результат) и
воспользоваться стандартным или чуточку доработанным notification
механизмом.
> приделали оптимизатор, то в результате бы имели реальную СУБД
> _следующего_ поколения.
Мы ее уже имеем.
> А так, приходится лепить всякие O/R mappings (ну или без них).
> А всё для того, чтобы упростить работу серверу
> (или разработчикам серверов).
>
Не поэтому. А из-за цены лицензии и/или требований к совместимости.
--
Victor Metelitsa
Serguei Tarassov wrote:
> Дорогой наш товарищ Victor
> На запрос в комитет от 29 января 2002 года, отправленного тов. Victor
> Metelitsa по поводу предыдущего запроса тов. Andrei N.Sobchuck со всей
> партийной прямотой отвечаем:
>
>
> VM> год; у него есть слой для работы с GemStone/S. Главная его польза -
> VM> возможность абстрагироваться от SQL СУБД, как будто работаем с ОО
> VM> СУБД (SQL СУБД при таком подходе становится "умной" дисковой
> VM> подсистемой; при этом реализация вполне эффективна).
> Вот здесь мне и кажется, что абстрагирование от SQL является ошибкой.
> Почему бы не абстрагироваться сразу от "умной" подсистемы хранения? Зачем
> тебе там сиквел: данные читать и записывать? Так ведь декларативный сиквел
> для этого не нужен, всего несколько императивных функций хватит.
Мне SQL абсолютно не нужен, только вот на GemStone денег не дадут,
спиратить его чрезвычайно сложно, а ограничение в четыре коннекта
некоммерческой совершенно не устраивает. Просто так писать объекты на
диск - появляются проблемы с параллельностью, поддержкой транзакция и
пр., они, конечно, решаются, но тоже недешево. o-r-mapping - это дешевое
и сердитое решение (по крайней мере, в плане реализации). Инкапсуляция
при этом, да, нарушается, но это замаскировано, и можно воображать,
будто это не так.
--
Victor Metelitsa
Andrei N.Sobchuck wrote:
> Victor Metelitsa wrote:
>
> VM> Andrei N.Sobchuck wrote:
>
>
>>>Victor Metelitsa wrote:
>>>[...]
>>>_сложно_. имхо.
>>>
>>>
>>>
>
> VM> В каком месте сложно? То, что словари и есть индексы (один из видов),
> Оптимизация "руками" - анахронизм.
Что ты имеешь в виду под "оптимизацией руками"? Я предложил обернуть
коллекцию (или расширить ее). Протокол, конечно, должен быть как у
коллекции (add:, remove:, select:) плюс расширения. Расширения включают
в себя механизм индексирования (на основе словарей; можно взять
B-Деревья и что-нибудь еще) и механизм запросов. Нужно ли было
разжевывать до деталей? Что если нет соответствующего индекса, то он не
должен использоваться, что если индексы многоколоночные (например, на
многоключевых словарях), то надо принять решение и выбрать нужный? Я не
вижу особых сложностях в реализации. Я думаю, реально внутри GemStone
оно так уже и устроено, только привязано зачем-то к instance variables и
не доведено до ума.
--
Victor Metelitsa
Vladimir Pavlikov wrote:
> Hello! "Victor Metelitsa" <v...@cssc.tat.ru> wrote:
>
>
>>Вопрос сводится к правильности определений. Вот маленькая задачка:
>>Есть человек A, у него в голове имеется определение "XXX - это YYY".
>>Есть человек B, у него в голове имеется определение "XXX - это ZZZ".
>>Вопрос: у кого из них определение правильней? А может, XXX - это на
>>самом деле TTT? Как мы будем это решать? Посмотреть в книжках? Их, в
>>конце концов, писали тоже люди, и они нередко противоречат друг другу;
>>разные вещи, называемые одними и теми же словами, обычное явление.
>>Ответ, по-моему, совершенно прост. Правильных и неправильных определений
>>не существует. Определение просто _дается_. В неформальных разговорах,
>>увы, оно обычно "за кадром", что приводит к многочисленным
>>недоразумениям, однако каждый раз формализовывать все эти вещи просто
>>немыслимо.
>>
>
> Напоминаю, что сабж поднял именно ты. Определения "давать" не стал,
> существование б.м. устойчивых определений не признаешь... Следует
> понимать так, что флейм ты завел, чтобы "привести к многочисленным
> недоразумениям"?
"Проблемы persistent layers" поднял не я. Понятие "устойчивого
определения" имеет мало смысла. В другой группе людей оно может быть
другим (и меняться со временем). Как определяется группа? Как угодно
("существует две группы людей - те, кто знают, что люди делятся на две
группы, и все остальные").
Теперь о недоразумениях. Как при работе с базой есть пессимистическая
(блокируем строки заранее) и оптимистическая (ничего подобного не
делаем, а просто в нужный момент производим попытку обновления, а если
не вышло, откатываемся) стратегии, причем наиболее популярной является
оптимистическая, так и в разговорах и переписке.
Пессимистическая стратегия в данном контексте - прописать явно все
нужные определения, письмо превращается... в учебник или "научную
статью". На худой конец, сослаться на что-то.
Оптимистическая стратегия - ничего подобного не делать, надеясь на
совпадение. Если не совпало, возникает конфликт. А уж разрешение его
бывает разным: если все участники хотят разобраться, обсуждение идет по
одному пути, иначе по другому.
> Я уже задавал вопрос, повторю :"Это что, неудачная попытка выкрутится
> типа "я пошутил""? Ты на него не ответил, что-то про манию величия
> начал плести.
Я не знаю, как отвечать на такие вопросы. "Выкрутиться", "пошутил" -
откуда это взялось? Почему мне надо перед тобой выкручиваться, с какой
целью?
> Наверное, это тебе очень близко... Сейчас опять сказал
> глупость, а когда тебя прижали - начал рассуждать про определения.
Так ты, по-видимому, не знаешь про определения, а потому и решил, что я
сказал глупость.
> Поздновато, не находишь? Да и как полноценная замена не катит. Что,
> совсем не способен признавать собственные ошибки?
>
Ошибки? Ну вот, пожадуйста:
Глупо говорить о зле в хранимых процедурах, когда настоящее зло -
реляционка.
Глупо было обсуждать это здесь. Народ все равно за деревьями не видит
леса. Как минимум, мне надо было тщательно подготовиться и наработать
материалы. С другой стороны, нет худа без добра, и теперь я твердо
решил, что возьмусь за то, что нужно сделать.
>
>>Итак. То, что _я_ называю ОО СУБД, это СУБД, где, кроме всего прочего,
>>все данные - это объекты, там вообще нет ничего, кроме объектов, эти
>>объекты знают друг о друге и посылают друг другу сообщения. Индексы,
>>стало быть, тоже объекты (разновидность коллекций).
>>
>
> Мне малоинтересны ООСУБД. Просто потому, что ОО я считаю ограниченной
> технологией, к СУБД применимой в целом тоже ограниченно. Т.е. некая
> часть ОО-шности будет полезной, но не более. Соответственно, "чистА
> ООСУБД" - скорее всего, плохо. Поэтому обсуждать эту тему мне неинте-
> ресно.
Ну, а я думаю, что ОО - универсальный подход.
> Но, так и быть - расскажи нам (чисто для интереса), как работает
> механизм посылки сообщений между ОО-аналогами кортежей в твоей
> любимой ООСУБД (которая, без сомнения - с твоей точки зрения -
> существует).
>
Кортеж (запись) - это такой уродец. Без методов (суррогатом служат
триггеры), с прямым доступом к атрибутам. Таблица одновременно является
и коллекцией, и классом, кортеж может содержаться только в "своей"
таблице и никакой другой, таблица может содержать только "свои" кортежи
и никакие другие...
Нет, в кошмарном сне не могу вообразить такую ООСУБД. Она должна
работать не с кортежами, а с бизнес-объектами произвольной сложности
(конечно, и кортежи можно проэмулировать).
Механизм посылки сообщений - стандартный ST. Нужны подробности?
> Но если и на этот раз "сольешь", перейдя на общие (и к делу не от-
> носящиеся) рассуждения - поставлю на тебя фильтр. Так дешевле будет...
> --
Хм. Ну, постараюсь пережить, если что.
Andrei N.Sobchuck
>> VM> В каком месте сложно? То, что словари и есть индексы (один из видов),
>> Оптимизация "руками" - анахронизм.
VM> Что ты имеешь в виду под "оптимизацией руками"? Я предложил обернуть
VM> коллекцию (или расширить ее). Протокол, конечно, должен быть как у
VM> коллекции (add:, remove:, select:) плюс расширения. Расширения включают
VM> в себя механизм индексирования (на основе словарей; можно взять
VM> B-Деревья и что-нибудь еще) и механизм запросов. Нужно ли было
VM> разжевывать до деталей? Что если нет соответствующего индекса, то он не
VM> должен использоваться, что если индексы многоколоночные (например, на
VM> многоключевых словарях), то надо принять решение и выбрать нужный? Я не
VM> вижу особых сложностях в реализации. Я думаю, реально внутри GemStone
VM> оно так уже и устроено, только привязано зачем-то к instance variables и
VM> не доведено до ума.
Этого сейчас нет. Делать самому? То, что ты написал - будет полноценный сервер.
Так что, O/R mapping - проще всего.
Кстати о маппинге. Ко всем.
В результате запроса получили объект на клиенте.
Другой пользователь удалил из базы записи из которых
объект был "собран".
Что с этим уже не существующим объектом должно
происходить на клиенте?
Ответ попрошу разжевать.
--
Андрей Собчук
E-mail: and...@itware.com.ua
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Victor Metelitsa
Andrei N.Sobchuck wrote:
> Victor Metelitsa wrote:
>
>>> VM> В каком месте сложно? То, что словари и есть индексы (один из видов),
>>>Оптимизация "руками" - анахронизм.
>>>
>
> VM> Что ты имеешь в виду под "оптимизацией руками"? Я предложил обернуть
> VM> коллекцию (или расширить ее). Протокол, конечно, должен быть как у
> VM> коллекции (add:, remove:, select:) плюс расширения. Расширения включают
> VM> в себя механизм индексирования (на основе словарей; можно взять
> VM> B-Деревья и что-нибудь еще) и механизм запросов. Нужно ли было
> VM> разжевывать до деталей? Что если нет соответствующего индекса, то он не
> VM> должен использоваться, что если индексы многоколоночные (например, на
> VM> многоключевых словарях), то надо принять решение и выбрать нужный? Я не
> VM> вижу особых сложностях в реализации. Я думаю, реально внутри GemStone
> VM> оно так уже и устроено, только привязано зачем-то к instance variables и
> VM> не доведено до ума.
> Этого сейчас нет. Делать самому? То, что ты написал - будет полноценный сервер.
Мне все это кажется настолько простым... Многие компоненты уже готовые,
лишь немножко поработать напильником осталось ;-). Только зачем, если
всего четыре коннекта? ;-(
> Так что, O/R mapping - проще всего.
>
> Кстати о маппинге. Ко всем.
> В результате запроса получили объект на клиенте.
> Другой пользователь удалил из базы записи из которых
> объект был "собран".
> Что с этим уже не существующим объектом должно
> происходить на клиенте?
Такого просто не может (не должно) быть. Никаких "записей" не
существует, есть просто объекты. Пользователь в результате запроса
получил не объект GemStone, а одно из двух: либо "отражение", связанное
коннектором с оригинальным GemStone-объектом, либо прокси. Есть на
объект GemStone ссылка - он в мусор не попадет; то, что другой
пользователь убрал объект из коллекции или откуда-то еще, роли не
играет. А ссылка есть (должна быть) обязательно; коннектор и прокси это
и есть ссылки, только между разными имиджами. Вот когда первый
пользователь разорвет коннект с базой, либо "избавится" от того
"отражения" или прокси (их приберет сборщик мусора), тогда только
базоданновый объект может отправлиться в мусор.
--
Vladimir Pavlikov
Hello! "Victor Metelitsa" <v...@cssc.tat.ru> wrote:
> Глупо говорить о зле в хранимых процедурах, когда настоящее зло -
> реляционка.
Но ты же говоришь :)
> Глупо было обсуждать это здесь. Народ все равно за деревьями не видит
> леса. Как минимум, мне надо было тщательно подготовиться и наработать
> материалы. С другой стороны, нет худа без добра, и теперь я твердо
> решил, что возьмусь за то, что нужно сделать.
И заменишь реляционку ОО :((
При том, что "плоскотабличную" структуру нужно заменить полносвязной
сетью, а декларативность запросов надо _оставить_. ОО тоже место
найдется, _ограниченное_, в самом "низу". А не везде, как хочешь ты.
> > Мне малоинтересны ООСУБД. Просто потому, что ОО я считаю ограниченной
> > технологией, к СУБД применимой в целом тоже ограниченно. Т.е. некая
> > часть ОО-шности будет полезной, но не более. Соответственно, "чистА
> > ООСУБД" - скорее всего, плохо. Поэтому обсуждать эту тему мне неинте-
> > ресно.
> Ну, а я думаю, что ОО - универсальный подход.
Значит, я тебя обогнал, у тебя это еще впереди :)
> > Но, так и быть - расскажи нам (чисто для интереса), как работает
> > механизм посылки сообщений между ОО-аналогами кортежей в твоей
> > любимой ООСУБД (которая, без сомнения - с твоей точки зрения -
> > существует).
> Кортеж (запись) - это такой уродец. Без методов (суррогатом служат
> триггеры), с прямым доступом к атрибутам. Таблица одновременно является
> и коллекцией, и классом, кортеж может содержаться только в "своей"
> таблице и никакой другой, таблица может содержать только "свои" кортежи
> и никакие другие...
Трудно признать это ответом на вопрос...
> Механизм посылки сообщений - стандартный ST. Нужны подробности?
В такой постановке вопроса - нет. Ибо с такой с позволения сказать
СУБД работать нечем. Не на ST же, в самом деле :))
> > Но если и на этот раз "сольешь", перейдя на общие (и к делу не от-
> > носящиеся) рассуждения - поставлю на тебя фильтр. Так дешевле будет...
> Хм. Ну, постараюсь пережить, если что.
:)
--
Владимир Павликов.
Vladimir Pavlikov
Hello! "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote:
> Кстати о маппинге. Ко всем.
> В результате запроса получили объект на клиенте.
> Другой пользователь удалил из базы записи из которых
> объект был "собран".
> Что с этим уже не существующим объектом должно
> происходить на клиенте?
Если я правильно понял вопрос - он не о маппинге.
Ровно то же самое справедливо и в отношении единич-
ной записи. Касается "актуальности на момент чтения".
Ответ - ничего не делать. Либо, при желании получить
актуальные на данный момент объекты - перезапросить
их.
--
Владимир Павликов.
Andrei N.Sobchuck
>>
>> Кстати о маппинге. Ко всем.
>> В результате запроса получили объект на клиенте.
>> Другой пользователь удалил из базы записи из которых
>> объект был "собран".
>> Что с этим уже не существующим объектом должно
>> происходить на клиенте?
VM> Такого просто не может (не должно) быть. Никаких "записей" не
VM> существует, есть просто объекты. Пользователь в результате запроса
VM> получил не объект GemStone, а одно из двух: либо "отражение", связанное
Я о O/R mapping (GLORP в частности).
Andrei N.Sobchuck
VP> Hello! "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote:
>> Кстати о маппинге. Ко всем.
>> В результате запроса получили объект на клиенте.
>> Другой пользователь удалил из базы записи из которых
>> объект был "собран".
>> Что с этим уже не существующим объектом должно
>> происходить на клиенте?
VP> Если я правильно понял вопрос - он не о маппинге.
VP> Ровно то же самое справедливо и в отношении единич-
VP> ной записи. Касается "актуальности на момент чтения".
VP> Ответ - ничего не делать. Либо, при желании получить
VP> актуальные на данный момент объекты - перезапросить
VP> их.
В том то и дело. Объект уже есть на клиенте. В работе.
Нужно изменения сохранить в базу.
Просто проигнорировать - нехорошо. Что то другое сделать -
что, не понятно. Пока, кроме простого уведомления
объекта о том, что его уже "нет" ничего в голову не пришло.
Хотя сейчас я подумал, что это, похоже, единственный вариант.
Dmitry V. Liseev
Hi!
> Кстати о маппинге. Ко всем.
> В результате запроса получили объект на клиенте.
> Другой пользователь удалил из базы записи из которых
> объект был "собран".
> Что с этим уже не существующим объектом должно
> происходить на клиенте?
> Ответ попрошу разжевать.
В Cache поскольку первый клиент держит интерфейс на объект,
то из памяти сервера (в данном процессе) он не удалится
в соответствии с правилами подсчета ссылок, но
другой пользователь может удалить объект с диска.
у меня есть 3 варианта:
1. Поскольку объект был удален с диска, но жив в памяти, то
рассматривать его как новый (только-что созданный), и при
попытке его сохранить - создавать на диске новую запись.
2. При попытке сохранить объект возвращать клиенту исключение.
3. Еще при чтении объекта указать флаг исключающей блокировки,
и попытки удаления или модификации объекта другими пользователями
будут ставиться на ожидание или отлетать сразу.
В реальных задачах использую разные методы в зависимости от
ситуации.
PS: ИМХО объектная модель, как ее обычно понимают, мало
применима к БД и хранению данных. Если у Буча объект понимается,
как "нечто целостное", то при хранении объекта он неизбежно
"рассыпается", т.к. нам редко нужно просто читать и записывать
объекты, их нужно еще и искать. То есть появляются
индексы. Если искать нужно по многим критериям, то нужно много индексов,
в разном порядке следования, и часто хранение самого "нечто целого" просто
не имеет смысла - проще и эффективнее при считывании объекта собирать
его из индексов, а при записи обратно расталкивать по индексам. Возникают
напряги и с производительностью: Если объект понимать, как "нечто целое",
то при извлечении объекта из базы он должен извлекаться целиком, даже
если клиенту нужно только одно его свойство. А объект может иметь достаточно
сложную структуру и значительный размер. При сохранении опять нужно писать
на диск целиком в соответствии с принципом целостности. В то-же время
в РСУБД можно делать и селект и апдейт отдельно взятых полей.
Ведь инкапсуляция, наследование и полиморфизм существуют не как самоцель,
а как средство для достижения обычных целей: необходимо разбивать сложную
задачу на достаточно слабо взаимодействующие части, чтобы ее было легче
осмыслить, чтобы можно было распараллелить разработку, чтобы легче было
сопровождать и развивать, чтобы можно было повторно использовать
отлаженный код. Вполне возможно, что в БД этих целей можно достичь
несколько иными методами, не придерживаясь строгой идеологии
классических ОО-языков разработки. То есть, если ОО-метода рулит
при разработке приложений, то это не значит, что она в неизменном
виде порулит и в хранении данных, поддержании ссылочной целостности,
быстром поиске и многопользовательском доступе. И не лучше-ли вместо
втискивания таких задач в рамки существующей ОО-идеологии доработать
ее под данную предметную область и создать нечто вроде ОО for DBMS?
Или создать что-то принципиально иное?
Victor Metelitsa
Michael Demichev wrote:
> Привет, 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/.
> Вот он клипперист. Все сделаем свое и будет тип-топ.
>
По этому поводу мне вспоминается один несмешной анекдот (по-моему, за
такое надо давать в морду, а не смеяться) - как пьяный мужик сказал
девице, что он назавтра проспится, а у нее ноги кривыми как есть, так и
останутся.
--
Vladimir Pavlikov
Hello! "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote:
> VP> Если я правильно понял вопрос - он не о маппинге.
> VP> Ровно то же самое справедливо и в отношении единич-
> VP> ной записи. Касается "актуальности на момент чтения".
> VP> Ответ - ничего не делать. Либо, при желании получить
> VP> актуальные на данный момент объекты - перезапросить
> VP> их.
> В том то и дело. Объект уже есть на клиенте. В работе.
> Нужно изменения сохранить в базу.
Я писал о чтении.
> Просто проигнорировать - нехорошо. Что то другое сделать -
> что, не понятно. Пока, кроме простого уведомления
> объекта о том, что его уже "нет" ничего в голову не пришло.
> Хотя сейчас я подумал, что это, похоже, единственный вариант.
Уведомления объекта или клиента? Видимо, тут опечатка.
Введи галку в опциях. Делаешь update. Если не проходит -
в зависимости от галки либо делаешь rollback, либо insert.
Пойдет?
--
Владимир Павликов.
Vladimir Pavlikov
Hello! "Dmitry V. Liseev" <di...@infopro.spb.su> wrote:
> PS: ИМХО объектная модель, как ее обычно понимают, мало
> применима к БД и хранению данных.
...
> Ведь инкапсуляция, наследование и полиморфизм существуют не как самоцель,
> а как средство для достижения обычных целей
...
> Вполне возможно, что в БД этих целей можно достичь
> несколько иными методами, не придерживаясь строгой идеологии
> классических ОО-языков разработки.
...
> И не лучше-ли вместо
> втискивания таких задач в рамки существующей ОО-идеологии доработать
> ее под данную предметную область и создать нечто вроде ОО for DBMS?
> Или создать что-то принципиально иное?
А вот и соратник :)
По мне - "идеальная" картинка д.б. что-то вроде (по "слоям", снизу) :
1. Физическое хранение данных (диск).
2. Объекты, в определенных границах.
3. Логическая схема - полносвязная сеть.
4. Декларативный [и процедурный] ONSQL (объектно-сетевой), доступный
и на сервере, и на клиентах (создаваемых _разным_ инструментарием).
5. (Опционально) - языковый (для используемых инструментальных пакетов)
слой, "инкапсулирующий" БД в язык (библиотеку).
2Andrei N.Sobchuck - теперь мои соображения понятнее? То, о чем гово-
ришь ты - для меня это лишь 2-й и 5-й слой, опциональный. Причем 2-й
откровенно не на месте. И уж никак не СУБД.
2Ilya Zvyagin - надеюсь, это прояснит мое нежелание обсуждать ООСУБД.
Просто не вижу в них практического смысла. Единственное исключение -
дектопные "все в памяти" движки. Но это никоим образом не эхотаг,
а некая "приблуда" к инструментальному пакету для работы с относи-
тельно небольшими объемами данных, сохраняемыми между сеансами работы.
--
Владимир Павликов.
Tolik Tentser
В чреве акулы, пойманной Fri, 1 Feb 2002 11:15:54 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: Проблемы persistent
layers':
>Теперь о недоразумениях. Как при работе с базой есть пессимистическая
>(блокируем строки заранее) и оптимистическая (ничего подобного не
>делаем, а просто в нужный момент производим попытку обновления, а если
>не вышло, откатываемся) стратегии, причем наиболее популярной является
>оптимистическая, так и в разговорах и переписке.
>
>Пессимистическая стратегия в данном контексте - прописать явно все
>нужные определения, письмо превращается... в учебник или "научную
>статью". На худой конец, сослаться на что-то.
>
>Оптимистическая стратегия - ничего подобного не делать, надеясь на
>совпадение. Если не совпало, возникает конфликт. А уж разрешение его
>бывает разным: если все участники хотят разобраться, обсуждение идет по
>одному пути, иначе по другому.
Нет уж, если проводить параллели с СУБД - при возниконовении конфликта
инициатор должен с извинениями откатиться :-Р
Иначе это уже какая-то иная стратегия (не блокироуем, но и откатывать
не хотим), которой все-же прежде чем обсуждать придется дать
определение. :-)
Bye ...
Тенцер А.Л.
to...@katren.nsk.ru
ICQ 15925834
Tolik Tentser
В чреве акулы, пойманной Fri, 1 Feb 2002 12:53:54 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: Проблемы persistent
layers':
>Кстати о маппинге. Ко всем.
>В результате запроса получили объект на клиенте.
>Другой пользователь удалил из базы записи из которых
>объект был "собран".
>Что с этим уже не существующим объектом должно
>происходить на клиенте?
>Ответ попрошу разжевать.
А чего тут жевать ?
Работаешь с объектами - будь любезен обеспечить, например,
блокирование (или версионность или любой другой механизм разведения
конфликтов доступа) на уровне объектов. Например - слой, занимающийся
маппингом при считывании объекта должен проверять не заблокирован ли
он и блокировать при необходимости.
Andrei N.Sobchuck
>> Просто проигнорировать - нехорошо. Что то другое сделать -
>> что, не понятно. Пока, кроме простого уведомления
>> объекта о том, что его уже "нет" ничего в голову не пришло.
>> Хотя сейчас я подумал, что это, похоже, единственный вариант.
VP> Уведомления объекта или клиента? Видимо, тут опечатка.
Почему опечатка?
VP> Введи галку в опциях. Делаешь update. Если не проходит -
VP> в зависимости от галки либо делаешь rollback, либо insert.
VP> Пойдет?
Инсерт не пойдёт. Всей информации об объекте может не быть
(я о Proxy).
Хотелось бы какое-то универсальное решение. Но похоже, всё
слишком зависит от приложения.
Andrei N.Sobchuck
VP> А вот и соратник :)
VP> По мне - "идеальная" картинка д.б. что-то вроде (по "слоям", снизу) :
VP> 1. Физическое хранение данных (диск).
VP> 2. Объекты, в определенных границах.
VP> 3. Логическая схема - полносвязная сеть.
VP> 4. Декларативный [и процедурный] ONSQL (объектно-сетевой), доступный
VP> и на сервере, и на клиентах (создаваемых _разным_ инструментарием).
VP> 5. (Опционально) - языковый (для используемых инструментальных пакетов)
VP> слой, "инкапсулирующий" БД в язык (библиотеку).
VP> 2Andrei N.Sobchuck - теперь мои соображения понятнее? То, о чем гово-
VP> ришь ты - для меня это лишь 2-й и 5-й слой, опциональный. Причем 2-й
VP> откровенно не на месте. И уж никак не СУБД.
В твое схеме данные на диске и данные в памяти - это разные вещи.
ИМХО было бы удобнее не делать таких различий.
Вместо "инкапсуляции" БД в язык, правильнее прикрутить язык к БД.
"Роднее" получается.
oleg taranov
23 Jan 02 17:36, Victor Metelitsa wrote to Ilya Zvyagin:
VM> Пример: X связан с Y отнощением 1:N. Типичное для РСУБД решение - две
VM> таблицы, foreign key, без индекса работа немыслима (чудовищные
VM> тормоза). У ОО СУБД экземпляр X попросту содержит ссылку на коллекцию
VM> экземпляров Y, с которыми связан. Таким образом, мы получаем искомые Y
VM> немедленно, без поиска по индексам.
в каком виде все это находиться на сервере? наверно
надо хранить коллекции? имхо мало того что это неоптимально так
и размер всего этого 'удобоства' будет тоже немаленьким
/tff
Vladimir Pavlikov
Hello! "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote:
> >> Пока, кроме простого уведомления
> >> объекта о том, что его уже "нет" ничего в голову не пришло.
> >> Хотя сейчас я подумал, что это, похоже, единственный вариант.
> VP> Уведомления объекта или клиента? Видимо, тут опечатка.
> Почему опечатка?
Это было предположение. Исходил из того, что - а нафига объект
уведомлять? - грохнуть его, раз невалидный, и все.
> VP> Введи галку в опциях. Делаешь update. Если не проходит -
> VP> в зависимости от галки либо делаешь rollback, либо insert.
> VP> Пойдет?
> Инсерт не пойдёт. Всей информации об объекте может не быть
> (я о Proxy).
> Хотелось бы какое-то универсальное решение. Но похоже, всё
> слишком зависит от приложения.
Если занесение измененного объекта невозможно (в силу его
некомплектности, в частности) - остается только rollback.
Хотя твое последнее утверждение все равно остается верным.
--
Владимир Павликов.
Vladimir Pavlikov
Hello! "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote:
> VP> 2Andrei N.Sobchuck - теперь мои соображения понятнее? То, о чем гово-
> VP> ришь ты - для меня это лишь 2-й и 5-й слой, опциональный. Причем 2-й
> VP> откровенно не на месте. И уж никак не СУБД.
> В твое схеме данные на диске и данные в памяти - это разные вещи.
Так они и есть разные. Вне зависимости от чьих-либо имхо :)
> ИМХО было бы удобнее не делать таких различий.
Где не делать, в приложении? Для этого есть п.5 - не делай на
здоровье, только поддержу. А при описании схемы возможность
_отдельно_ прописать физику и "лирику" есть благо, обеспечива-
емое большинством серверов. И не только серверов.
> Вместо "инкапсуляции" БД в язык, правильнее прикрутить язык к БД.
> "Роднее" получается.
Без разницы - результат один. А вот реализация очень разная -
в твоем случае придется прикручивать к БД кучу языков. И для
любого все они, кроме одного - явный оверхед, утяжеляющий и
сам сервер, и стоимость его лицензий :)
--
Владимир Павликов.
Vladimir Pavlikov
Hello! "oleg taranov" <oleg.t...@f44.n464.z2.fidonet.org> wrote:
> VM> У ОО СУБД экземпляр X попросту содержит ссылку на коллекцию
> VM> экземпляров Y, с которыми связан. Таким образом, мы получаем искомые Y
> VM> немедленно, без поиска по индексам.
> в каком виде все это находиться на сервере? наверно
> надо хранить коллекции? имхо мало того что это неоптимально так
> и размер всего этого 'удобоства' будет тоже немаленьким
Это _намного_ оптимальнее. Только, как уже писалось, это не имеет
отношения к ОО - так работают с данными сетевые СУБД.
--
Владимир Павликов.
Andrei N.Sobchuck
VP> Это _намного_ оптимальнее. Только, как уже писалось, это не имеет
VP> отношения к ОО - так работают с данными сетевые СУБД.
А если к этим сетевым прикрутить тригера, то получится ООБД?
Andrei N.Sobchuck
>> >> Пока, кроме простого уведомления
>> >> объекта о том, что его уже "нет" ничего в голову не пришло.
>> >> Хотя сейчас я подумал, что это, похоже, единственный вариант.
>> VP> Уведомления объекта или клиента? Видимо, тут опечатка.
>> Почему опечатка?
VP> Это было предположение. Исходил из того, что - а нафига объект
VP> уведомлять? - грохнуть его, раз невалидный, и все.
С одной стороны, просто грохнуть не получится - ссылки на него могут быть.
С другой, таки да, в силу специфики объектов из базы данных
ссылок на него быть вроде и не должно.
>> VP> Введи галку в опциях. Делаешь update. Если не проходит -
>> VP> в зависимости от галки либо делаешь rollback, либо insert.
>> VP> Пойдет?
>> Инсерт не пойдёт. Всей информации об объекте может не быть
>> (я о Proxy).
>> Хотелось бы какое-то универсальное решение. Но похоже, всё
>> слишком зависит от приложения.
VP> Если занесение измененного объекта невозможно (в силу его
VP> некомплектности, в частности) - остается только rollback.
VP> Хотя твое последнее утверждение все равно остается верным.
Ясно.
Хотелось универсального :)
Andrei N.Sobchuck
VP> Без разницы - результат один. А вот реализация очень разная -
VP> в твоем случае придется прикручивать к БД кучу языков. И для
VP> любого все они, кроме одного - явный оверхед, утяжеляющий и
VP> сам сервер, и стоимость его лицензий :)
Ну к PostgreSQL чего только не крутится. Включая перл.
Vladimir Pavlikov
Hello! "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote:
> VP> Это _намного_ оптимальнее. Только, как уже писалось, это не имеет
> VP> отношения к ОО - так работают с данными сетевые СУБД.
> А если к этим сетевым прикрутить тригера, то получится ООБД?
Получится сетевая БД с констрейнами и пр. автоматами :)
ОО тут и близко нет.
--
Владимир Павликов.
Vladimir Pavlikov
Hello! "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote:
> VP> Без разницы - результат один. А вот реализация очень разная -
> VP> в твоем случае придется прикручивать к БД кучу языков. И для
> VP> любого все они, кроме одного - явный оверхед, утяжеляющий и
> VP> сам сервер, и стоимость его лицензий :)
> Ну к PostgreSQL чего только не крутится. Включая перл.
_Снаружи_. Т.е. сам постгресс о перле не знает, а это ровно
то, о чем я и говорил.
--
Владимир Павликов.
Andrei N.Sobchuck
VP> Hello! "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote:
>> VP> Без разницы - результат один. А вот реализация очень разная -
>> VP> в твоем случае придется прикручивать к БД кучу языков. И для
>> VP> любого все они, кроме одного - явный оверхед, утяжеляющий и
>> VP> сам сервер, и стоимость его лицензий :)
>> Ну к PostgreSQL чего только не крутится. Включая перл.
VP> _Снаружи_. Т.е. сам постгресс о перле не знает, а это ровно
VP> то, о чем я и говорил.
Интересно, от него можно оторвать SQL? :)
Serge Sapozhnikov
04 Feb 02 19:03, you wrote to Andrei N.Sobchuck:
>> А если к этим сетевым прикрутить тригера, то получится ООБД?
VP> Получится сетевая БД с констрейнами и пр. автоматами :)
VP> ОО тут и близко нет.
А что такое "ОО"? Можно мылом, дабы флейм не поднимать :-)
Good luck, Serge
p.s.
[на всякий случай] Расшифровку сокращения я знаю, Всемогущего Буча читал:-)
Vladimir Pavlikov
Hello! "Andrei N.Sobchuck" <and...@mart.cherkassy.ua> wrote:
> >> Ну к PostgreSQL чего только не крутится. Включая перл.
> VP> _Снаружи_. Т.е. сам постгресс о перле не знает, а это ровно
> VP> то, о чем я и говорил.
> Интересно, от него можно оторвать SQL? :)
Наверняка. Но, если у него нет других методов доступа (я просто
не в курсе) - это имеет смысл только непосредственно перед
выбросом на помойку :)
Vladimir Pavlikov
Hello! "Serge Sapozhnikov" <Serge.Sa...@p34.f4.n4635.z2.fidonet.org> wrote:
> VP> Получится сетевая БД с констрейнами и пр. автоматами :)
> VP> ОО тут и близко нет.
> А что такое "ОО"? Можно мылом, дабы флейм не поднимать :-)
Нечто эфемерное, в чистом виде ненужное :)