Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 34   вперед  Ctrl
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
c127

Не могли бы Вы теперь показать как в FastObjects и предложенной схеме получить:
1) типы самолетов, которыми летал Scott Tiger, 1,9,12,13,18,22,28 января 2003 года
2) номера рейсов которые были в январе 2003 года и на которые оставалось от 10 до 20 непроданных билетов включительно, но самолет не "TU 154"
3) пары рейсов, где 10 или более пассажиров общие (летели одни и те же люди)


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

Если же предполагается, что подобных от балды составленных запросов будет много, то ООСУБД однозначно проиграет типовым РСУБД, которые именно и хороши тем, что в среднем быстрее обрабатывают сложные нерегламентированные запросы.

В нашем конкретном случае я бы решил проблему довольно просто.
Для FastObjects имеется специальный продукт FastObjects Connect, который в т.ч. обеспечивает доступ к хранимым в БД FastObjects данным через ODBC посредством типовых SQL-запросов. Модуль для получения сложной аналитики может работать с объектной базой ровно также, как и с реляционной.

И в заключение (учитывая и другие ваши замечания) я замечу, что выше уже говорил - "представленная мною структура классов не единственная из возможных и не самая оптимальная". Просто мне было удобно использовать именно такую структуру с тем, чтобы продемонстрировать технику работы с различными инструментами (запросы, пространства классов, фильтры над пространствами классов ... ), поддерживаемыми именно FastObjects. Если бы я решал эту задачу на С++ с помощью, например, Versant Developer Suite, то подход был бы иным. Чтобы проиллюстрировать богатое многообразие возможных подходов, предлагаю сторонникам ООП предложить другие варианты хранимых классов (лично мне в голову приходит множество возможных комбинаций).

Я не пытаюсь отвергнуть критику вообще, но давайте обсуждать эффективность решения только в рамках поставленной задачи, т.е. мы можем обсудить скорость работы конкретных запросов, а не способы реализации других запросов, ранее не входивших в условия задачи.
28 янв 05, 12:12    [1281544]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

>Чушь. Демонстрирую для запроса 1:
...
Во-первых никакой 8-кратной разницы не вижу.


Вам же объяснили, что 8-кратная это если учесть Ваше заполнение базы, но я его вычел, я же сказал об этом. СКЛ запрос короче раза в 2-3, но если взять весь Ваш листинг (без заполнения) и весь листинг SergSuper-а, который представляет собой ПОЛНОЕ решение, то получится не меньше чем в 4 раза.

>А во-вторых справедливости ради нам нужно было бы рассматривать не чистый SQL-код, а код на Java, который посылает соответствующий SQL-запрос и получает результат.

Как раз справедливости ради этого делать не нужно. Одна из целей создания SQL-я - построение отчетов. Т.е. то, что Вы видите перед собой - готовый отчет. Чтоб получить его в виде, например, текстового файла, в сайбейзовском клиенте достаточно в после запроса добавить
"output to file_name".

Это длину принципиально не изменит. Так что 4 раза это совершенно четко, без всяких "но".

>Вот в SQL-запросе 'нужный рейс' откуда берется? В Java программе я элементарно могу попросить пользователя ввести этот исходный параметр и поместить введенное значение в переменную. Java-программу я могу запустить для регулярного вывода информации на электронное табло и т.п.

Но в предложенном решении Вы этого не сделали. Пока что пользователь должен менять текст прогоаммы, как и в случае SQL. Только в SQL-е это сделать легче т.к. короче и понятнее (ИМХО). Так что мы опять в равных положениях.

>А SQL-запрос представляет собой лишь фрагмент, который иллюстрирует центральный алгоритм решения задачи, но не является полным решением.

Неправда. Точно та же часть, что решена Вами в Вашем примере. Если хотите - добавьте output, это будет аналог printf, только гораздо более мощный (output-format : ASCII | DBASEII | DBASEIII | EXCEL | FIXED | FOXPRO | HTML | LOTUS | SQL | XML).

>Предлагаемые вами вопросы изменяют саму суть поставленной задачи.

Для реляционной базы они ничего не меняют. В реальных системах требования и тем более отчеты меняются постоянно.

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

Договорились, обсуждаем. То что Вы показали это "реляционная" модель в объектном исполнении, имеет место полное соответствие объект <-> таблица. В этом случае тягаться СКЛ-ем (DDL & DML) заранее проигрышный вариант, СКЛ специально создавался для создания отчетов на основе реляционных данных. Он так и называется: query language.

Нельзя ли перерписать этот пример, чтоб там было наследование или какие-то другие фичи ОМД, которые считаются преимуществом перед РМД и как-то это использовать? Интересно увидеть какую-нибудь специфику ОМД.
29 янв 05, 01:18    [1284231]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
c127
2 Alexey Rovdo

Как раз справедливости ради этого делать не нужно. Одна из целей создания SQL-я - построение отчетов. Т.е. то, что Вы видите перед собой - готовый отчет. Чтоб получить его в виде, например, текстового файла, в сайбейзовском клиенте достаточно в после запроса добавить
"output to file_name".



Только не рассказывайте мне, что вы действительно делаете системы, в которых конечные пользователи получают доступ к данным непосредственно через инструментарий СУБД, а не с помощью отдельного клиентского приложения или через Web. В том маловероятном случае, когда это действительно допустимо, готов уступить и согласиться с тем, что использование традиционной реляционной СУБД эффективнее, чем применение ООСУБД, которая по своей природе просто обязана интегрироваться с приложением, написанным на ОО языке программирования.

c127

>Вот в SQL-запросе 'нужный рейс' откуда берется? В Java программе я элементарно могу попросить пользователя ввести этот исходный параметр и поместить введенное значение в переменную. Java-программу я могу запустить для регулярного вывода информации на электронное табло и т.п.

Но в предложенном решении Вы этого не сделали. Пока что пользователь должен менять текст прогоаммы, как и в случае SQL. Только в SQL-е это сделать легче т.к. короче и понятнее (ИМХО). Так что мы опять в равных положениях.


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



>А SQL-запрос представляет собой лишь фрагмент, который иллюстрирует центральный алгоритм решения задачи, но не является полным решением.

Неправда. Точно та же часть, что решена Вами в Вашем примере. Если хотите - добавьте output, это будет аналог printf, только гораздо более мощный (output-format : ASCII | DBASEII | DBASEIII | EXCEL | FIXED | FOXPRO | HTML | LOTUS | SQL | XML).


А из Java программы я могу вывести данные вообще в ЛЮБОМ формате в любой файл, поток в/в, устройство визуализации. Разумеется для этого либо прийдется использовать какую-нибудь стандартную (нестандартную) библиотеку, либо самостоятельно писать процедуру экспорта. Но в любом случае я не ограничен никаким списком. А в целом это к сути нашего спора имеет весьма отдаленное отношение.


c127

>Предлагаемые вами вопросы изменяют саму суть поставленной задачи.

Для реляционной базы они ничего не меняют. В реальных системах требования и тем более отчеты меняются постоянно.


Ну давайте я продемонстрирую решение по п.1)

типы самолетов, которыми летал Scott Tiger, 1,9,12,13,18,22,28 января 2003 года

DECLARE EXTENT Tickets FOR avia.model.Ticket;
SELECT ticket.item.flight.crafttype FROM Tickets AS ticket
WHERE ticket.person.first_name = "Scott" and ticket.person.last_name = "Tiger"
and (ticket.item.day = "01.01.2003" or ticket.item.day = "09.01.2003" or ticket.item.day= ... )


К слову уверен, что этот запрос будет работать заметно быстрее именно на объектной СУБД. Напишите запрос для реляционной модели, и я объясню почему это будет именно так.

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

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


c127

Договорились, обсуждаем. То что Вы показали это "реляционная" модель в объектном исполнении, имеет место полное соответствие объект <-> таблица. В этом случае тягаться СКЛ-ем (DDL & DML) заранее проигрышный вариант, СКЛ специально создавался для создания отчетов на основе реляционных данных. Он так и называется: query language.

Нельзя ли перерписать этот пример, чтоб там было наследование или какие-то другие фичи ОМД, которые считаются преимуществом перед РМД и как-то это использовать? Интересно увидеть какую-нибудь специфику ОМД.


Согласен, я действительно придерживался близкой аналогии с типичными реляционными моделями. Но и в этом случае тягаться с SQL очень даже получается. Например, запрос 3 в моем случае будет обрабатываться много быстрее, чем в реляционной СУБД.
Что касается специфики ОМД, то полное решение не обещаю, но саму модель классов с использование наследования и прочей ОО-специфики приведу.
29 янв 05, 11:56    [1284450]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Alexey Rovdo

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

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




Alexey Rovdo

Только не рассказывайте мне, что вы действительно делаете системы, в которых конечные пользователи получают доступ к данным непосредственно через инструментарий СУБД, а не с помощью отдельного клиентского приложения или через Web. В том маловероятном случае, когда это действительно допустимо, готов уступить и согласиться с тем, что использование традиционной реляционной СУБД эффективнее, чем применение ООСУБД,


Вы задались целью вбить осиновый кол в ООМД? Непосредственно через инструментарий СУБД или сторониих прог - итерактивный запуск запросов имеет важное значение на всем протяжении жизненного цикла ИС. Не конечными пользователями, так разработчиками и админами это используется существенно на этах разработки, сопровождения. У нас юзера некоторые пишут запросы, и втюхивают их в генератор отчетов, нами же разработанный. Мало что им за инфа нужна. Опять, думаю, что ООСУБД должна предоставлять такую возможеность. Без этого ей конец. Вы уверены, что там такой возможности нет ни у одной СУБД нет? Там ить есть OQL.
29 янв 05, 20:27    [1284804]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
vadiminfo

> Alexey Rovdo
ООСУБД обладают как достоинствами, так и недостатками. К одному из недостатков относится их плохая совместимость с нерегламентированными запросами. Т.е. если пп. 1) - 3) включить в условия задачи, то это приведет к переработке представленной выше структуры классов, с тем, чтобы искомые данные находить быстрее и эффективнее.

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


> Alexey Rovdo
Только не рассказывайте мне, что вы действительно делаете системы, в которых конечные пользователи получают доступ к данным непосредственно через инструментарий СУБД, а не с помощью отдельного клиентского приложения или через Web. В том маловероятном случае, когда это действительно допустимо, готов уступить и согласиться с тем, что использование традиционной реляционной СУБД эффективнее, чем применение ООСУБД,

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


А вот здесь вы меня не правильно поняли. Я вовсе не хочу сказать, что ООСУБД всего этого не могут. Могут! В частности я уже писал, что для FastObjects есть продукт под названием FastObjects Connect, который и предназначен для решения таких задач (в т.ч. он содержит ODBC драйвер, поддерживающий стандартные SQL-92 запросы). Более того, объектные данные можно хранить не только в объектных базах. FastObjects позволяет работать с MS SQL, Oracle и DB2 совершенно прозрачно для программиста (т.е. приведенный выше пример будет работать с MS SQL в качестве хранилища данных без модификации приложения). Дело в другом - в таких задачах ООСУБД заведомо менее эффективны (в чем-то слегка, в чем-то сильнее). И будет глупо пытаться доказывать обратное.
То же самое я могу сказать и о конкретной задаче. Когда я писал "Т.е. если пп. 1) - 3) включить в условия задачи, то это приведет к переработке представленной выше структуры классов, с тем, чтобы искомые данные находить быстрее и эффективнее." я именно и имел ввиду, что переработка нужна не для того чтобы решить задачу в принципе (в принципе это, разумеется, не составляет труда, и п.1 я выше уже продемонстрировал), а именно для того, чтобы обеспечить большее быстродействие объектной СУБД по сравнению с реляционной при выполнении ВСЕХ требуемых запросов.

Так и по второй части моих замечаний. Разумеется для разработчиков и админов имеется инструментарий, позволяющий напрямую вводить OQL и SQL запросы, осуществлять мониторинг работы и исполнения запросов и делать многое другое (ко всему есть и сторонние продукты, например, для создания отчетов). Но в целом сам FastObjects (а мы сейчас все-таки сконцентрировались на рассмотрение не всех ООСУБД вообще, а именно на этом продукте) в первую очередь предназначен для построения эффективно работающих приложений и на практике чаще всего используется именно как встраиваемая база данных (т.е. пользователи приложений на базе FO могут вообще не знать о наличии СУБД как таковой). Если говорить о продуктах Versant, то есть еще одна ООСУБД - Versant Developer Suite, возможности которой в части интегрированных и дополнительных инструментов для работы админов, разработчиков и продвинутых пользователей шире (там есть и курсоры и хранимые процедуры и средство обработки SQL-запросов и др.). Но про нее я уже не могу сказать, что она проста как грабли, и использование решений на базе этой системы в нашей дискуссии на мой взгляд просто менее удобно и менее наглядно.
29 янв 05, 22:26    [1284866]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

>Только не рассказывайте мне, что вы действительно делаете системы, в которых конечные пользователи получают доступ к данным непосредственно через инструментарий СУБД, а не с помощью отдельного клиентского приложения или через Web.

Покажите требование ввода данных в Вашей же постановке задачи.

Более того в Вас сказано:"Выдать таблицу (свободные места): номер места m - класс - цена". У SergSuper-а это именно таблица. А у Вас что, какой-то System.out.println(), который не таблица, а условно файл. Не нужно спорить по этому пункту, реляционное решение поставленной Вами задачи абсолютно ПОЛНОЕ.

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

>Ну если вы действительно считаете, что в Java этот момент существенно изменит программный код, то я обязательно продемонстрирую такую возможность.

Если хотите, но лучше не надо, пожалейте свое время, к разговору это отношения не имеет.

>А из Java программы я могу вывести данные вообще в ЛЮБОМ формате в любой файл, поток в/в, устройство визуализации. Разумеется для этого либо прийдется использовать какую-нибудь стандартную (нестандартную) библиотеку, либо самостоятельно писать процедуру экспорта. Но в любом случае я не ограничен никаким списком. А в целом это к сути нашего спора имеет весьма отдаленное отношение.

Вот именно, не имеет. Зачем тогда говорить: "Вот в SQL-запросе 'нужный рейс' откуда берется? В Java программе я элементарно могу попросить пользователя ввести этот исходный параметр и поместить введенное значение в переменную. Java-программу я могу запустить для регулярного вывода информации на электронное табло и т.п." Предлагаю обсуждать токько серверную часть.

>Ну давайте я продемонстрирую решение по п.1)

Продемонстрируйте лучше решение п.3. Если Вы выберете СКЛ, то это заодно покажет насколько продвинут вариант СКЛ-я, который реализован в фастобжектс. Но я бы хотел увидеть то решение, которое Вы сами считаете лучшим.

>
DECLARE EXTENT Tickets FOR avia.model.Ticket;
SELECT ticket.item.flight.crafttype FROM Tickets AS ticket
WHERE ticket.person.first_name = "Scott" and ticket.person.last_name = "Tiger"
and (ticket.item.day = "01.01.2003" or ticket.item.day = "09.01.2003" or ticket.item.day= ... )


К слову уверен, что этот запрос будет работать заметно быстрее именно на объектной СУБД. Напишите запрос для реляционной модели, и я объясню почему это будет именно так.


Да в принципе такой же запрос
select f.*
from Fly f natural join Shedul natural join Sold s
where s.fio='Tiger Scott'
and s.date in ('2003.01.01','2003.01.09','2003.01.12','2003.01.13','2003.01.18','2003.01.22','2003.01.28')

Это не принципиально, но в отличие от Вашего, мое решение полное.

А почему ООСУБД будет работать на этом запросе быстрее, да еще заметно?

>Но совсем другое дело, когда система задействована в самом процессе выполнения этих операций. Продажа билетов на мой взгляд - одна из таких систем. Главным в ней является обеспечение самого процесса продажи билетов - обеспечение одновременной работы множества касс, непересекающееся бронирование и выписка билетов, обеспечение полной загруженности рейсов.

Этого я не понимаю. Пока не видел ни одного аргумента в пользу этого утверждения.

>Согласен, я действительно придерживался близкой аналогии с типичными реляционными моделями. Но и в этом случае тягаться с SQL очень даже получается.

Ну если в забыть о коде, который в четыре раза длиннее, то я согласен, все остальное не хуже. Но что же тогда остается?

>FastObjects позволяет работать с MS SQL, Oracle и DB2 совершенно прозрачно для программиста (т.е. приведенный выше пример будет работать с MS SQL в качестве хранилища данных без модификации приложения).

Тогда это получается просто очень дорогой ОДБЦ драйвер. В этом случае дешевле и удобнее использовать повербилдер+одбц, что даст такой же доступ ко всем реляционным БД.

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

Я даже представить себе не могу систему, для которой заранее известны абсолютно ВСЕ требуемые запросы. Возможно это какая-то бухгалтерия в очень классической ее части, с которой работает только бухгалтер классической закваски и никто больше. По-моему все-таки Вы пытаетесь решать какую-то идеальную задачу, но мы живем в реальном мире и заранее никогда неизвестно, какую информацию потребуется завтра вытащить из БД.
30 янв 05, 04:21    [1285005]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
c127

Более того в Вас сказано:"Выдать таблицу (свободные места): номер места m - класс - цена". У SergSuper-а это именно таблица. А у Вас что, какой-то System.out.println(), который не таблица, а условно файл. Не нужно спорить по этому пункту, реляционное решение поставленной Вами задачи абсолютно ПОЛНОЕ.

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


c127

>А из Java программы я могу вывести данные вообще в ЛЮБОМ формате в любой файл, поток в/в, устройство визуализации. Разумеется для этого либо прийдется использовать какую-нибудь стандартную (нестандартную) библиотеку, либо самостоятельно писать процедуру экспорта. Но в любом случае я не ограничен никаким списком. А в целом это к сути нашего спора имеет весьма отдаленное отношение.

Вот именно, не имеет. Зачем тогда говорить: "Вот в SQL-запросе 'нужный рейс' откуда берется? В Java программе я элементарно могу попросить пользователя ввести этот исходный параметр и поместить введенное значение в переменную. Java-программу я могу запустить для регулярного вывода информации на электронное табло и т.п." Предлагаю обсуждать токько серверную часть.



В принципе, я согласен рассматривать голые SQL-запросы в качестве решения задачи для РСУБД. Но всякий раз, когда кто-то пытается сравнивать длину программы на Java с длиной SQL-запроса, я просто вынужден обращать внимание на то, что сферический сервер в вакууме не является иллюстрацией практической ситуации.

Я понимаю, что для случая с ООСУБД вам бы хотелось увидеть в качестве решения OQL-запросы, чтобы сравнивать только лишь работу и эффективность запросов на сходных задачах. Но здесь и лежит принципиальное отличие объектно-ориентированных систем от реляционных - использование OQL-запросов в ООСУБД, хотя и поддерживается, но является плохой практикой (к FastObjects это относится в полной мере). Действительно эффективные объектно-ориентированные приложения не должны осуществлять выборку данных по значению (во всяком, случае этого следует всячески избегать) – они должны использовать прямую навигацию, что реализуется в программах на объектно-ориентированных языках программирования (Java, C++, C#, SmallTalk ... ). Таким образом в ООСУБД отделение базы данных от приложения противоречит всей идеологии системы. Практика использования ООСУБД FastObjects показывает, что в большинстве случаев она находит применение именно как встраиваемая СУБД, а пользователи приложений, построенных на базе этой системы, на деле вообще могут не знать о наличии в ней базы данных как таковой.

“Что же получается” – скажете вы – “мы привыкли иметь возможность работы с голыми данными и по отдельности разрабатывать как саму структуру базы данных, так и сами приложения для работы с этими данными, а объектно-ориентированные СУБД, по вашим словам не позволяют реализовать такой подход или же заведомо объявляют его неэффективным.” Да, это так. И, если хотите, именно данный факт и является основной ахилесовой пятой ООСУБД, и именно за это их критикуют многие теоретики СУБД. Но хотя кому-то это и кажется большим минусом, кто-то, наоборот, - видит большие плюсы именно в том, что разработчики приложений совершенно не должны заниматься проблемами хранения данных (все это реализуется транспарентно для приложения через механизм связывания ООСУБД с ОО-языками программирования).

Вся описанная выше идеология в полной мере соответствует ООСУБД FastObject, которую я избрал в качестве платформы для реализации тестовой задачи. Обладая возможностями обработки OQL-запросов, эта СУБД, тем не менее, поддерживает только достаточно урезанный вариант языка OQL. Этого вполне достаточно для приложений, в которых доступ к данным осуществляется преимущественно путем навигации, а запросы нужны только для поиска исходного корневого объекта от которого затем и осуществляется навигация. Именно поэтому с моей стороны заведомо проигрышным было бы пытаться строить доступ к данным только лишь на базе OQL-запросов (как предлагаете вы), и именно поэтому я по-прежнему буду в примерах преимущественно использовать код на Java. Но я не вижу серъезной проблемы, которая бы ограничивала наши возможности по сравнению эффективности двух подходов (для РСУБД – SQL, для ООСУБД – Java+OQL). Просто мы должны четко понимать границы применимости обоих методик и не акцентироваться исключительно на производных моментах, обсуждение которых неизменно приводит нас к пониманию того, что мы уходим от сути первоначальной дискуссии. Если хотите, мы можем определить и упомянутые «границы применимости», но боюсь здесь мы столкнемся со многими проблемами, касающимися возможного разнообразия платформ, выбираемых для построения приложений (например, в качестве языка разработки я бы мог выбрать и C++ и любой язык платформы .NET, а «клиентом» может быть как конечный клиент, так и сервер приложений и т.п.).

c127


>Ну если вы действительно считаете, что в Java этот момент существенно изменит программный код, то я обязательно продемонстрирую такую возможность.

Если хотите, но лучше не надо, пожалейте свое время, к разговору это отношения не имеет.


Рад, что вы это понимаете.

c127


Продемонстрируйте лучше решение п.3. Если Вы выберете СКЛ, то это заодно покажет насколько продвинут вариант СКЛ-я, который реализован в фастобжектс. Но я бы хотел увидеть то решение, которое Вы сами считаете лучшим.


Изначально все-таки предполагалось, что мы будем сравнивать эффективность решения тех вопросов, которые будут сформулированы в задаче. Но настаивая на решении этих новых вопросов вы явно пытаетесь показать преимущества РСУБД в той области, где их преимущества для меня, например, очевидны. Я не вижу смысла корпеть над пунктом 3 вашего предложения по той простой причине, что заранее признаю свое поражение именно по этому пункту. И хотя мне не вполне очевидна простота решения этой задачи на РСУБД (любопытно было бы уведить это SQL-запрос), но сама ее суть – сложная выборка и анализ хранимых данных для представления в отчете – уже говорит о том, что ООСУБД здесь менее эффективны. В частности язык запросов FastObjects, являясь урезанным подмножеством OQL, не позволит построить OQL-запрос, возвращающий требуемые данные. Для решения проблемы в FastObjects однозначно необходимо писать Java-код.

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

c127

DECLARE EXTENT Tickets FOR avia.model.Ticket;
SELECT ticket.item.flight.crafttype FROM Tickets AS ticket
WHERE ticket.person.first_name = "Scott" and ticket.person.last_name = "Tiger"
and (ticket.item.day = "01.01.2003" or ticket.item.day = "09.01.2003" or ticket.item.day= ... )


select f.*
from Fly f natural join Shedul natural join Sold s
where s.fio='Tiger Scott'
and s.date in ('2003.01.01','2003.01.09','2003.01.12','2003.01.13','2003.01.18','2003.01.22','2003.01.28')

А почему ООСУБД будет работать на этом запросе быстрее, да еще заметно?


Перед тем, как сравнивать два этих запроса, прошу пояснить мне для какой конкретно СУБД написан запрос на SQL. Также было бы полезно привести к некому единому значенателю состав хранимых данных. Так у меня имя и фамилия хранятся раздельно, а в реляционной модели – вместе. Не то чтобы это имело определяющее значение, но так было бы удобнее.

c127

>Но совсем другое дело, когда система задействована в самом процессе выполнения этих операций. Продажа билетов на мой взгляд - одна из таких систем. Главным в ней является обеспечение самого процесса продажи билетов - обеспечение одновременной работы множества касс, непересекающееся бронирование и выписка билетов, обеспечение полной загруженности рейсов.

Этого я не понимаю. Пока не видел ни одного аргумента в пользу этого утверждения.


Поясню, что я имею ввиду, когда говорю о принципиальном различии учетных систем и обеспечивающих систем.

Учетная система – это система, предназначенная для хранения данных об имевших место событиях и процессах. Т.е. сами учитываемые события и процессы имеют место вне зависимости от каких-либо данных, действий или бездействий учетной системы. В учетную систему данные попадают постфактум и не влияют на принятие первичного решения. Зачем же тогда вообще нужны такие системы? Обычно их основное назначение – предоставить возможность сложного анализа хранимых данных различными, заранее не конкретизируемыми способами, с тем, чтобы обеспечить генерацию некоторого (статичного или изменяющегося во времени набора отчетов). Например, типичная бухгалтерская система является ярким примером учетной задачи. В бухгалтерскую систему вводятся данные о совершенных сделках, платежах, операциях. Содержимое бухгалтерской системы обычно никак не влияет на сам факт совершения операций. И если система на какое-то время зависнет (выйдет из строя), то это в принципе не будет непреодолимой преградой для того, чтобы отпустить покупателю оплаченный товар.

Обеспечивающая система всегда является неотъемлемой частью технологического процесса. Причем, далеко не по формальным признакам. Фактически, внутри обеспечивающей системы присутствует своего рода обратная связь, создающая зависимость между хранимыми в системе данными и реакцией системы на различные внешние воздействия. Любая неработоспособность обеспечивающей системы означает прекращение технологического процесса, поскольку для его нормального продолжения нужен доступ к хранимым данным. Так цифровая АТС в случае выхода из строя базы данных с настройками портов при всем нашем желании не сможет обслуживать звонки. А касса не сможет продать билет, если не будет знать, какие точно места на требуемом рейсе точно свободны.

На практике очень часто (хоть и не всегда) оказывается так, что в обеспечивающих системах (многие из которых являются системами реального времени) сложные механизмы анализа и генерации нерегламентированных отчетов просто не нужны. В тех же ситуациях, когда в обеспечивающей системе продвинутая отчетность все-таки необходима, оказывается, что слишком рискованно проводить анализ непосредственно по рабочей базе данных обеспечивающей системы – гораздо безопаснее и разумнее разделить обеспечивающую и аналитическую части. Каков же вывод из всей этой теории?

Реляционные СУБД как правило являются наилучшим выбором именно для учетных систем. И таких систем в реальном мире сегодня большинство. Некоторые пытаются доказывать, что ООСУБД часто удобнее и на этом фронте. Но лично я не придерживаюсь такой точки зрения. И критерием для меня здесь выступает вероятность большого количества нерегламентированных запросов. Если такая вероятность есть (вытекает из смысла и предметной области задачи), то эффективнее будет использовать РСУБД.

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

c127

>FastObjects позволяет работать с MS SQL, Oracle и DB2 совершенно прозрачно для программиста (т.е. приведенный выше пример будет работать с MS SQL в качестве хранилища данных без модификации приложения).

Тогда это получается просто очень дорогой ОДБЦ драйвер. В этом случае дешевле и удобнее использовать повербилдер+одбц, что даст такой же доступ ко всем реляционным БД.


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

c127

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

Я даже представить себе не могу систему, для которой заранее известны абсолютно ВСЕ требуемые запросы. Возможно это какая-то бухгалтерия в очень классической ее части, с которой работает только бухгалтер классической закваски и никто больше. По-моему все-таки Вы пытаетесь решать какую-то идеальную задачу, но мы живем в реальном мире и заранее никогда неизвестно, какую информацию потребуется завтра вытащить из БД.


Вот именно поэтому вы меня и не понимаете, когда я говорю о принципиальной разнице между учетными и обеспечивающими системами. Полагаю, что вы просто на практике имели дело только с первыми. Но уверяю вас – мир гораздо разнообразнее, чем нам иногда представляется.

Например, вы априори допускаете что у системы вообще есть какое-то «завтра», в котором мы захотим вытащить из нее какую-то информацию. Но какое «завтра», может быть, например, у свежезапущенной ракеты? И какие нерегламентированные запросы могут быть к системе управления ПВО, работающей в реальном времени? В военной технике опережение на миллисекунду может иметь решающее значение и ради этой миллисекунды можно пожертвовать многими вторичными возможностями.

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

Существуют и такие области, как управление производственными линиями, управление разнообразными охранными сетями, сетями электрического, вентиляционного и прочего оборудования. Здесь также состав запросов большей частью регламентирован и мы можем создавать системы наилучшим образом адаптированные именно под такие запросы.
30 янв 05, 21:29    [1285687]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
serg99
Member

Откуда:
Сообщений: 422
Alexey Rovdo

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


Я бы не стал обобщать возможности конкретной системы (FastObjects) по работе с запросными языками на все ООСУБД, а тем более на объектную парадигму как таковую. Объектная ориентированность не является антогонистом запросных языков.

Объектная ориентированность даже не является антогонистом SQL. И одна из задач ООСУБД на мой взгляд обеспечить приемлимую скорость обработки стандартных SQL запросов.

Что касается расширенного синтаксиса связанного с объектной навигацией, то на приведенные вверху 3 задачки приходят на ум следующие выражения.

1)
Person{fio=`Scott Tiger}.seat.flight{where date in (`2003.01.01`...)}.plane.type

Пусть не смущает отсутствие SELECT. Это он и есть. Навигация через `.` аналог натуральных join.

2)
Select Number From Flight f Where date>`2002.12.31` And date<`2004.01.01` And
f.plane.type<>`TU 154` And
Count(f.seats{status=`Unsold`}) Between 10 And 20;

3)
Select Number
(Select Number From Flight f1
Where Count(f1.seat.person Intersect f2.seat.person)>9) From Flight f2;

Не думаю что это сильно короче запросов SQL, но и не сильно длинней. Я согласен с Алексеем, что объектная парадигма может дать существенные плюсы особенно на этапе проектирования систем.
31 янв 05, 01:54    [1285852]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

>Но всякий раз, когда кто-то пытается сравнивать длину программы на Java с длиной SQL-запроса, я просто вынужден обращать внимание на то, что сферический сервер в вакууме не является иллюстрацией практической ситуации.

Вы сами так поставили задачу. ИМХО постановка правильная и напрпавлена на сравнение именно серверов.

>Я понимаю, что для случая с ООСУБД вам бы хотелось увидеть в качестве решения OQL-запросы,...

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

>Таким образом в ООСУБД отделение базы данных от приложения противоречит всей идеологии системы.

Ладно, давайте рассуждать таким образом. Можно строить ООСУБД приложения (типа клиент-сервер) в виде Java+сервер, (C++)+сервер, C#+сервер, SmallTalk+сервер, причем где начинается сервер Вы сказать не можете. Так вычтите из этих систем Java, C++, C#, SmallTalk соотвсетсвенно и ту общую часть, которая останется назовите сервером. Его и будем сравнивать. Чисто формальный подход.

Кстати в ДБ2 код процедурного языка (напрмиер С) тоже типа встраивается в сервер, но это не значит, что там же живет и клиент. Уберите клиент.

>Но настаивая на решении этих новых вопросов вы явно пытаетесь показать преимущества РСУБД в той области, где их преимущества для меня, например, очевидны. Я не вижу смысла корпеть над пунктом 3 вашего предложения по той простой причине, что заранее признаю свое поражение именно по этому пункту.

Я не настаиваю и согласен с Вами, раз Вы говорите, что эти примеры не покажут характерных преимуществ, я Вам верю.

>любопытно было бы уведить это SQL-запрос

Мне тоже.

Шутка. Я знаю как решать подобные задачи, если очень интересно напишу запрос, но я не создавал БД, поэтому не будет возможности проверить, а ошибки будут наверняка. Идея может быть следующая. Построить соединение по фио (это должно быть ID) множеств пассажиров для каждой пары различных рейсов, сгруппировать по ключам рейсов (у нас это (рейс1,дата1),(рейс2,дата2)) и сказать having count()>=10. Это все один запрос, если правильно проиндексировать, то будет работать очень шустро, у нас в системе аналогичная штука крутится.

>Для решения проблемы в FastObjects однозначно необходимо писать Java-код.

Нужно писать джава код - пишите. Джава это не всегда клиент даже в РСУБД можно писать сохраненки на джаве, только не вспоминайте о вводе-выводе.

>Перед тем, как сравнивать два этих запроса, прошу пояснить мне для какой конкретно СУБД написан запрос на SQL. Также было бы полезно привести к некому единому значенателю состав хранимых данных. Так у меня имя и фамилия хранятся раздельно, а в реляционной модели – вместе. Не то чтобы это имело определяющее значение, но так было бы удобнее.

Sybase ASA, Watcom-SQL. natural join соединяет таблицы по полям с одинаковыми именами. Это не принципиально. Я им никогда не пользуюсь, тут лень было писать кучу "and". Имя-фамилия тоже не принципиально. Объедините их если хотите, Вы же автор решения. Я объединять не могу, я не автор.

>Поясню, что я имею ввиду, когда говорю о принципиальном различии учетных систем и обеспечивающих систем.............
Как следствие, мы и имеем преимущество ООСУБД в таких системах, особенно, если хранимые данные имеют достаточно сложную структуру.


Это я все понимаю и в принципе согласен. Я не видел аргументов в пользу того, что обеспечивающую систему на ООСУБД строить легче. Даже если забыть о нерегламентированных отчетах. Пока что были аргументы только в пользу того, что учетную систему на ОСУБД строить не нужно. Почему Вы считаете, что система на основе РСУБД будет иметь проблемы с непрерывностью технологического процесса?

>Наоборот, во многих случаях ООСУБД целесообразно использовать только лишь как инструмент разработки,

Зачем? Дорогвато получается. ГУЙ наверное писать непросто, в общем одни проблемы.

>Вот именно поэтому вы меня и не понимаете, когда я говорю о принципиальной разнице между учетными и обеспечивающими системами. Полагаю, что вы просто на практике имели дело только с первыми. Но уверяю вас – мир гораздо разнообразнее, чем нам иногда представляется.

Обеспечивающие тоже были, правда несложные. Никаких принципиальных проблем пока не наблюдал. Дело в том, что любую хранимую информацию рано или поздно (скорее рано) нужно обрабатывать. А иначе зачем ее хранить. Вот и лезут эти запросы. А поскольку требования часто меняются (другого не встречал), то запросы очень часто получаются нерегламентируемые.

>Например, вы априори допускаете что у системы вообще есть какое-то «завтра», в котором мы захотим вытащить из нее какую-то информацию. Но какое «завтра», может быть, например, у свежезапущенной ракеты?

Согласен. Но нахера в ракете БД? В танке еще понимаю, он накапливает информацию и взаимодействует (сбрасывает-получает) с другими единицами. Как хорошо известно в нашей конференции, там стоит интербейз, который перезагружается после каждого выстрела. В том числе из пулемета. А ракета вроде ничего большого не накапливает и ни с кем почти никогда не разговаривает. Чем меньше разговаривает тем для нее лучше. Кому там нужны транзакции и многопользовательский режим, которые самый проблемный во

>И какие нерегламентированные запросы могут быть к системе управления ПВО, работающей в реальном времени?

Да сколько угодно. В штатном режиме все регламентировано, но он тоже имеет свойство меняться. Новая техника, новые требования и пр. Редко, но бывает. По-Вашему получается БД нужно переструктурировать, поскольку появятся запросы, о которых Вы заранее не знали, т.е. нерегламентированные.
31 янв 05, 03:11    [1285872]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
c127

>Но всякий раз, когда кто-то пытается сравнивать длину программы на Java с длиной SQL-запроса, я просто вынужден обращать внимание на то, что сферический сервер в вакууме не является иллюстрацией практической ситуации.

Вы сами так поставили задачу. ИМХО постановка правильная и напрпавлена на сравнение именно серверов.



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

Полагаю разумным будет доработать SQL-решение SergSuper и привести пример Java-приложения для него. Постараюсь найти для этого время. Чтобы не заморачиваться с вводом выводом будем рассматривать отдельные процедуры, возвращающие коллекции объектов. При таком подходе, я надеюсь, все замечания о якобы имеющей место многократной разнице в длине кода также отпадут.

c127

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

...

Ладно, давайте рассуждать таким образом. Можно строить ООСУБД приложения (типа клиент-сервер) в виде Java+сервер, (C++)+сервер, C#+сервер, SmallTalk+сервер, причем где начинается сервер Вы сказать не можете. Так вычтите из этих систем Java, C++, C#, SmallTalk соотвсетсвенно и ту общую часть, которая останется назовите сервером. Его и будем сравнивать. Чисто формальный подход.

Кстати в ДБ2 код процедурного языка (напрмиер С) тоже типа встраивается в сервер, но это не значит, что там же живет и клиент. Уберите клиент.


Если подходить к вопросу с чисто теоретических позиций, то клиента, разумеется, убрать можно. Но я не сторонник такого метода. Все-таки на практике приходится работать с конкретными продуктами и то, что они теоретически могли бы поддерживать какую-то функциональность, но практически этого не делают, душу никак не греет. Так что здесь я уступаю место serg99, который выше уже продемонстрировал возможность манипулирования именно теоретическими конструкциями.

Если же оставаться в рамках практики, то мне прийдется учитывать все ограничения выбранного мною продукта FastObjects. С одной стороны, таких ограничений довольно много (гораздо больше, чем, например, у VDS), но с другой - это очень простой в использовании продукт, который идеально подходит для быстрого построения приложений и примеров.
Я не имею практики работы с Sybase ASA, поэтому нахожу более удобным рассматривать SQL-примеры на базе MS SQL. Не отвергая совсем возможность формально-теоретического подхода, лично я все-таки постараюсь приводить примеры именно в рамках функциональности названных продуктов.

c127


>Наоборот, во многих случаях ООСУБД целесообразно использовать только лишь как инструмент разработки,

Зачем? Дорогвато получается. ГУЙ наверное писать непросто, в общем одни проблемы.


Затем, что в некоторых случаях это может кардинально ускорить процесс разработки сложной системы. И цена используемых продуктов с лихвой окупается экономией на стоимости самой разработки и снижением рисков невыпуска продукта в срок и снадлежащим качеством. Разумеется все это может иметь место только в достаточно крупных проектах (по моим оценкам с бюджетами не менее 20-50 К$). Для написания GUI тоже имеются специальные средства, так что каких-то специфичных проблем не возникает.

c127

>Вот именно поэтому вы меня и не понимаете, когда я говорю о принципиальной разнице между учетными и обеспечивающими системами. Полагаю, что вы просто на практике имели дело только с первыми. Но уверяю вас – мир гораздо разнообразнее, чем нам иногда представляется.

Обеспечивающие тоже были, правда несложные. Никаких принципиальных проблем пока не наблюдал. Дело в том, что любую хранимую информацию рано или поздно (скорее рано) нужно обрабатывать. А иначе зачем ее хранить. Вот и лезут эти запросы. А поскольку требования часто меняются (другого не встречал), то запросы очень часто получаются нерегламентируемые.

>Например, вы априори допускаете что у системы вообще есть какое-то «завтра», в котором мы захотим вытащить из нее какую-то информацию. Но какое «завтра», может быть, например, у свежезапущенной ракеты?

Согласен. Но нахера в ракете БД? В танке еще понимаю, он накапливает информацию и взаимодействует (сбрасывает-получает) с другими единицами. Как хорошо известно в нашей конференции, там стоит интербейз, который перезагружается после каждого выстрела. В том числе из пулемета. А ракета вроде ничего большого не накапливает и ни с кем почти никогда не разговаривает. Чем меньше разговаривает тем для нее лучше. Кому там нужны транзакции и многопользовательский режим, которые самый проблемный во

>И какие нерегламентированные запросы могут быть к системе управления ПВО, работающей в реальном времени?

Да сколько угодно. В штатном режиме все регламентировано, но он тоже имеет свойство меняться. Новая техника, новые требования и пр. Редко, но бывает. По-Вашему получается БД нужно переструктурировать, поскольку появятся запросы, о которых Вы заранее не знали, т.е. нерегламентированные.


Трудно сразу написать обо всем. Поэтому и приходится поправляться. Я ни в коем разе не утверждаю, что ООСУБД не следует применять там, где в принципе могут возникнуть нерегламентированные запросы. И ни в коем разе из появления в регламенте новых запросов не следует, что обязательно необходима переработка объектной структуры. Но если общее количество случайных нерегламентированных запросов при эксплуатации системы может существенно превысить количество регламентированных и учтенных на этапе разработки запросов, вот именно тогда применение РСУБД априори более целесообразно. Так и с изменением объектной структуры. Всегда существует некоторая критическая масса. Когда в результате изменения требований и разнообразных модификаций оборудования количество новых запросов к системе превысит в разы состав первоначального регламента, то скорее всего изменение объектной структуры станет неизбежным. Многое здесь, разумеется, зависит от конкреных запросов и от того, как они ложатся на существующую объектную структуру. Следует также понимать, что когда я говорю о "большинстве запросов", то имею ввиду именно соотношение разных запросов при работе системы. Т.е. самих вариантов нерегламентированных запросов может быть очень и очень много, но если они достаточно редки, то выполняющиеся в тысячи раз чаще регламентированные запросы даже при небольшом числе их возможных вариантов составляют в системе большинство.

Ну а про ракеты и базы данных могу только сказать, что компьютеризация всего, что только можно идет весьма активно. И если вчера базы данных использовались только в больших ракетах стратегического назначения, то завтра их засунут даже в патроны. Где по вашему ракета берет данные о местонахождении цели, пути (возможных путях) следования к цели, рельефе местности, предусмотренных реакциях на различные события (маневрирование воздушной цели, помехи) и т.п.

Разумеется в этой сфере находят применение различные системы и критиковать использование интербейза в танках Абрамс я не стану. Но танков и прочей самоходной и стреляющей пакости в мире насоздано очень много. И применяются там самые разнообразные решения. Так Versant используется во французской системе управления артиллерией Atlas. Но в большей части такая информация является закрытой, в особенности по новейшим разработкам.

Главное, что вы согласились с тем, что существуют области и задачи, в которых действительно можно строго регламентировать большую часть запросов к данным (т.е. при работе системы значительная часть обращений за данными будет происходить в рамках регламента).
31 янв 05, 11:30    [1286484]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Вот нашел интересную статью. Она хоть и достаточно старая, но во многом соответствует моему взгляду на нынешнее состояние ООСУБД FastObjects (ограничения языка запросов и связанные с этим языком плюсы и минусы при сопоставлении с РСУБД).
31 янв 05, 11:58    [1286603]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

Я предлагаю не писать сочинения на тему тему "что в принципе можно сделать на ООБД (РСУБД)", а сосредоточиться на конкретных примерах и конкретном коде. Это относится и ко мне и к Вам. Мы так ни до чего не договоримся. Давайте говорить только о том, что мы готовы подтвердить кодом или подробной схемой.

>Полагаю разумным будет доработать SQL-решение SergSuper и привести пример Java-приложения для него. ... Чтобы не заморачиваться с вводом выводом будем рассматривать отдельные процедуры, возвращающие коллекции объектов. При таком подходе, я надеюсь, все замечания о якобы имеющей место многократной разнице в длине кода также отпадут.

Решение SergSuper в доработке по большому счету не нуждается. Если хотите доработать свое - пожалуйста, хоть заново перепишите. Но только в рамках постановки задачи, не выдвигая дополнительных требований по вводу-выводу и других.

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

Вот там и посмотрим.

>Если же оставаться в рамках практики, то мне прийдется учитывать все ограничения выбранного мною продукта FastObjects. С одной стороны, таких ограничений довольно много (гораздо больше, чем, например, у VDS), но с другой - это очень простой в использовании продукт, который идеально подходит для быстрого построения приложений и примеров.

Выберите другой сервер. Выбор за вами, задача одна: ПРОДЕМОНСТРИРОВАТЬ преимущества ООБД.

>Я не имею практики работы с Sybase ASA, поэтому нахожу более удобным рассматривать SQL-примеры на базе MS SQL. Не отвергая совсем возможность формально-теоретического подхода, лично я все-таки постараюсь приводить примеры именно в рамках функциональности названных продуктов.

Буду стараться. Пока что различия в диалектах были не принципиалны.

>Затем, что в некоторых случаях это может кардинально ускорить процесс разработки сложной системы. И цена используемых продуктов с лихвой окупается экономией на стоимости самой разработки и снижением рисков невыпуска продукта в срок и снадлежащим качеством.

Приведите пример, а то я не понимаю. Какой смысл разговаривать с РСУБД через фастобджектс?
1 фев 05, 04:07    [1289083]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Злой Хорёк
Member

Откуда:
Сообщений: 24
2 Alexey Rovdo

Алексей, не кажется ли вам что вы слишком ударились в ООП, не понимая его сути? Ваши заявления о провокациях и о том что SergSuper не решил задачу это так - желание обрызгать грязью оппонента, когда он прав. Вставка записей не относилась к решению задачи. Перескакивание на GUI это попытка увильнуть от ответственности. То что вы пытались доказать - это чистой воды изрядная ерундистика. Во первых если вы профессиональный разработчик ООБД то где же ваши спецификации на объекты? Самолет завтра сняли с линий - вы удаляете его из CraftType и где мне по нему информацию искать? Правильная архитектура следующая есть PlaneSpecification {модель, кол-во мест ...} и есть Plane {серийный номер ...}. Вы же распинались что ваша модель на полноту претендует, в отличие от модели SergSuper? Это же азы ООП. Ну ладно пропустим это будем считать, что это сделано для упрощения модели. Второе ваше утверждение, что ОО модель плохо работает с нерегламентироваными запросами - это заявление вчерашнего студента. Вам шаблон Query Object не знаком? Что вам мешает создать собственный класс ответственный за выполнение сложных запросов для каждого типа объектов по шаблону Factory Method? Или вы считаете использование шаблонов ООП таких зубров как Fowler, Larman, Gamma не стоящим внимание? А если использовать только итерацию, то далеко ходить не надо. Зачем вообще БД, когда все записи вы можете хранить в виде сериализованных данных и использовать итерационный метод доступа к ним? Это очень на DBF смахивает. А объясните зачем скрещивание элемента доступных билетов и билета в объекте Ticket? Есть билет с местом, есть список свободных мест и должен быть еще класс представляющий данную связь между билетом и свободными местами. Где он? Я его не вижу? Это просто непонимание основ ООП.
У участников форума сложилось желание обходить ООБД стороной, после вашего описания проекта. Ну оно и верно. Использование ООП не панацея от ошибок, медленной работы приложений и т.д. ООП способ борьбы со сложностью и возможность использования повторного кода не вдаваясь в то как устроен объект внутри. А всякие заявления о том что это быстрее работает это ЧУШЬ. Не ОО приложение написаное на голом асме будет летать в десятки раз быстрее.
1 фев 05, 06:39    [1289112]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Злой Хорёк
2 Alexey Rovdo

Алексей, не кажется ли вам что вы слишком ударились в ООП, не понимая его сути? Ваши заявления о провокациях и о том что SergSuper не решил задачу это так - желание обрызгать грязью оппонента, когда он прав. Вставка записей не относилась к решению задачи. Перескакивание на GUI это попытка увильнуть от ответственности. То что вы пытались доказать - это чистой воды изрядная ерундистика. Во первых если вы профессиональный разработчик ООБД то где же ваши спецификации на объекты? Самолет завтра сняли с линий - вы удаляете его из CraftType и где мне по нему информацию искать? Правильная архитектура следующая есть PlaneSpecification {модель, кол-во мест ...} и есть Plane {серийный номер ...}. Вы же распинались что ваша модель на полноту претендует, в отличие от модели SergSuper? Это же азы ООП. Ну ладно пропустим это будем считать, что это сделано для упрощения модели. Второе ваше утверждение, что ОО модель плохо работает с нерегламентироваными запросами - это заявление вчерашнего студента. Вам шаблон Query Object не знаком? Что вам мешает создать собственный класс ответственный за выполнение сложных запросов для каждого типа объектов по шаблону Factory Method? Или вы считаете использование шаблонов ООП таких зубров как Fowler, Larman, Gamma не стоящим внимание? А если использовать только итерацию, то далеко ходить не надо. Зачем вообще БД, когда все записи вы можете хранить в виде сериализованных данных и использовать итерационный метод доступа к ним? Это очень на DBF смахивает. А объясните зачем скрещивание элемента доступных билетов и билета в объекте Ticket? Есть билет с местом, есть список свободных мест и должен быть еще класс представляющий данную связь между билетом и свободными местами. Где он? Я его не вижу? Это просто непонимание основ ООП.
У участников форума сложилось желание обходить ООБД стороной, после вашего описания проекта. Ну оно и верно. Использование ООП не панацея от ошибок, медленной работы приложений и т.д. ООП способ борьбы со сложностью и возможность использования повторного кода не вдаваясь в то как устроен объект внутри. А всякие заявления о том что это быстрее работает это ЧУШЬ. Не ОО приложение написаное на голом асме будет летать в десятки раз быстрее.


Готов признать, что доля правды в вашей критике есть. Но только доля. Во-первых, я не одногкратно писал, что моя модель данных не является действительно удачной с точки зрения ООП. И я уже признавал, что эта модель по сути - реляционная модель, перенесенная в объектную базу. Представте другую, действительно отвечающую принципам ООП так, как вы их понимаете, а я проанализирую на примере реализацию задачи в этой модели.

А работает БЫСТРЕЕ. А вот почему и где - будем разбираться ниже.

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

Лишний раз убеждаюсь, что спорить без рассмотрения реальных работающих примеров - только время терять. Поэтому см. ниже.
1 фев 05, 10:09    [1289438]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Ха-Ха!
Вот что значит не полениться. Взял да и написал Java-приложение, работающее с базой MS SQL 2000, идентичное тому, что я написал ранее для FastObjects.
Я слегка изменил SQL-модель, предложенную SergSuper и переименовал в ней поля для достижения максимальной похожести и идентичности состава хранимых данных с той ОО-моделью, которую я использовал в Java-приложении для FastObjects.
Здесь, здесь и здесь высказывались замечания по поводу неравной длины представленных решений и якобы имеющих место преимуществах SQL именно в связи с этим.
Но стоило сравнять возможности и платформу по обим решениям, как ситуация изменилась на обратную. Итак демонстрирую решение для MS SQL 2000.

Остается один вопрос. Почему же вариант для FastObjects (при использовании ОО-хранилища) будет работать быстрее, чем вариант для MS SQL? Это объяснить, а тем более продемонстрировать, будет сложнее. Ответ готовлю.

Структура базы данных:


CREATE TABLE Person (
       id                   int NOT NULL,
       first_name           varchar(255) NULL,
       last_name            varchar(255) NULL,
       PRIMARY KEY (id ASC)
)
go


CREATE TABLE Crafttype (
       id                   int NOT NULL,
       description          varchar(255) NULL,
       PRIMARY KEY (id ASC)
)
go


CREATE TABLE Seat (
       id                   int NOT NULL,
       level                int NULL,
       crafttype_id         int NOT NULL,
       number               int NULL,
       PRIMARY KEY (id ASC), 
       FOREIGN KEY (crafttype_id)
                             REFERENCES Crafttype  (id)
)
go


CREATE TABLE City (
       id                   int NOT NULL,
       name                 varchar(255) NOT NULL,
       PRIMARY KEY (id ASC)
)
go


CREATE TABLE Flight (
       id                   int NOT NULL,
       description          varchar(255) NULL,
       crafttype_id         int NOT NULL,
       startpoint_id        int NOT NULL,
       endpoint_id          int NOT NULL,
       PRIMARY KEY (id ASC), 
       FOREIGN KEY (endpoint_id)
                             REFERENCES City  (id), 
       FOREIGN KEY (startpoint_id)
                             REFERENCES City  (id), 
       FOREIGN KEY (crafttype_id)
                             REFERENCES Crafttype  (id)
)
go


CREATE TABLE Item (
       id                   int NOT NULL,
       day                  varchar(20) NULL,
       flight_id            int NOT NULL,
       PRIMARY KEY (id ASC), 
       FOREIGN KEY (flight_id)
                             REFERENCES Flight  (id)
)
go


CREATE TABLE Ticket (
       id                   int NOT NULL,
       cost                 money NULL,
       person_id            int NULL,
       item_id              int NOT NULL,
       seat_id              int NOT NULL,
       PRIMARY KEY (id ASC), 
       FOREIGN KEY (seat_id)
                             REFERENCES Seat  (id), 
       FOREIGN KEY (person_id)
                             REFERENCES Person  (id), 
       FOREIGN KEY (item_id)
                             REFERENCES Item  (id)
)
go

Инициализация базы тестовыми данными.

INSERT INTO City(id, name) VALUES (1, 'A')
INSERT INTO City(id, name) VALUES (2, 'B')
INSERT INTO City(id, name) VALUES (3, 'C')

INSERT INTO Crafttype(id, description) VALUES (1, 'Boeing 747')
INSERT INTO Crafttype(id, description) VALUES (2, 'TU 154')

INSERT INTO Flight(id, description, startpoint_id, endpoint_id, crafttype_id) 
   VALUES (1, 'A-B', 1, 2, 1)
INSERT INTO Flight(id, description, startpoint_id, endpoint_id, crafttype_id) 
   VALUES (2, 'B-C', 2, 3, 1)
INSERT INTO Flight(id, description, startpoint_id, endpoint_id, crafttype_id) 
   VALUES (3, 'C-A', 3, 1, 1)
INSERT INTO Flight(id, description, startpoint_id, endpoint_id, crafttype_id) 
   VALUES (4, 'C-B', 3, 2, 2)
INSERT INTO Flight(id, description, startpoint_id, endpoint_id, crafttype_id) 
   VALUES (5, 'B-A', 2, 1, 2)
INSERT INTO Flight(id, description, startpoint_id, endpoint_id, crafttype_id) 
   VALUES (6, 'A-C', 1, 3, 2)

INSERT INTO Seat(id, number, level, crafttype_id)    VALUES (1, 1, 1, 1)
INSERT INTO Seat(id, number, level, crafttype_id)    VALUES (2, 2, 1, 1)
INSERT INTO Seat(id, number, level, crafttype_id)    VALUES (3, 3, 1, 1)
INSERT INTO Seat(id, number, level, crafttype_id)    VALUES (4, 4, 2, 1)
INSERT INTO Seat(id, number, level, crafttype_id)    VALUES (5, 5, 2, 1)
INSERT INTO Seat(id, number, level, crafttype_id)    VALUES (6, 1, 2, 2)
INSERT INTO Seat(id, number, level, crafttype_id)    VALUES (7, 2, 2, 2)
INSERT INTO Seat(id, number, level, crafttype_id)    VALUES (8, 3, 2, 2)
INSERT INTO Seat(id, number, level, crafttype_id)    VALUES (9, 4, 1, 2)
INSERT INTO Seat(id, number, level, crafttype_id)    VALUES (10, 5, 1, 2)


INSERT INTO Item(id, day, flight_id) VALUES(1, '01.01.2005', 1)
INSERT INTO Item(id, day, flight_id) VALUES(2, '01.01.2005', 2)
INSERT INTO Item(id, day, flight_id) VALUES(3, '01.01.2005', 3)
INSERT INTO Item(id, day, flight_id) VALUES(4, '02.01.2005', 4)
INSERT INTO Item(id, day, flight_id) VALUES(5, '02.01.2005', 5)
INSERT INTO Item(id, day, flight_id) VALUES(6, '02.01.2005', 6)
INSERT INTO Item(id, day, flight_id) VALUES(7, '01.01.2005', 1)
INSERT INTO Item(id, day, flight_id) VALUES(8, '01.01.2005', 2)
INSERT INTO Item(id, day, flight_id) VALUES(9, '01.01.2005', 3)


Java-приложение

import com.microsoft.jdbc.sqlserver.*;
import com.borland.dx.sql.dataset.*;

public class Avia_sql {
  public static void main( String[] args ) {
    Database db1 = new Database();
    db1.addDriver("com.microsoft.jdbc.sqlserver.SQLServerDriver");
    db1.setConnection (new ConnectionDescriptor 
       "jdbc:microsoft:sqlserver://localhost:2433", "test", "test"));
    db1.openConnection();

    ...
   (выполнение тестовых задач)
    ...
    db1.closeConnection();
  }
}

А теперь сравним собственно выполнение тестовой задачи для Запроса 1.
Напоминаю:
Дано: дата d, маршрут [Z1, Z2]
Выдать таблицу (билеты в наличии): рейс - класс - кол-во мест

FastObjects

txn = pm.currentTransaction();
txn.begin();

itemExtent = pm.getExtent( avia.model.Item.class, true );
iter = itemExtent.iterator();
com.poet.jdo.Extents.setFilter( iter,
   "WHERE this.day = \"01.01.2005\" and this.flight.startpoint.name = \"A\" " +
   "and  this.flight.endpoint.name = \"B\" " );

System.out.println("id  Date       Description  Class    Free seats");
   while (iter.hasNext() ) {
      Item itm = (Item) iter.next();
      System.out.println( itm.id + "   " + itm.day + " " +
                                 itm.flight.description + "          1-st     " +
                                 Integer.toString(itm.flight.crafttype.seats1.size() -
                                 itm.tickets1.size()) );
      System.out.println( itm.id + "   " + itm.day + " " +
                                 itm.flight.description + "          2-nd     " +
                                 Integer.toString(itm.flight.crafttype.seats2.size() - 
                                 itm.tickets2.size()) );
   }

        txn.commit();


MS SQL 2000

QueryDataSet qds = new QueryDataSet();
qds.setQuery(new QueryDescriptor(db1,
   "SELECT Item.id, Item.day, Flight.description, Seat.level, " +
   "Count(Seat.id)-Count(Seat2.id) AS free_seats " +
   "FROM Item INNER JOIN Flight ON Flight.id = Item.flight_id " +
   "INNER JOIN CraftType ON CraftType.id = Flight.crafttype_id " +
   "INNER JOIN Seat ON Seat.crafttype_id = CraftType.id " +
   "INNER JOIN City AS City1 ON Flight.startpoint_id = City1.id " +
   "INNER JOIN City AS City2 ON Flight.endpoint_id = City2.id " +
   "LEFT JOIN Ticket ON Ticket.item_id = Item.id " +
   "LEFT JOIN Seat AS Seat2 ON Ticket.seat_id = Seat2.id and " +
   "Seat2.level = Seat.level " +
   "WHERE Item.day = \'01.01.2005\' and City1.name = \'A\' and  " +
   "City2.name = \'B\' " +
   "Group BY Item.id, Item.day, Flight.description, Seat.level " ));

qds.executeQuery();

System.out.println("id  Date       Description  Class    Free seats");
while (qds.inBounds()) {
      System.out.println( Integer.toString(qds.getInt("id")) + "   " +
                              qds.getString("day") + " " + qds.getString("description") +
                              "          " + Integer.toString(qds.getInt("level")) + "        " +
                              Integer.toString(qds.getInt("free_seats")) );
      qds.next();
   }

А вот теперь, когда есть конкретные реализации для конкретных (вполне реальных) и идентичных в обоих случаях условий, давайте сравнивать длину кода. И где же код короче ?

Сто раз был прав PArth, когда писал:
... при реализации моих задач в объектной схеме сложность запросов значительно уменьшается - вполне достаточно простых select'ов и короткой навигации по ссылкам (а insert и update изчезают совсем...) В реляционной же реализации (моих задач) запросы гораздо сложнее...

Взгляните на код для FastObjects. Что же еще принципиально отличает этот код от кода для MS SQL? А то, что при написании этого кода вообще не был использован SQL. Т.е. разрабатывать приложения на FO могут программисты совершенно незнакомые с этим языком (достаточно знания ОО-программирования и любого из языков Java, C++ или C#).

А раз получаемый код проще, то разработка сложных приложений на базе FastObjects будет весьма осмысленна (экономия денег, сокращение сроков, снижение рисков) даже при том условии, что оконечным хранилищем данных будет реляционная СУБД, такая как MS SQL. Как это достигается? Понятно, что нужно выполнить ряд манипуляций по созданию базы и (если это необходимо) тонкой настройке мэппинга. В приложении же на Java нам нужно будет изменить только строку коннекта с базой:


Было (все данные хранились в ОО-БД FastObjects):

pmfProps.put("javax.jdo.option.ConnectionURL",
   "fastobjects://LOCAL/W:/Borland Studio Projects/Avia_proj/avia_base");

Становится (все данные хранятся в БД MS SQL Server, имя базы test2):

pmfProps.put("javax.jdo.option.ConnectionURL",
   "fastobjects://MSSQL$localhost/test2");

Аналогично можем работать с Oracle или DB2. При этом весь функционал FastObjects, использовавшийся при написании Java-приложения, выбирающего данные из ОО-хранилища FastObjects (локальный файл или сервер), будет работать как ни в чем не бывало вне зависимости от того, где собственно хранятся данные.
1 фев 05, 11:07    [1289642]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Остается один вопрос.
Почему приложение для FastObjects (при использовании ОО-хранилища) в рассмотренном выше будет еще и быстрее, чем приложение для MS SQL Server?
Объяснение этому факту лежит в особенностях обработки join-операций на сервере реляционной СУБД и в особенностях прямой навигации по связям в объектной базе данных.
1 фев 05, 11:18    [1289681]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Чисто практический вопрос:
com.poet.jdo.Extents.setFilter( iter,
   "WHERE this.day = \"01.01.2005\" and this.flight.startpoint.name = \"A\" " +
   "and  this.flight.endpoint.name = \"B\" " );
Этот код отрабатывает где? На клиенте? Сервере? Он преобразуется в SQL и посылается на сервер? Можно посмотреть, какой sql получается?
Просто интересно.

-- Tygra's --
1 фев 05, 11:18    [1289683]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Alexey Rovdo
Помнится Вы сами писали, что нужно рассматривать технологию в том контексте, в котором она есть (применительно к FastObjects - это сервер и клиент вместе). Теперь Вы нам привели зачем то Java код для решения MSSQL - честно говоря достаточно было написать просто запрос, откуда он будет выполнен - с Java, Delphi, или вообще внутри ХП - это дело третье. Далее Вы нажали на то, что у Вас код короче - честно говоря это меня огорчило - люди которые путают производительность системы с длиной кода производят недостаточное впечатление, как специалистов. Можем позвать Антона Андреевича, он Вам на MUMPS вообще код в одну строчку напишет загогулинами и закорючками и сделает вывод, что MUMPS круче.

Теперь собственно говоря по примеру - я сильно разбираться не стал, однако кое чего увидел: для MSSQL используется аггрегирующий запрос, т.е. СУБД оптимизирует его, наиболее эффективно получает информацию, обрабатывает, аггрегирует и возвращает клиенту конечный результат. Тут все просто и понятно - все сделал сервер, клиентское приложение по сети только получило результат. Закономерный вопрос, что делает вот этот код:
      System.out.println( itm.id + "   " + itm.day + " " +
                                 itm.flight.description + "          1-st     " +
                                 Integer.toString(itm.flight.crafttype.seats1.size() -
                                 itm.tickets1.size()) );
size() я так понимаю функция возврата значений в коллекции seats1 ? Если это так, то означает ли это, что Ваш пример сначала вытащит на клиентское приложение все обьекты этой коллекции и только потом будет считать их кол-во ? Если это так, то спрашивается, где тут порылась производительность, если с хранилища данных вытаскиваются все данные по сети на клиента и только потом обрабатываются ? Так что прошу обьяснений данного куска кода без рассуждений, что он короче, читабельней, красивей и т.д. и т.п. - это все второстепенно.
1 фев 05, 11:23    [1289721]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
ASCRUS

Помнится Вы сами писали, что нужно рассматривать технологию в том контексте, в котором она есть (применительно к FastObjects - это сервер и клиент вместе). Теперь Вы нам привели зачем то Java код для решения MSSQL - честно говоря достаточно было написать просто запрос, откуда он будет выполнен - с Java, Delphi, или вообще внутри ХП - это дело третье.


Лично я с этим утверждение согласен и уже говорил об этом. Но уж больно некоторым понравилось критиковать мой код за его длину. Вот и пришлось уравнять условия.

ASCRUS

Далее Вы нажали на то, что у Вас код короче - честно говоря это меня огорчило - люди которые путают производительность системы с длиной кода производят недостаточное впечатление, как специалистов. Можем позвать Антона Андреевича, он Вам на MUMPS вообще код в одну строчку напишет загогулинами и закорючками и сделает вывод, что MUMPS круче.


Короче - не значит проще, понятнее или эффективнее. Некоторым нравится сравнивать по размеру (мне не нравится). Но интересно как бы вы ранжировали мои два примера именно по простоте, читабельности кода и эффективности.

ASCRUS

Теперь собственно говоря по примеру - я сильно разбираться не стал, однако кое чего увидел: для MSSQL используется аггрегирующий запрос, т.е. СУБД оптимизирует его, наиболее эффективно получает информацию, обрабатывает, аггрегирует и возвращает клиенту конечный результат. Тут все просто и понятно - все сделал сервер, клиентское приложение по сети только получило результат. Закономерный вопрос, что делает вот этот код:
      System.out.println( itm.id + "   " + itm.day + " " +
                                 itm.flight.description + "          1-st     " +
                                 Integer.toString(itm.flight.crafttype.seats1.size() -
                                 itm.tickets1.size()) );
size() я так понимаю функция возврата значений в коллекции seats1 ? Если это так, то означает ли это, что Ваш пример сначала вытащит на клиентское приложение все обьекты этой коллекции и только потом будет считать их кол-во ? Если это так, то спрашивается, где тут порылась производительность, если с хранилища данных вытаскиваются все данные по сети на клиента и только потом обрабатываются ? Так что прошу обьяснений данного куска кода без рассуждений, что он короче, читабельней, красивей и т.д. и т.п. - это все второстепенно.


Существует два вида хранимых объектов - независимые и встраиваемые. Описанный вами порядок работы FastObjeсts действительно может иметь место, если сами объекты коллекции seats будут встраиваемыми объектами (это настраивается в JDO-файле метаданных). При этом они будут фактически частью объекта Сrafttype и доступ (ссылки) к ним будет возможен только через этот объект. Но в моем примере объекты seats не являются встраиваемыми. Это значит, что обращение itm.flight.crafttype.seats1.size() не приведет к загрузке всех объектов коллекции на клиента. Оно приведет к загрузке одного объекта Item, одного Flight, одного Crafttype (в т.ч. и объекта-коллекции Seats, который сам по себе является одним из атрибутов объекта Crafttype, т.е. встроен в объект Crafttype). Но объект-коллекция содержит только ссылки на объекты-члены коллекции, т.е. сами эти объекты-члены загружаться не будут. Мы могли бы избежать и встраивания объекта-коллекции Seats в объект Crafttype. Для этого нам бы пришлось ввести вместо встраиваемого класса HashSet собственный класс, реализующий нужные нам механизмы работы с коллекциями, и определить, что объекты данного класса являются независимыми. В этом случае мы бы могли обращаться за данными, например, так: itm.flight.crafttype.size1 (размер коллекции) и itm.flight.crafttype.my_collection_seats1.element[1] (1-й элемент коллекции).

Отвечая на этот вопрос, я пришел к выводу, что от большей адаптации моей модели классов под требования ООП мне, пожалуй, не отвертеться. Все равно в итоге мы прийдем к пониманию ряда недостатков, которые сейчас заложены в нее на концептуальном уровне. Но тем и интереснее процесс. Прийдем - буду показывать, как их следует исправлять.
1 фев 05, 13:01    [1290268]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ну и как Вы собираетесь исправлять концептуальный недостаток, мешающий использованию нерегламентированных запросов ?
Кстати, длина сравнивалась не просто так, а как источник потенциальных ошибок. ИМХО навигационный код больший рассадник ошибок, чем отлаженные SQL-запросы с примитивнейшим вспомогательным кодом.
1 фев 05, 13:06    [1290287]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
tygra
Чисто практический вопрос:
com.poet.jdo.Extents.setFilter( iter,
   "WHERE this.day = \"01.01.2005\" and this.flight.startpoint.name = \"A\" " +
   "and  this.flight.endpoint.name = \"B\" " );
Этот код отрабатывает где? На клиенте? Сервере? Он преобразуется в SQL и посылается на сервер? Можно посмотреть, какой sql получается?
Просто интересно.

-- Tygra's --


Этот код накладывает фильтр на пространство класса Item и определяет итератор iter. Т.е. теперь через этот итератор будут доступны только те объекты, которые на сервере проходят проверку WHERE ... . Сама выборка объекта с сервера может происходить только в тот момент когда мы позиционируемся на соответствующий объект в итераторе командой iter.next() . Впрочем, если нам нужно, мы можем за одно обращение к серверу выбрать сразу все объекты, доступные через итератор (с учетом отрабатываемого на сервере фильтра).
Разумеется никакого SQL-кода здесь не возникает, поскольку мы обсуждаем работу с сервером объектно-ориентированной СУБД FastObjects.
1 фев 05, 13:10    [1290305]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Gluk (Kazan)
Ну и как Вы собираетесь исправлять концептуальный недостаток, мешающий использованию нерегламентированных запросов ?
Кстати, длина сравнивалась не просто так, а как источник потенциальных ошибок. ИМХО навигационный код больший рассадник ошибок, чем отлаженные SQL-запросы с примитивнейшим вспомогательным кодом.


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


ИМХО навигационный код больший рассадник ошибок, чем отлаженные SQL-запросы с примитивнейшим вспомогательным кодом.

Это мнение многих противников ООП. Но многие сторонники ООП его не приемлют. Священные войны на эту тему бушуют уже давно. На мой же взгляд тут даже не о чем спорить - можно только обмениваться декларациями. Каждый имеет право на собственное мнение и выбирает тот инструментарий, с которым ему работать приятнее (я даже не говорю об относительной эффективности разных подходов, поскольку эффективность самого разработчика как профессионала здесь гораздо важнее).
1 фев 05, 13:28    [1290386]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Я прагматик, мне покласть на Ваши войны. Если у меня найдется задача, которая потребует ОО подхода в ХРАНЕНИИ данных, с удовольствием приму Вашу веру. :P
1 фев 05, 13:35    [1290416]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Gluk (Kazan)
Я прагматик, мне покласть на Ваши войны. Если у меня найдется задача, которая потребует ОО подхода в ХРАНЕНИИ данных, с удовольствием приму Вашу веру. :P


Я тоже прагматик и войны меня не заводят. Но вот любопытно.
А если у вас найдется задача, которая потребует ОО подхода в ОБРАБОТКЕ данных, как вы поступите ?
1 фев 05, 13:48    [1290482]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dogen
Member

Откуда: Гондурас
Сообщений: 2976
Alexey Rovdo
Gluk (Kazan)
Я прагматик, мне покласть на Ваши войны. Если у меня найдется задача, которая потребует ОО подхода в ХРАНЕНИИ данных, с удовольствием приму Вашу веру. :P


Я тоже прагматик и войны меня не заводят. Но вот любопытно.
А если у вас найдется задача, которая потребует ОО подхода в ОБРАБОТКЕ данных, как вы поступите ?

Например?
1 фев 05, 13:52    [1290509]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 34   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить