Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 55 56 57 58 59 [60] 61 62 63 64 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
Alexey Rovdo

>Т.е. речь шла о сравнении ООСУБД с комбинацией ORM+РСУБД, а вы мне опять тычете свой SQL-код в качестве контраргумента!

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

Еще раз повторяю: на каком основании сделан подобный вывод. Какие есть претензии к постановке вопроса? Лучше ответьте на него.

Так что ни о каком выдергивании фразы из контекста речи нет, смысл Вашей фразы не был изменен.

>Яркий пример той ошибки, которую я раз за разом пытаюсь объяснить. Нужно четко конкретизировать ситуации, которые мы используем при сравнении. Иначе возникает полный бардак и непонимание.

Во как. Смена спорщиками позиций в процессе спора.

1) Конкретизация ситуации начинается с определений, а эту тему мы по Вашей же инициативе закрыли.

2) Кроме того, я как минимум дважды предлагал уточнить условие Вашей задачи, чтоб не было разночтений в сравнении, но получил ответ, что условие сформулировано достаточно четко. Теперь получается что условие, оказывается, ведет к бардаку и непониманию. Напомнить кто автор постановки задачи?

Так что опять говорим неправду.

Где ответы на вопросы о количетстве приложений, созданных на универсальном ОО средстве от Версанта?

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

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

Почему трудно рассматривать ООСУБД в отрыве от приложения?
Именно потому, что манипулировать объектами без описания их классов проблематично. Строго говоря, объект в контексте хранилища данных ООСУБД представляет собой некий набор полей (атрибутов) с данными (ООСУБД поддерживает набор элементарных типов для таких полей). Что это за поля и как они структурированы задано в объявлениях классов (Java, C++, C# ... ). Эти метаданные (описания классов) также хранятся в хранилище данных ООСУБД, но в контексте хранилища - это просто еще одни наборы полей. Связать описания класов с самим объектами в полной мере мы можем только в приложении. И говорить об объектах в смысле Java мы можем только в контексте Java-приложения. А об объектах в смысле C++ - в контексте C++ приложения. В контексте только лишь хранилища данных ООСУБД - это все наборы полей, которые в разных приложениях и структурировать можно по разному. При определенных условиях мы даже можем использовать разные метаданные (описания классов) при обращении к одному и тому же хранилищу. И тогда в контексте разных приложений и сами объекты будут разными (на практике, впрочем, много чаще востребована обратная ситуация - одно хранилище метаданных для множества объектных хранилищ).


Тогда вопорс, а как сервер осуществляет поик, использует индексы, если "Связать описания класов с самим объектами в полной мере мы можем только в приложении"? А поиск по полям? В чем тогда состоят фунции сервера? В обычном понимании сервер данных отвечает за храниение и ОБРАБОТКУ данных. А тут получается только хранение, да и то я слабо представляю, как можно положить что-то куда-то не зная размера. Получается либо чистый файл-сервер, типа фокспро, где за все отвечает клиент, либо Вы не понимаете механизмов работы ООСУБД.
24 мар 05, 04:40    [1410636]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый Alexey_Rovdo !

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

^объект(идентификатор экземпляра,идентификатор характеристики)=значение характеристики

Некоторые разработчики используют другой вариант:

^объект(идентификатор экземпляра)=список характеристик

В этом случае возникает ограничение на количество характеристик объекта (в современной ненормативной лексике - на количество свойств класса).

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

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

P.S. Три (!) года на одном месте, господа ! Неужели действительно во всем виноват шизофреник, демагог, пустозвон, идиот, а теперь еще и урод (!), Андрей Леонидович ? Даже страшно становится от своего, столь мощного, негативного влияния на умы участников дискуссии.
24 мар 05, 09:44    [1410926]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

>Т.е. речь шла о сравнении ООСУБД с комбинацией ORM+РСУБД, а вы мне опять тычете свой SQL-код в качестве контраргумента!

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


Вы хоть понимаете, что вы мне сейчас пытаетесь доказать? Что я отвечая на конкретный вопрос на самом деле отвечал вовсе не на него, и поэтому моя фраза "скорость и простота разработки (сложные схемы мэппинга при работе с ООСУБД строить не приходится, собственно обычно никакие схемы мэппинга строить не приходится)" должна читаться вовсе не в том контексте, котрый предполагал я, когда ее писал? Могу только еще раз повторить, что это справедливо при сравнении ООСУБД с комбинацией ORM+РСУБД, а все остальное - ваши личные домыслы и больше по этому пункту я дискутировать не буду.
24 мар 05, 10:03    [1411003]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Где ответы на вопросы о количетстве приложений, созданных на универсальном ОО средстве от Версанта?


Вы действительно хотите, чтобы я здесь повыкладывал кучу success-stories?
Разумеется, это будут рассказы о внедрении на западе. В России Versant до сих пор практически не используется. Первые клиенты появились не более полугода тому назад (впрочем реальные примеры ситуаций, когда кроссплатформенность и переносимость на разные СУБД оказалась необходимым требованием к приложению уже имеются).

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

Учитывая сказанное, я смотрю, например, на спецификацию JDO именно как на средство, которое позволяет строить такие приложения, перенос которых при необходимости окажется гораздо легче и дешевле. Обращаю также ваше внимание на то, что полнофункциональные средства ORM у Versant появились не так уж давно (VOA JDO - в августе 2004, VOA .NET - в марте 2005), т.е. большинство проектов, в которых используются именно эти продукты, еще находятся на стадии разработки. Чуть раньше появилась технология FastObjects SQL Object Factory, но этот ORM-механизм является частью ООСУБД FastObjects и (в т.ч. и из-за особенностей лицензирования) предназначен скорее для обеспечения интеграции объектных хранилищ FastObjects с унаследованными системами на базе MS SQL, Oracle и DB2, а не для создания переносимых приложений (хотя, как оказалось, он очень удобен именно для этого, поэтому многие наработки FastObjects SQL Object Factory ныне перекочевали в Versant Open Access .NET).
24 мар 05, 10:23    [1411083]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
c127
В обычном понимании сервер данных отвечает за храниение и ОБРАБОТКУ данных. А тут получается только хранение ...


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

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

В VDS операции INSERT и UPDATE поддерживаются. Поэтому и сам сервер ООСУБД должен уметь внятно различать и оперировать объектами (т.е. имеет полное представление о всей внутренней структуре классов хранимых объектов). Здесь роль приложения уже меньше.
24 мар 05, 10:45    [1411169]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Юличка
Member [заблокирован]

Откуда:
Сообщений: 40
Андрей Леонидович
, а теперь еще и урод (!), Андрей Леонидович ?


пхотку давай
24 мар 05, 15:02    [1412468]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Юличка

пхотку давай

Смотрите. Если Вам понравится фотка, то Вам придется еще изучить то, что мало кому нужно - дореляционную (радуйтесь что не доисторическую) объектную СУБД, и все эти устаревшие вещи. И наоборот отказаться от классных вещей - РСУБД и ООСУБД.
24 мар 05, 22:44    [1413753]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alex.Czech
Guest
Похоже, 1С - это тоже ООСУБД. И при этом стоит дешевле и кадры для нее гораздо доступнее у нас в стране. Правда, нету модного слова JDO, это серьезный недостаток
25 мар 05, 01:12    [1413836]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Alexey Rovdo

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

В который раз повторяю, смысл Вашей фразы я не обсуждаю, я пытаюсь получить ответ на заданный вопрос, который Вы не заметили: на чем основано Ваше утверждение о скорости и простоте разработки? Вы же именно это и утверждали, что скорость разработки будет выше. Вот и отвечайте.

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

>Вы действительно хотите, чтобы я здесь повыкладывал кучу success-stories?

Нет, я хочу получить ответы на совершенно конкретные вопросы, которые задаю уже в третий раз:
"Сколько таких "ПЕРЕНОСИМЫХ" приложений Вы лично построили, и которые работали в промышленности? А сколько видели в своей жизни?"

Напоминаю, что речь идет об универсальном средстве разработки от Версанта, о котором Вы тут рассказывали и только о нем. Только не success-stories, а ПОСТРОИЛИ ЛИЧНО и ВИДЕЛИ ЛИЧНО.

Как я понял из сказанного - ответ 0 в обоих случаях.

>а не для создания переносимых приложений (хотя, как оказалось, он очень удобен именно для этого, поэтому многие наработки FastObjects SQL Object Factory ныне перекочевали в Versant Open Access .NET).

Какое отношение миграция на .NET имеет к тому, что приложения окаываются переносимыми? Какое отношение оно имеет к объектно-реляционному отображению, о котором шла речь?

>В VDS операции INSERT и UPDATE поддерживаются. Поэтому и сам сервер ООСУБД должен уметь внятно различать и оперировать объектами (т.е. имеет полное представление о всей внутренней структуре классов хранимых объектов). Здесь роль приложения уже меньше.

Так давайте о VDS и говорить, он хоть какое-то подобие сервера и забудем о фастобджектс. Хотя я уже запутался кто есть кто.
25 мар 05, 02:10    [1413861]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


Задайте внятно вопрос - получите ответ.

c127

Вы в своей жизни не постролили, по крайней мере ни одного ООБД-приложения. Возможно я ошибаюсь, поправьте.


Ошибаетесь.

c127

"Сколько таких "ПЕРЕНОСИМЫХ" приложений Вы лично построили, и которые работали в промышленности? А сколько видели в своей жизни?"


Все приложения, написанные в рамках спецификации JDO, в той или иной мере переносимы вне зависимости от того, входило ли это вобще в планы разработчиков. А вот использование native-SQL - запросов и хранимых процедур уже ограничивает переносимость столь сильно, что говорить об этом не приходится. Крупнейшие производители СУБД всячески пытаются переломить эту ситуацию. Испоьзуется два метода: затормозить развитие ORM-стандартов и сделать собственные реализации ORM-средств, совместимые только со своей СУБД и делающие приложения непереносимыми (например, Oracle TopLink).

Примеры использования JDO можно найти на www.jdocentral.com. Если кому-то интересно, могу сообщить, что разработки на основе VOA JDO ведутся и в России нашими партнерами, и именно переносимость приложений сыграла не малую роль в выборе технологии. На эту тему имеет смысл также почитать здесь.

c127

Так давайте о VDS и говорить, он хоть какое-то подобие сервера и забудем о фастобджектс. Хотя я уже запутался кто есть кто.


Конечно можно говорить о VDS и сравнивать эту ООСУБД, например, с Oracle. Но мне казалось, что вопрос здесь стоит несколько шире. Впроочем я не настаиваю - посмотрим как пойдет дискуссия.
25 мар 05, 12:22    [1414804]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
фф
Guest
автор
На эту тему имеет смысл также почитать здесь.

Такой бред, такой бред... Особенно взятые неизвестно откуда какие-то цифры стоимости и продолжительности разработки.
25 мар 05, 12:55    [1414952]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
BaZa
Guest
фф
автор
На эту тему имеет смысл также почитать здесь.

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


Для особо сообразительных там есть ссылки на источник - www.yphise.fr.
25 мар 05, 15:00    [1415587]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Alexey Rovdo

>Задайте внятно вопрос - получите ответ.

В который раз: на чем основано Ваше утверждение о скорости и простоте разработки?



c127>Есть у меня сильное подозрение, что кроме как рассуждать о схемах мепинга Вы ничего не умеете и ни одного работающего приложения Вы в своей жизни не постролили, по крайней мере ни одного ООБД-приложения. Возможно я ошибаюсь, поправьте.

Alexey Rovdo> Ошибаетесь.


Ну и сколько работающих ООБД приложений (не реляционных) Вы построили? Просото интересно, можно не отвечать.

c127> "Сколько таких "ПЕРЕНОСИМЫХ" приложений Вы лично построили, и которые работали в промышленности? А сколько видели в своей жизни?"

Напоминаю, что речь идет об универсальном средстве разработки от Версанта, о котором Вы тут рассказывали и только о нем. Только не success-stories, а ПОСТРОИЛИ ЛИЧНО и ВИДЕЛИ ЛИЧНО.

Alexey Rovdo> Все приложения, написанные в рамках спецификации JDO, в той или иной мере переносимы вне зависимости от того, входило ли это вобще в планы разработчиков. А вот использование native-SQL - запросов и хранимых процедур уже ограничивает переносимость столь сильно, что говорить об этом не приходится. Крупнейшие производители СУБД всячески пытаются переломить эту ситуацию. Испоьзуется два метода: затормозить развитие ORM-стандартов и сделать собственные реализации ORM-средств, совместимые только со своей СУБД и делающие приложения непереносимыми (например, Oracle TopLink).

Примеры использования JDO можно найти на www.jdocentral.com. Если кому-то интересно, могу сообщить, что разработки на основе VOA JDO ведутся и в России нашими партнерами, и именно переносимость приложений сыграла не малую роль в выборе технологии. На эту тему имеет смысл также почитать здесь.


Ну и где ответ? Сколько все-таки видели и построили лично?

Конечно можно говорить о VDS и сравнивать эту ООСУБД, например, с Oracle.

Да сравнивайте с кем хотите, только это должна быть ООСУБД, а не ексель по завышенной цене.
26 мар 05, 04:20    [1417032]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

>Задайте внятно вопрос - получите ответ.

В который раз: на чем основано Ваше утверждение о скорости и простоте разработки?


Какое конкретно утверждение?
Впрочем, все мои утверждения основаны на моих знаниях и практическом опыте.

c127

Ну и сколько работающих ООБД приложений (не реляционных) Вы построили? Просото интересно, можно не отвечать.
...
Напоминаю, что речь идет об универсальном средстве разработки от Версанта, о котором Вы тут рассказывали и только о нем. Только не success-stories, а ПОСТРОИЛИ ЛИЧНО и ВИДЕЛИ ЛИЧНО.


Видите ли, мерятся с кем-то крутизной и длинной чего-нибудь я не планирую. А ответ на вопрос "сколько" сразу же предполагает и вопрос "каких", на который я отвечать в полном объеме не вправе, поскольку не уполномочен на это своими клиентами (заказчиками).

Только еще раз могу повторить. Примеры использования JDO можно найти на www.jdocentral.com. Разработки на основе VOA JDO ведутся и в России нашими партнерами, и именно переносимость приложений сыграла не малую роль в выборе технологии.

c127

Да сравнивайте с кем хотите, только это должна быть ООСУБД, а не ексель по завышенной цене.


Вам стоит меньше думать о деньгах (и их количестве) - это может отрицательно сказаться на психике (похоже уже сказывается). Рекомендую регулярные выезды на природу (шашлык и все такое :-))) ).

Все-таки не я настрогал здесь пол сотни страниц, поэтому превращать эту ветку в обсуждение технологий Versant я не хочу - для этого логичнее создать новую тему.
26 мар 05, 09:18    [1417089]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo, как всегда, точен в формулировках. Действительно, "Р"СУБД и "ОО"СУБД - классные СУБД. Ведь их изучают по школьным учебникам, по обычному расписанию, в классе. А настоящие СУБД, основанные на теории баз данных, приходится изучать на внеклассных занятиях. А на это далеко не у всех есть время и средства...
Три (!) года на одном месте, господа ! А ведь никаких серьезных "проблем" нет. Отбросить рекламные слоганы "Р"СУБД (якобы основана на какой-то проработанной теории), "ОО"СУБД (якобы "объекты" хранятся в каком-то "естественном" виде), "ОР"СУБД (якобы основана на какой-то проработанной теории, которая, счастливым образом, сгодилась и для хранения "объектов"), и все становится ясным, как божий день.
Но для этого нужно как-то "преодолеть" классное образование...
26 мар 05, 14:10    [1417350]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Alexey Rovdo

>Какое конкретно утверждение?

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

>Впрочем, все мои утверждения основаны на моих знаниях и практическом опыте.

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

>Видите ли, мерятся с кем-то крутизной и длинной чего-нибудь я не планирую.

Так вроде никто и не предлагает. А что, есть проблемы с длиной? Комплексы на пустом месте не рождаются.

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

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

>Только еще раз могу повторить. Примеры использования JDO можно найти на www.jdocentral.com.

Не нужно повторять, ответьте на вопрос.

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

А какая разница, тем более что тема называется "Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД.", т.е. все, что мы обсуждаем соответствует теме.


Не уходите от ответа.
26 мар 05, 22:56    [1417833]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
>А настоящие СУБД, основанные на теории баз данных, приходится изучать на внеклассных занятиях.

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

И почему коллега ЧАЛ выбрал эту тему, а , скажем, не тему "Exel быстрее всех СУБД" для своих попыток переделать название темы в пользу дореляционных каких-то воспоминаний? Это все-таки ближе по духу к ходу мыстлей. С экселем он бы мог потягаться, если не в практической пользе (все-таки екселем пользуются несколько больше, чем дореляционной объектной якобы СУБД), то кто из них ближе к СУБД.
27 мар 05, 01:36    [1417928]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


Могу повторить хоть тысячу раз. При проектировании информационных систем на базе объектно-ориентированного подхода (написании программ на ОО-языках) ООСУБД обладают рядом преимуществ по сравнению с РСУБД. Вот эти преимущества:

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

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

PS: c127 очень любит вспоминать наши длительные и не приведшие ни к какому внятному результату споры в другой ветке. Почему-то ему кажется, что отсутствие результата уже говорит в его пользу. А его упорное желание перевести технические споры в обсуждение моих личных достоинств и недостатков вообще сложно комментировать. Впрочем я готов и перейти на личности и даже (если разумное и плодотворное обсуждение действительно покажет мою неправоту или некомпетентность в каких-то вопросах) признать ошибки и покаяться. Но будьте любезны, c127, в этом случае вам прийдется выступать под собственным именем, а не прятаться за псевдонимами. Похоже, однако, вы не готовы к такому повороту событий, ведь в таком случае вы действительно рискуете именно своей репутацией и "отвечать за базар" прийдется уже не виртуально. Так что рекомендую поумерить свои эмоции и притязания и вернуться к обсуждению технических вопросов, а мои личные достоинства и недостатки оставить в покое.
27 мар 05, 11:58    [1418027]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

1) Высокая скорость выполнения кода (при прямой навигации).

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

Alexey Rovdo

2) В случае РСУБД мы вынуждены использовать средства ORM, которые так или иначе тормозят приложение. Кроме того, сами средства ORM предполагают наличие схем мэппинга, сложность которых увеличивается вместе со сложностью задачи.

Кто вынужден, а кто и нет. Или, по крайней мере, не в курсе что он вынужден.
Зато считается само проектирование в ООМД сложнее. Не удачно спроектированные классы вызывают большие проблемы, чем ошибки структуре РМД. Поэтому сложность задачи в плане проектирования системы тоже пока врядля очивидное преимущества.
Т.е. эти преимущества пока не очевидны ни на форуме, ни в литре.
27 мар 05, 13:56    [1418101]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Кто вынужден, а кто и нет. Или, по крайней мере, не в курсе что он вынужден.
Зато считается само проектирование в ООМД сложнее. Не удачно спроектированные классы вызывают большие проблемы, чем ошибки структуре РМД. Поэтому сложность задачи в плане проектирования системы тоже пока врядля очивидное преимущества.


Я ни в коей мере не оспариваю того факта, что существуют иные (кроме ОО) подходы к проектированию информационных систем. Зачастую такие подходы могут оказаться и лучше, чем ориентация на ОО (быть может). Но я в своих высказываниях касаюсь исключительно той ситуации, когда мы имеем имеем объектно-ориентированное проектирование и объектно-ориентированое программирование приложения на объектно-ориентированных языках (например, Модель предметной области -> UML-модель -> Java-приложение). Так вот именно в такой ситуации мои оценки и следует рассматривать. Нельзя их обобщать и раз за разом спорить с тем о чем я и не говорю. Теперь по существу.

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

1) скорость исполнения програмного кода, реализующего прямую навигацию по межобъектным связям (ака object.subobject.attribute = ...), при применении ООСУБД окажется выше, чем при использовании РСУБД+ORM.
2) использование ООСУБД позволит отказаться от реализации в приложении механизма (уровня) ORM и написания сложных схем мэппинга (что само по себе сокращает объем работ и, соответственно, упрощает и ускоряет разработку приложений).

Еще раз акцентирую. Если есть желание сравнивать ООСУБД с РСУБД вне обязательного требования об использовании ОО-методик на ВСЕХ этапах построения моделей, приложения и его интерфейсов, то об этом нужно явно говорить. А еще лучше - уточнять и то, какие же конкретно методики используются при работе с РСУБД на всех этапах проектирования и разработки приложений. Полагаю, что сам по себе вопрос выбора методологии проектирования не прост и вполне достоин отдельного и вдумчивого анализа.
27 мар 05, 16:20    [1418205]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

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

Да разумеется. Мы можем брать любые отдельные случаи.

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

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


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

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

Т.е. это преимущество нуждается в доп исследованиях. И в литре, если и упоминается что-то про это, то скорее как еще не установленное окончательно.
Да, для приложений где РМД имеет трудности - конструкторских, например, ООСУБД имеет шансы. И я писал, что лет 10 назад оно обогнало в 30 раз на таком приложении. Хотя Оракл там не участвовал - это лично для меня важно.


Alexey Rovdo

Конечно же, если у вас есть ОО-приложение, созданное в описанных выше условиях, а работаете вы с РСУБД, то вы в обязательном порядке в том или ином виде реализуете в своем приложении объектно-реляционное отображение (ORM)!

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

Alexey Rovdo

1) скорость исполнения програмного кода, реализующего прямую навигацию по межобъектным связям (ака object.subobject.attribute = ...), при применении ООСУБД окажется выше, чем при использовании РСУБД+ORM.

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

Alexey Rovdo

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

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

Alexey Rovdo

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

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

Вы же учтите, что основным из достижений РМД является значительная независимость данных от приложений. Ведь в БД данные предназначены для многих приложений. И вообще есть польза от разделения задач - проектирование БД - это одно, а приложений другое. Такое разделение обосновнывается преимуществами в скрости разработки, лучшего управления проектом. Разделение задачи на части и решения этих частей в сумме дает меньше времени на решение, чем без такого разделения. Или недостаточного разделения. И в этой теме сравниваются СУБД, а не ИС в целом. Т.е. по мысли базистов - приложение вторично в некотором смысле. Мало ли приложений? А БД одна, даже если она распределенная.
27 мар 05, 18:37    [1418273]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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


Alexey Rovdo

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

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


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

vadiminfo

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


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

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

vadiminfo

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


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

vadiminfo

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


Нет никаких ООСУБД - надстроек на РСУБД. Если данные хранятся в РСУБД, а приложение манипулирует объектами, то все, что между ними называется ORM. То, что вы называете реляционно-объектным отображением, есть ничто иное как перенос реляционных конструкций из реляционного же хранилища и в само приложение. Ход вполне логичный и активно применяемый именно как средство избавления от уже упоминавшегося мною выше "несоответствия имедансов" (только при этом приложение в общем то перестает быть ОО ). Именно так многие инструменты разработки и устроены (датасеты, дататаблы и прочие суррогатные, т.е. необъектные, конструкции). И логика работы в такой парадигме именно вынуждает разработчика "плясать" от структуры БД. К примеру, популярна следующая схема работы: Модель предметной области -> E/R-модель -> схема БД -> Приложение. Такой подход вполне себя зарекомендовал и оправдан на простых приложениях. Но по мере усложнения задач и логики приложений начинают проявляться и его недостатки, а переход на иной порядок (Модель предметной области -> UML-модель -> Приложение -> Схема БД) кажется вполне оправданным.

vadiminfo

Alexey Rovdo

1) скорость исполнения програмного кода, реализующего прямую навигацию по межобъектным связям (ака object.subobject.attribute = ...), при применении ООСУБД окажется выше, чем при использовании РСУБД+ORM.

Это скорей проблемы, если они и есть, сравнеия ООСУБД - надстройка над РСУБД и ООСУБД без надстройки.


Это проблемы, сравнения ORM-надстройки над РСУБД и ООСУБД без надстройки.

vadiminfo

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


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

vadiminfo

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


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

vadiminfo

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


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

vadiminfo

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


Тут надо принять во внимание, что использование РСУБД+ORM или ООСУБД позволяет во многом вообще исключить этап разработки структуры БД, а не включить его в состав каких-то других частей проекта. Структура БД целиком определяется (или совпадает) объектной структурой приложения.
27 мар 05, 21:51    [1418378]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Lirik_SPB
Guest
vadiminfo
Вы же учтите, что основным из достижений РМД является значительная независимость данных от приложений. Ведь в БД данные предназначены для многих приложений. И вообще есть польза от разделения задач - проектирование БД - это одно, а приложений другое. Такое разделение обосновнывается преимуществами в скрости разработки, лучшего управления проектом. Разделение задачи на части и решения этих частей в сумме дает меньше времени на решение, чем без такого разделения. Или недостаточного разделения. И в этой теме сравниваются СУБД, а не ИС в целом. Т.е. по мысли базистов - приложение вторично в некотором смысле. Мало ли приложений? А БД одна, даже если она распределенная.


В объектных базах также возможно разделение проектирования БД и приложения. С точки зрения программы данные "часть программы". Но для базы данных существуют лишь хранимые объкеты и классы. Вы можете создать модель данных на диалекте языка программирования и, оформив это как библиотеку, использовать ее для разных приложений, которые работают с одной базой данных. Как вариант есть reverse-engineering - т.е. по существующей базе данных (объектной или реляционной) можно создать описание классов на объектном языке программирования.
27 мар 05, 21:58    [1418381]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

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

Первые предпочитают смотреть на БД, как на ядро информационной системы.
В БД могут быть интегрированы данные, например, всего предприятия. Данные храниятся вместе с информационной моделью - т.е. они, как Вы выразились самодостаточны. Т.е. в БД все есть, чтобы получить информацию, необходимую для принятия решения. Эта модель обеспечивает наиобльший уровень абстракции. Приложения, могут обеспечивать представления данных для разных пользователей. Они обеспечивают меньший уровень абстракции.
Это связано с пользой от независимости данных от приложений. Это польза осознана была достаточно давно и выражена, например, в трехуровневой архитектуре ANSI-SPARCS 1975. Сам термин БД относится примерно к 1960 году. И по началу идей о независимомти данных от приложений не было. Вся модель была в приложениях, и данные без этих приложений представляли из себя просто бесполезный набор байт заполненных нулями и единицами.
Этот опыт привел к печальным последствиям. С ним даже связано, по-моему, понятие дипрессии программного обеспечения. Которое выразилось в разочаровании от внедрения первых ИС.
Поэтому первые вынуждены (а не просто предпочитают) так смотреть. Причем, я подозреваю, что эти первые есть и среди представителей ООСУБД. Поскольку это характерный подход в приложениях с БД.

Alexey Rovdo

Но такие приложения не являются полноценными ОО-программами и не манипулируют объектами как таковыми

Для того, чтобы быть ОО-приложениями достаточно реализовывать ОО - парадигму программирования. Любая прога на JAVA - будет ОО - прложением, поскольку JAVA не поддерживает не поддерживает никаких других парадигм.

Alexey Rovdo

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

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

Alexey Rovdo

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

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

Alexey Rovdo

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

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



Alexey Rovdo

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

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

Alexey Rovdo

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

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

Alexey Rovdo

(Модель предметной области -> UML-модель -> Приложение -> Схема БД) кажется вполне оправданным.

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

Alexey Rovdo

Во-первых, уверенны ли вы, что ваши приложения действительно корректно называть объектно-ориентированными?

Уверен в том смысле, в котором писал выше - соблюдены принципы ООП.

Alexey Rovdo

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

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

Alexey Rovdo

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

Нет вопросов. Пусть это будет ORM. Тока надо перепроверить. А то брякну где понапрасну.

Alexey Rovdo

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

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

Alexey Rovdo

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

Ну тут Вы расходитесь с общепринятыми какими-то представлениями. Я про пользу независимости данных.
И эта польза не только на стадии проектирования, но на всем жизненном цикле ИС. И, в частности, данные могут продолжать свой жизненный цикл, после того, как ИС и все ее приложения сняты с экплуатации. Например, в хранилище данных.
Что касается совмещения при проетировании, то это противоречит идее декомпозиции задачи на несколько задач для выигрыша по времени. А для скорости, кроме всего прочего можно частично параллельно решать эти задачи.

Alexey Rovdo

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

Однако, кажется, что на самом деле проектирование БД происходило одновременно с приложением. Но лучше - это проетирование в ООСУБД, в случае если она есть надстройка над РСУБД. Т.е. Ваше РСУБД+ORM очень походит на такую СУБД. Потому что здесь на лицо проектирование ООМД, а ее место в БД. И обеспечивает это моделирование СУБД. Следовательно это ООСУБД. А раз там фигурирует РСУБД, значит эта ООСУБД надстройка над РСУБД.
Я тогда покину Вам еще аргументы. При таком маппировании происходит потеря и семантичности модели, и вообще насколько она хорошо ложится на реляционные структуры в общем случае тоже не ясно.
Идея же автоматического проектирования РМД маппированием ООМД тоже вызывает опасения. Не всегда просто найти наиболее оптимальную схему РМД. Эта задача, не всегда поддается алгоритмическому решению. Т.е. в общем случае - задача искусственного интеллекта. Говорят, в частности, об искусстве проектировщика. Какое уж тут автоматическое проектирование (отсутствие такового)?
28 мар 05, 03:10    [1418533]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Alexey Rovdo

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

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

Это основная причина, по которой так интересно все-таки услышать ответы на вопросы, задаваемые по-моему в четвертый раз: "Сколько таких "ПЕРЕНОСИМЫХ" приложений Вы лично построили, и которые работали в промышленности? А сколько видели в своей жизни?"

Еще раз повторяю, от этого зависит уровень доверия к Вашим утверждениям относительно продуктов версанта и пр., которые проверить затруднительно.


>1) скорость исполнения програмного кода, реализующего прямую навигацию по межобъектным связям (ака object.subobject.attribute = ...), при применении ООСУБД окажется выше, чем при использовании РСУБД+ORM.

Это совсем не очевидно, мы обсуждали этот вопрос и очевидного результата не получили. Я уже гворил, что это точка в "object.subobject.attribute" только на вид простая, в случае сложных структур данных за ней могут скрываться сложные алгоритмы. А в случае простых данных я и в реляционной структуре обойдусь данными в той же записи. План запроса Вы привести не смогли и также не смогли рассказать как в ООБД фастобджектс происходит разадресация. Но "Почему-то ему кажется, что отсутствие результата уже говорит в его пользу". ((С) Alexey Rovdo)

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

Я уже говорил, что В ПОЛЬЗОВАТЕЛЬСКОМ ПРИЛОЖЕНИИ И В ООБД ОБЪЕКТЫ РАЗНЫЕ. В приложении это объекты пользователького интерфейса, в конечном счете все к ним сводится, а в БД это объекты бизнес логики. В ГУИ это экранные формы, а в БД это, например, накладные, товары, скидки, проплаты и пр. Поэтому отображение строить нужно будет всегда, и еще неизвестно что легче объекты отобразить в структуру реляционных данных или же одни объекты отобразить в другие.


Так что Ваши рассуждения - очередная спекуляция, построенная на том малозначащем на самом деле факте, что сущности в ГУИ и в ООБД называются одинаково - объекты. Но из этого факта не следуют те выводы, которые Вы делаете.
28 мар 05, 07:08    [1418562]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 55 56 57 58 59 [60] 61 62 63 64 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить