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

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


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


Я пользуюсь Delphi. Как я уже сказал, я прагматик.
1 фев 05, 14:05    [1290584]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Gluk (Kazan)

Я пользуюсь Delphi. Как я уже сказал, я прагматик.


А что вы можете сказать о полезности и практической целесообразности использования в Delphi такой фичи как Bold (ECO II) - инструментария объектно-реляционного отображения, имеющего возможности во многом схожие с возможностями FastObjects SQL Object Factory и Versant Open Access JDO (продукты Versant не интегрируются с Delphi - они предназначены для использования в таких средах разработки как MS Visual Studio, JBuiler, C++ Builder, IBM WebSphere Studio Application Developer, Sun One Studio и др.) ?

Представляете ли вы себе задачи, в которых Bold мог бы быть полезен?
1 фев 05, 15:26    [1290975]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
С глубоким отвращением, как и все мои товарищи
1 фев 05, 15:28    [1290990]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
У меня есть самописные библиотеки, позволяющие в приемлемое время решать те задачи, которые перед нами ставятся. В обчем мне этот Bold нафиг не вперся.
1 фев 05, 15:29    [1290995]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Gluk (Kazan)
У меня есть самописные библиотеки, позволяющие в приемлемое время решать те задачи, которые перед нами ставятся. В обчем мне этот Bold нафиг не вперся.


Лично я с ним не работал. Так что интересно, что конкретно вас в нем напрягает - сама идея (и связанные с этим издержки) или качество реализации конкретного продукта ?
1 фев 05, 15:33    [1291010]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Считаю, что UML и CASE оправдываются при количестве разработчиков более 10. У нас меньше. Соответственно и работаем по другому. NotePad+SQLPLUS превосходное IDE
1 фев 05, 15:45    [1291065]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Gluk (Kazan)
Считаю, что UML и CASE оправдываются при количестве разработчиков более 10. У нас меньше. Соответственно и работаем по другому. NotePad+SQLPLUS превосходное IDE


Ну у меня на это несколько иной взгляд. Получившие достаточно большое распространение сильно формализованные методики типа RUP действительно оправдываются только на больших проектах с большим количеством разработчиков. Но в целом UML и CASE - это не только формализованный подход и связанные с этим издержки. Полагаю, что при разработке сложных систем, обрабатывающих сложно организованные данные, правильное использование ОО-технологий разработки может принести существенный выигрыш. Т.е. там, где при традиционном подходе нужно 20 разработчиков, переход на чистый OO-инструментарий (его перечень см. выше) может позволить обойтись и 5-ю разработчиками, да еще и сократить срок реализации проекта. Платой за это, однако, могут быть меньшие показатели производительности системы, обусловленные введением дополнитего звена (O/R мэппера) между приложением и реляционной базой данных (переход на ООСУБД в таком случае мог бы помочь, но не всегда возможен).
1 фев 05, 16:00    [1291142]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Согласен в части разработки клиента. И не столько ОО вообще, сколько RAD в частности. UML позволяет найти общий язык большому коллективу разработчиков. Других преимуществ не вижу. Все это есть IMHO, но моя группа полностью придерживается моих взглядов в этой части.
Так что мы обмениваемся непосредственно исходными текстами.
1 фев 05, 16:06    [1291168]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Т.е. там, где при традиционном подходе нужно 20 разработчиков, переход на чистый OO-инструментарий (его перечень см. выше) может позволить обойтись и 5-ю разработчиками, да еще и сократить срок реализации проекта.

Я вам найду таких разработчиков, что будет все наоборот
А потом найду ваще таких, что если выше на чиста-ОО нужно было бы 20, то этих на него же нужно было бы 40, а на чиста-Р хватило бы и одного

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

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

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

Откуда: Москва
Сообщений: 913
Gluk (Kazan)
Согласен в части разработки клиента. И не столько ОО вообще, сколько RAD в частности. UML позволяет найти общий язык большому коллективу разработчиков. Других преимуществ не вижу. Все это есть IMHO, но моя группа полностью придерживается моих взглядов в этой части.
Так что мы обмениваемся непосредственно исходными текстами.


Возможно в таком контексте вы и правы. Но я то хотел подчеркнуть тот факт, что ОО-подход позволяет обойтись одной моделью (построенной с помощь CASE средств в виде UML или просто с помощью Notepad в виде исходных текстов), которая распространяется и на базу и на клиента. Сожаление вызывает только то, что эта методика не универсальна и пригодна только для определенного круга задач - задач, в которых можно производить объектно-ориентированную ОБРАБОТКУ данных. А уже объектное ХРАНЕНИЕ данных - вопрос производный. Теперь, надеюсь, вы понимаете почему выше я обратил ваше внимание на различие этих терминов.
1 фев 05, 17:14    [1291569]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

Я вам найду таких разработчиков, что будет все наоборот
А потом найду ваще таких, что если выше на чиста-ОО нужно было бы 20, то этих на него же нужно было бы 40, а на чиста-Р хватило бы и одного


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

tygra

А если серьезно, то не вижу, где бы ОО в части данных (в части клиентского кода оно уже и так) могло бы так сильно помочь.


В том то и фишка, что можно совместить разработку клиентской и серверной частей (по крайней мере строить их на базе единой объектной модели).

tygra


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


Собственно именно поэтому ООСУБД и продвинутые средства О/R отображения в России до сих пор относительно слабо известны. Труд разработчика у нас пока (до недавнего времени) относительно недорог и можно себе позволить нанять побольше неплохих профессиональных SQL-разработчиков (которые будут вручную тюнить запросы) вместо того, чтобы сокращать издержки и сроки за счет использования разнообразных продвинутых ОО средств разработки, которые достаточно дороги. Ко всему такие средства неизбежно приводят к меньшей производительности приложений на базе традиционных (наиболее распространенных) реляционных хранилищ информации. Интерес возникает тогда, когда зарплата разработчика уходит за 1К$ (а стоимость рабочего места для его размещения - не менее того) и привлечение в проект пары-тройки новых людей сказывается на росте затрат катастрофически. И вот, когда при общей стоимости проекта в десятки, а то и сотни килобаксов риски не уложиться в отведенное время и в отведенный бюджет оказываются значительными, люди и приходят к этой технологии.
1 фев 05, 17:35    [1291682]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Shtock
Member

Откуда: СПб
Сообщений: 3049
Alexey, Вы пишете:
"
Например, вы априори допускаете что у системы вообще есть какое-то «завтра», в котором мы захотим вытащить из нее какую-то информацию. Но какое «завтра», может быть, например, у свежезапущенной ракеты? И какие нерегламентированные запросы могут быть к системе управления ПВО, работающей в реальном времени? В военной технике опережение на миллисекунду может иметь решающее значение и ради этой миллисекунды можно пожертвовать многими вторичными возможностями.
"
Лозунг неспециалиста..
Вся инфа "по свежезапущенной ракете" пишется в БД БИУС (эта штуковина фактически мозг боевой части) и ракета корректируется именно им. Зачем тогда разрабатывать систему на "сегодня", если все равно придется разрабатывать ее "на завтра"?!
1 фев 05, 17:39    [1291702]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Shtock
Alexey, Вы пишете:
"
Например, вы априори допускаете что у системы вообще есть какое-то «завтра», в котором мы захотим вытащить из нее какую-то информацию. Но какое «завтра», может быть, например, у свежезапущенной ракеты? И какие нерегламентированные запросы могут быть к системе управления ПВО, работающей в реальном времени? В военной технике опережение на миллисекунду может иметь решающее значение и ради этой миллисекунды можно пожертвовать многими вторичными возможностями.
"
Лозунг неспециалиста..
Вся инфа "по свежезапущенной ракете" пишется в БД БИУС (эта штуковина фактически мозг боевой части) и ракета корректируется именно им. Зачем тогда разрабатывать систему на "сегодня", если все равно придется разрабатывать ее "на завтра"?!


Я пытался доказать существование в реальной жизни информационных систем, для которых возможно написание достаточно полного регламента возможных запросов. Если вы считаете пример с ракетой некорректным, то я могу еще подумать и привести другие примеры (мне в принципе все равно - я уверен, что в итоге я такие примеры найду). А ваш комментарий мне непонятен - четче выражайте свои мысли и расшифровывайте абревиатуры.
1 фев 05, 18:00    [1291813]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
PArth
Member

Откуда: теткина деревня
Сообщений: 48
Shtock
Лозунг неспециалиста..
Вся инфа "по свежезапущенной ракете" пишется в БД БИУС (эта штуковина фактически мозг боевой части) и ракета корректируется именно им. Зачем тогда разрабатывать систему на "сегодня", если все равно придется разрабатывать ее "на завтра"?!


Бред обкурившегося... Это как баллистичиской ракетой можно управлять извне? Да и нет в БИУС'ах никаких БД.
Сорри за офтопик...
1 фев 05, 20:14    [1292237]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
vadiminfo
Member

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

Т.е. там, где при традиционном подходе нужно 20 разработчиков, переход на чистый OO-инструментарий (его перечень см. выше) может позволить обойтись и 5-ю разработчиками, да еще и сократить срок реализации проекта.

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

Откуда: МО Электросталь
Сообщений: 5994
Alexey Rovdo
[quot Shtock]я уверен, что в итоге я такие примеры найду).

Тогда возникает 2 вопроса:
1. На каких задачах Вы сейчас используете ООСУБД
2. Чем это мотивировано, если Вы считаете, что эти же задачи неплохо решаются на РСУБД (сей вывод исходит из логики, что Вы только собираетесь искать примеры, где ООСУБД будет наиболее выигрышным выбором для поставленного решения)

Я так понимаю, ПО под ракеты и самолеты Вы не делаете. Так что давайте снова вернемся к конкретике, а именно лично к Вашему обоснованию выбора платформы :)
1 фев 05, 23:20    [1292400]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

>Остается один вопрос.
Почему приложение для FastObjects (при использовании ОО-хранилища) в рассмотренном выше будет еще и быстрее, чем приложение для MS SQL Server?
Объяснение этому факту лежит в особенностях обработки join-операций на сервере реляционной СУБД и в особенностях прямой навигации по связям в объектной базе данных.


Все, капец, похоже переходим на уровень аргументации Андрея Леонидовича. Почему модель быстрее? Да из-за особенностей модели. Или другими словами: потому что.

Ха-Ха!
Вот что значит не полениться. Взял да и написал Java-приложение, работающее с базой MS SQL 2000, идентичное тому, что я написал ранее для FastObjects.
..........................
..........................
..........................



Интересный подход, свежий. Чтоб доказать свое преимущество нужно ухудшить код конкурента.

Ответьте на очень важный вопрос: какой части постановки задачи не удовлетворяет решение SergSuper-а? За исключением тех, от которых Вы сами отказались.

Просто процитируйте соотсветсвующую часть постановки, ничего больше.

А если вдруг решение SergSuper-а удовлетворяет постановке (т.е. решает поставленную задачу), то так и скажите.

Следующий вопрос не такой важный. У Вас есть решение SergSuper-а и Ваше. В Вашем Вы на законном основании полный хозяин, делайте что хотите. Почему же Вы предпочитаете переделывать решение SergSuper-а вместо того, чтоб менять Ваше? Вы подгнали чужое решение, которое к тому же появилось гораздо раньше, под свое. Решение SergSuper-а Вам вообще не принадлежит, оно неприкосновенно.

Если на то пошло я могу ухудшить любое решение любой практической задачи до заранее заданной степени, тут много ума не нужно. То, что СКЛ решение после Вашей доработки увеличилось по длине до ОО решения может говорить, например о том, что Вы не знаете СКЛ-я. Но первоначальный тезис о перимуществах ОМД теперь недоказуем. Вы доказали только то, что в ВАШЕМ исполнении реляционная модель хуже объектной.

Следующий вопрос риторический. Я, немного работал с РСУБД, больше 10 лет, в том числе и разрабатывал клиентские приложения. Но НИ РАЗУ за это время не возникла необходимость использовать джаву для получения или складывания данных в БД. Вопрос: зачем же вы ее сюда постоянно суете? Достало уже. Кто вбил в Вам в голову идиотскую мысль (прошу прощения за грубость), что код SergSuper-а висит в воздухе? Я Вам 3 раза повторил, что КОД ПОЛНОСТЬЮ РАБОЧИЙ. Если Вы не понимаете как можно обойтись без джавы это Ваши проблемы. Если джава необходима в фастобджектс - вперед, флаг в руки, принимаются любые решеня Вашей задачи.

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


А пока что четырехкратный выигрыш в длине кода по-прежнему на стороне СКЛ-я.
2 фев 05, 04:44    [1292511]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Злой Хорёк
Member

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

"Я утверждаю, что реляционная модель с нерегламентированными запросами работает лучше (эффективнее, быстрее), чем ОО-модель." - ваши слова? Следовательно ОО приложение работает хуже чем реляционное. Или вы считаете что они одинакого хорошо работают? Если что-то работает хорошо значит что-то работает плохо. Давайте не заниматься тавтологией а рассматривать задачу. По поводу ваших заявление ОО mapping к различным БД -a JDBC позволяет делать то же самое, а уж если использовать JNDI на Application Server то ничего кроме xml-ного файла править не надо. Вы этим примером ничего не показали. Вы упомянули что ОО-подход позволяет обойтись одной моделью. Извините а какую вы модель упоминали? Концептуальную или проектную? Если первую, то как программы писать без второй, а вторая без первой смысла вообще не имеет. Человек не понимающий разницы между моделями не может быть ОО разработчиком. Согласно вашей методике RUP, концептуальная модель отображает понятия реального мира. А проектная - конкретную реализацию концептуальной модели. Кстати ОО метод проектирования не подразумевает использования ОО языка программирования в качестве конечного средства разработки. Он рекомендует использовать потому что перекладывать на ОО языки легче, но и не запрещает делать что-то другое. Ваше заявление о том что данная задача является по сути реляционной это ЧИСТЕЙШЕЙ ВОДЫ ЕРУНДИСТИКА. Такое может заявлять только дилетант. Метод ООП подразумевает декомпозицию системы на объекты, ВНЕ ЗАВИСИМОСТИ ОТ ЭТОЙ СИСТЕМЫ. Почитайте Booch-a хотя бы, а то это сплошной позор. Как вы не поймете, что метод ООП это не создание каких-то классов. Это метод описания сложных систем, а что вы дальше делаете с ним это ваше дело, хоть на асме пишите. А у вас так радостно свалялось все в кучу - сущности, объекты и т.д. Изрядная каша в понимании ОО методик. ОО разработка в несколько раз сложнее чем обычная. Но это хорошо себя окупает, когда нам требуется уложить проект в определенные временые рамки и обеспечить легкость в сопровождении продукта. А люди рассуждающие о легкости ОО подхода это просто вчерашние студенты нахватавшиеся азов ООП. Мое мнение, что вам прежде чем доказывать преимущества ОО подхода следовало бы изучить эту тему поглубже. А то это ныряние в мутной мелкой луже получается. И уж ваше заявление о том что ваша ОО надстройка работает быстрее эта та же песня из области дерзких замыслов разработчика.

2 Gluk (Kazan)

У уже упоминал для Алексея, что для сложных запросов есть шаблон, решающий данную задачу. Я его не буду описывать этот шаблон, просто скажу что он представляет собой отдельный класс, которому мы делегируем нахождение объекта по определенным условиям. Таким образом и овцы сыты и волки целы. Нет никаких преград использования сложных запросов. Правда это проходит только в случае OO-mapping. В случае настоящих ООБД типа GEMSTONE, а не надстроек над реляционной БД, я не могу ответить, что надо делать.
2 фев 05, 06:37    [1292552]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
PArth
Member

Откуда: теткина деревня
Сообщений: 48
2 ASCRUS:
"1. На каких задачах Вы сейчас используете ООСУБД
2. Чем это мотивировано, если Вы считаете, что эти же задачи неплохо решаются на РСУБД "


Лично я задумал переход с Sybase ASA8 на FastObjects после того, как устал от "навороченности" структуры данных. Задачи при этом самые обычные - учет, анализ (документы, бухгалтерия, etc.) Террабайтных объемов нет, по времени ограничений нет...
Претензий к инструменту (Sybase ASA) никаких, есть претензии к "плоскости" реляционных структур. Основной аргумент для перехода на ООБД (для себя самого) - УДОБНО. Аргумент для выбора именно FastObjects - персональные договоренности по цене.
Процесс перехода еще в зачаточном состоянии, так что пока не просите конкретных полноценных примеров. Попозже...

2 Злой Хорёк:
" Извините а какую вы модель упоминали? Концептуальную или проектную? Если первую, то как программы писать без второй, а вторая без первой смысла вообще не имеет. Человек не понимающий разницы между моделями не может быть ОО разработчиком"

Категоричный догматик...
2 фев 05, 10:08    [1292995]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Alexey Rovdo
Gluk (Kazan)
Согласен в части разработки клиента. И не столько ОО вообще, сколько RAD в частности. UML позволяет найти общий язык большому коллективу разработчиков. Других преимуществ не вижу. Все это есть IMHO, но моя группа полностью придерживается моих взглядов в этой части.
Так что мы обмениваемся непосредственно исходными текстами.


Возможно в таком контексте вы и правы. Но я то хотел подчеркнуть тот факт, что ОО-подход позволяет обойтись одной моделью (построенной с помощь CASE средств в виде UML или просто с помощью Notepad в виде исходных текстов), которая распространяется и на базу и на клиента. Сожаление вызывает только то, что эта методика не универсальна и пригодна только для определенного круга задач - задач, в которых можно производить объектно-ориентированную ОБРАБОТКУ данных. А уже объектное ХРАНЕНИЕ данных - вопрос производный. Теперь, надеюсь, вы понимаете почему выше я обратил ваше внимание на различие этих терминов.


Обилие моделей и языков мне совсем не мешает :)
2 фев 05, 10:26    [1293082]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Злой Хорёк
2 Gluk (Kazan)

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


Вполне с этим согласен, но тогда все ляжет на плечи оптимизатора (не обязательно SQL), либо придется по навигационному вручную бегать по всем циклам, обеспечивать изоляцию, блокировки и т.п. Про качество оптимизатора subj мы здесь уже слышали. Прямо скажем, и до Oracle и до MS SQL ему далеко. Так в чем выгода ? Почему я сегодня должен все бросить и использовать ОО в части хранения данных ???
2 фев 05, 10:35    [1293121]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
PArth
есть претензии к "плоскости" реляционных структур.

Вы просто (IMHO) не умеете их готовить :)
2 фев 05, 10:36    [1293128]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

"Я утверждаю, что реляционная модель с нерегламентированными запросами работает лучше (эффективнее, быстрее), чем ОО-модель." - ваши слова? Следовательно ОО приложение работает хуже чем реляционное. Или вы считаете что они одинакого хорошо работают? Если что-то работает хорошо значит что-то работает плохо. Давайте не заниматься тавтологией а рассматривать задачу. По поводу ваших заявление ОО mapping к различным БД -a JDBC позволяет делать то же самое, а уж если использовать JNDI на Application Server то ничего кроме xml-ного файла править не надо. Вы этим примером ничего не показали. Вы упомянули что ОО-подход позволяет обойтись одной моделью. Извините а какую вы модель упоминали? Концептуальную или проектную? Если первую, то как программы писать без второй, а вторая без первой смысла вообще не имеет. Человек не понимающий разницы между моделями не может быть ОО разработчиком. Согласно вашей методике RUP, концептуальная модель отображает понятия реального мира. А проектная - конкретную реализацию концептуальной модели. Кстати ОО метод проектирования не подразумевает использования ОО языка программирования в качестве конечного средства разработки. Он рекомендует использовать потому что перекладывать на ОО языки легче, но и не запрещает делать что-то другое. Ваше заявление о том что данная задача является по сути реляционной это ЧИСТЕЙШЕЙ ВОДЫ ЕРУНДИСТИКА. Такое может заявлять только дилетант. Метод ООП подразумевает декомпозицию системы на объекты, ВНЕ ЗАВИСИМОСТИ ОТ ЭТОЙ СИСТЕМЫ. Почитайте Booch-a хотя бы, а то это сплошной позор. Как вы не поймете, что метод ООП это не создание каких-то классов. Это метод описания сложных систем, а что вы дальше делаете с ним это ваше дело, хоть на асме пишите. А у вас так радостно свалялось все в кучу - сущности, объекты и т.д. Изрядная каша в понимании ОО методик. ОО разработка в несколько раз сложнее чем обычная. Но это хорошо себя окупает, когда нам требуется уложить проект в определенные временые рамки и обеспечить легкость в сопровождении продукта. А люди рассуждающие о легкости ОО подхода это просто вчерашние студенты нахватавшиеся азов ООП. Мое мнение, что вам прежде чем доказывать преимущества ОО подхода следовало бы изучить эту тему поглубже. А то это ныряние в мутной мелкой луже получается. И уж ваше заявление о том что ваша ОО надстройка работает быстрее эта та же песня из области дерзких замыслов разработчика.



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

Ну например:

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

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

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

Не имею ничего против JDBC, но именно плохая стыковка с ОО-подходом и породила средства O/R-мэппинга, которые де-факто вводят дополнительный уровень абстракции между ОО-приложением и JDBC. Почитайте о JDO и вы увидите, что JDO работает поверх JDBC и вполне с ним уживается.

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

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

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

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

Выводы и важные замечания об используемой мною терминологии:
хуже реализует (менее эффективнее) <> нереализует
ОО-подход <> ОО-модель
(ОО-надстройка == средство O/R-отображения) <> ООСУБД
ООСУБД подразумевает, что данные хранятся в ОО-модели (структуре)
РСУБД подразумевает, что данные хранятся в Р-модели (структуре)
С точки зрения ОО-подхода к разработке ИС  ООСУБД == (РСУБД + ОО-надстройка)
полный ОО-подход = ОО-модель предметной области + 
                             ОО-проектная модель + ОО-язык программирования
Сложные системы - системы, с числом хранимых (обрабатываемых ... )
   сущностей или функциональных модулей, превышающих 100-300. (Грубая 
   оценка - системы, приводящие к созданию реляционных структур с числом 
   таблиц, большим 200-400 штук).
2 фев 05, 11:15    [1293306]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

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


Gluk (Kazan)

Вполне с этим согласен, но тогда все ляжет на плечи оптимизатора (не обязательно SQL), либо придется по навигационному вручную бегать по всем циклам, обеспечивать изоляцию, блокировки и т.п. Про качество оптимизатора subj мы здесь уже слышали. Прямо скажем, и до Oracle и до MS SQL ему далеко. Так в чем выгода ? Почему я сегодня должен все бросить и использовать ОО в части хранения данных ???


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

Откуда:
Сообщений: 9365
Кое-какие мои нерегламентированные запросы весьма (при хорошем тюнинге) напрягают Oracle, почему Вы считаете, что аналогичные запросы в subj меньше напрягут его ???
2 фев 05, 11:59    [1293557]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 34   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить