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

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

С точки зрения практики - ерунда.




Alexey Rovdo

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



Неужели Вы всерьез считаете что ваши обоснования по этим вопросам не имеют слабых мест? Ведь все-таки эти доводы все еще избегают приводить, например, в литре. По крайней, мере как основные. И классификация не совсем совпадает с общепринятой про РСУБД и ОРСУБД. И тем более про роль теории для практики, Вы кажется, хватили. Есть, например, люди, которые считают, что и компьютеры - все это извращение, а есть тоько экперементальная физика. Она имперечиская наука, а все компьютеры и теории - это Буржуа и бездельники придумали, чтобы оправдать свою неспособность к эксперементальной физике.
16 мар 05, 12:34    [1390094]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Как быть тогда с тезисом, что нет ничего практичней хорошей теории? Считать этот тезис абсолютно неверным? Практическая польза от теорий не возможна?


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

Alexey Rovdo

Главное, чтобы работало и решало все поставленные задачи качественно и надежно!


vadiminfo

Много требований, которым на первый взгляд теория не повредит.


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

vadiminfo

Разве теория и грамотность не совместны? Профессонализм - это разве не ремесло, которое тем проще, чем более используется теоретических результатов. Ведь теория упрощает или нет? Зачем она вообще нужна? Не для этого?


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

vadiminfo

Alexey Rovdo

Уже давно публично признана и проблема "несоответствия импедансов" (impedance mismatch), проявляющаяся на стыке реляционной БД и ОО-приложения.

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

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


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

vadiminfo

Очень интересная инфа. Я не видел про самую большую нигде. Как определено и кем подтверждено, что самая большая? Какая СУБД? Подробности любые интересны.


Objectivity/DB - ООСУБД, весьма популярная в научных кругах.

http://www.objectivity.com/News/PressReleases/2004/News_PR_040112_SLAC_Winter.shtml

В принципе есть масса потверждений этой информации и в независимых источниках, но нет времени искать (погуглите, если есть сомнения).
16 мар 05, 12:34    [1390095]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

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


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

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





Alexey Rovdo

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



Alexey Rovdo

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


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



Alexey Rovdo

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



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


Alexey Rovdo


http://www.objectivity.com/News/PressReleases/2004/News_PR_040112_SLAC_Winter.shtml



Ссылку посмотю вечером. Но пока мне трудно себе представить, что не найдется ни одной РСУБД со сравнимыми объемами.
16 мар 05, 12:54    [1390205]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Alexey Rovdo

c127>2) Видимо есть серьезные причины избегать версанта. Расскажите о них. Последнее касается того удивительного факта, что Вы пропагандируете Версант, но сами избегаете его использовать.

>Нет таких причин. И я нигде ничего подобного не говорил.


Я и не говорил, что Вы это говорили, разумеется не говорили. Я говорил, что вы избегаете. После многочисленных просьб привести объектное решение Вашей задачи с билетами, реализованное в ООБД, Вы заявили:

Alexey Rovdo, 22 фев 05, 10:34>Что же касается ОО-модели, то я решил рассмотреть преимущества/недостатки ОО-подхода на вполне конкретной задаче (как я и обещал выше, так что ждите), но без использования ООСУБД (на базе общераспространенной РСУБД).
(https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=138641&pg=20)

А ОО решения в ООСУБД так до сих пор и нет. Как это еще можно трактовать, кроме как что Вы изо всех сил избегаете использовать ООБД и родные для них объектные методы?
17 мар 05, 03:26    [1392611]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Вы решили переносить нашу с вами дискуссию о FastObjects во все ветки ? Не надо.

Я вам обещал продемонстрировать решение - я это сделаю. Просто руки никак не дойдут этим заняться. Впрочем, я никуда не спешу, а вам, похоже, очень нетерпится? Ну я, конечно, рад, что сумел вас так заинтриговать. Возможно даже, учитывая мою медлительность, вы сами найдете время и займетесь самообразованием, напишите пример раньше меня и мы вместе обсудим его достоинства и недостатки?
17 мар 05, 10:27    [1393150]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Джентельмены, c127 и другие.

Было учень приятно убедиться, что я полный идиот, прочитав первые 18 страниц темы и ничего не поняв - слишком много отсылок к теориям. Если и остальные 30 страниц такие как первые, то мне уже можно высказать свое мнение:

1. Все теории упомянутые (множеств, систем, и тд) нет смысла упоминать. Они здесь никому не помогут.

2. Не нужны никакие формализации ОО модели - от этого объектным базам ни тепло ни холодно.

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

1. операция создания таблицы - Оракл:

CREATE TABLE Person
(
varchar2(150) name;
)

Типа - операция создания объекта - Versant:

// Пример версанта

А как пишется наследование в Версанте (других базах)?
Как положить с++(java) объект в базу?
Кладутся ли только поля? Как это конфигурить?

2. Привести пример как на языке программирования (Java, C++, C, другие) взаимодейтвовать с этими базами: через ODBC, JDBC, соственные механизмы.
- выборка, вставка, изменение, удаление.

А спор о теориях ничего не даст.
17 мар 05, 11:16    [1393453]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Dimonische

О создании объектов в версанте можно почитать по ссылке в моем предыдущем посте на ранних страницах. Там есть вроде бы рабочий код. Наследование и пр. нам увидеть пока не удалось, но надежда не умирает.

2 Alexey Rovdo

>Вы решили переносить нашу с вами дискуссию о FastObjects во все ветки ? Не надо.

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

>Я вам обещал продемонстрировать решение - я это сделаю.

Да не нужно, это лишено смысла. Лучше продемонстрируйте ОО решение на ООСУБД типа фастобджектс или любой другой. Я уже много раз (раз пять) об этом говорил. Это тоже позволить нам сравнить ООБД и РСУБД.
18 мар 05, 03:54    [1396196]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Я уже много раз пытался вам объяснить один простой факт (я собствено и полагал, что обещанный мною пример поможет мне в этом):

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

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

Ровно ту же ситуацию мы увидим, если посмотрим на Versant Open Access JDO. Только там есть уже даже стандарт (Java Data Objects), который оговаривает все Java-конструкции, применимые в клиентских приложениях для доступа к объектным данным (где бы эти данные на самом деле ни хранились - в Oracle или в VDS). При этом приложения также оказываются ПЕРЕНОСИМЫМИ между разными СУБД без изменения исходных кодов.

Можно сколько угодно критиковать сам JDO и пропагандируемый этим стандартом подход, утверждая что он не позволяет в полной мере использовать возможности РСУБД в целом и их конкретных реализаций в частности. Но сравнивать код, написанный в рамках JDO и низкоуровневый код на native-SQL - это вовсе не то же самое, что сравнивать ООСУБД и РСУБД. Все это имеет отношение только к вопросу применимости ОО и построенных на этом принципе концепций вроде того же JDO. Но тогда и следует назвать ветку соответствующим образом, убрав из нее всякие упоминания о СУБД.
18 мар 05, 16:13    [1398390]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alex.Czech
Guest
Alexey Rovdo
2 c127
ООСУБД и ОО-подход к проектированию и написанию приложений - это не одно и то же. Да, ООСУБД расчитаны именно на ОО-инструменты разработки. Но вот сами ОО-инструменты разработки и методики проектирования вовсе не ориентированы исключительно на ООСУБД. Более того, учитывая сегодняшнюю популярность РСУБД эти инструменты в гораздо большей степени ориентированы на использование именно вместе с РСУБД.


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

О чем вообще трем тогда ?
18 мар 05, 16:19    [1398416]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


Легко? (не понимаю)
Более естественно и правильно - верные, но только эмоциональные оценки.
Более эффективно! (при тех условиях, которые я многократно описывал).

Alex.Czech

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


При аккуратном подходе вобще нет никакой разницы для разработчика (не забывайте - приложения иногда переносятся вообще без изменения кода). Просто 50% функциональности ORM-инструментария предназначены для тонкой настройки схем мэппинга, их отладки и красивой визуализации, а также поддержки различных специфических функций разных СУБД (автоинкрементные поля, специфичная оптимизация и группировка запросов и т.п.). Т.е. при работе исключительно с ООСУБД эти 50% просто оказываются незадействованными.
18 мар 05, 16:44    [1398521]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alex.Czech
Guest
Более эффективно в каких единицах измерения ? Трудоемкость разработки, скорость выполнения кода, более широкий набор функциональных... шаблонов что ли, которые можно использовать не применяя нетривиальных приемов ?
18 мар 05, 22:13    [1399268]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
serg99
Member

Откуда:
Сообщений: 422
vadiminfo
Но Вы правы SERIALZABLE не означает последовательный график транзакций. Есть другой пример у Кайта, который это показывает. Но означает ли SERIALZABLE такой график в SQL92?
Вроде как такой уровень просто исключает: грязное чтение, неповторяемость при чтении и чтение фантомов.
Или у Вас есть инфа, что последовательный график, т.е. как будто транзакции выполнялись последовательно? Я что-то не нашел.


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

В стандарте же качество изоляции определяется отсутствием одного из феноменов
-Dirty Read
-Read Commited
-Repeatable Read
-Phantoms

Однако отсутствие всех этих феноменов (как в режиме Snapshot) автоматически не означает что транзакции являются сериализуемыми. То есть в данном случае Оракл вольно или невольно своим названием serializable вместо snapshot вводит народ в заблуждение.

Скажем в нижнем примере при каждом чтении целочисленного атрибута 1 нужно затем его увеличить на единицу и записать обратно в БД.

Trans1              Start Read1 Write1 Commit
Trans2     Start                                          Read1 Write1 Commit
Интересно что при изоляции Read Commited этот сценарий является сериализуемым, то есть сводится к последовательному выполнению транзакций и после выполнения их обоих значение атрибута увеличивается на 2.

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

Интересно воспринимаются ли подобные эффекты как проблема, или на практике об этом никто не задумывается?
18 мар 05, 22:21    [1399279]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
serg99
Member

Откуда:
Сообщений: 422
Извиняюсь, послал не в тот топик.
18 мар 05, 22:23    [1399280]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

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

Хорошо что ОО-инструменты разработки и методики проектирования вовсе не ориентированы исключительно на ООСУБД. Это означает, что нет в этом плане преимущества у ООСУБД?

И так пока выяснили, что РСУБД лучше оснащена теорией, а с ООП приложений дружит не хуже ООСУБД?

Правда, Вы сказали о какой-то проблеме "несоответствия импедансов" (impedance mismatch), проявляющаяся на стыке реляционной БД и ОО-приложения. Но не прояснили ее. А Ваше утвержденение о гораздо большей ориентированности ООП на РСУБД только увеличила необходимость утосчнения того, в чем состоит проблема impedance mismatch. Ведь тогда для ООСУБД еще болше, раз на нее ООП ориетирована гораздо меньше, чем на ООСУБД? Или что?
18 мар 05, 22:23    [1399281]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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

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


1) скорость выполнения кода (при прямой навигации)
2) скорость и простота разработки (сложные схемы мэппинга при работе с ООСУБД строить не приходится, собственно обычно никакие схемы мэппинга строить не приходится)
19 мар 05, 08:58    [1399458]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Alexey Rovdo

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

Хорошо что ОО-инструменты разработки и методики проектирования вовсе не ориентированы исключительно на ООСУБД. Это означает, что нет в этом плане преимущества у ООСУБД?


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

vadiminfo

И так пока выяснили, что РСУБД лучше оснащена теорией, а с ООП приложений дружит не хуже ООСУБД?


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

vadiminfo

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


Не следует относить мое высказывание "эти инструменты в гораздо большей степени ориентированы на использование именно вместе с РСУБД" к ООП в целом. Оно касается именно существующего ORM-инструментария. И именно в том смысле, что в состав этого инструментария входит масса "примочек", которые при работе с ООСУБД вообще не нужны. А если взглянуть шире и посмотреть на ORM-инструменты разных производителей, то окажется, что практически только Versant, являясь производителем ООСУБД, включает в свои ORM-средства поддержку работы со своими ООСУБД. Все остальные ограничиваются только РСУБД. Так, например, обстоят дела в ORM-инструментах DeveloperExpress, Borland (Bold), Solarmetrics и др. И опять уточняю, это не значит, что изначально построив, например, JDO-приложение на базе реализации Kodo от Solarmetrics вы уже не сможете перевести его на использование с ООСУБД Versant. Можете, поскольку спецификация JDO как раз и позволит вам относительно безболезненно сменить и базу данных и свой ORM-инструментарий.

Теперь чуть детальнее о проблеме impedance mismatch. Суть этой проблеы состоит в том, что типовое ОО-приложение - это классы, наследование, объекты. А реляционная структура БД - таблицы и отношения. При написании приложений постоянно возникает проблема преобразования одного в другое. Как, например, обеспечить хранение объектов, класса-наследника? И как поступать при обращении к объектам класса-родителя (ведь все объекты наследующих классов также относятся и к этому классу)? Как хранить древовидные и сетевые структуры связанных объектов? Как хранить типичные списки и коллекции? Как обеспечить целостность объектной сети при удалении и редактировании отдельных ее компонентов? В простейшем случае даже обычный объект с набором атрибутов простых типов требует определенных преобразований для сохранения (или считывания) в одной строке таблицы (т.е. мы не можем просто написть "insert obj" - нам приходится разбирать объект на части и подставлять значения всех его атрибутов в соответствующую sql-конструкцию). Все еще усложняется, если нам нужно обеспечить транзакционную обработку целой группы объектов или гибко управлять блокировками, накладываемыми на объекты при конкурентном доступе к ним множества пользователей. Программисты, работающие с базами данных, хорошо знают такие конструкции как DataSet, DataTable, Recordset, QueryDataSet и т.п. Мы привыкли называть их объектами и считать работу с ними объектно-ориентированной. Но на самом деле все это своего рода суррогаты, не являющиеся полноценными объектными конструкциями и выполняющие роль конвертов для реляционных данных. Достаточно сравнить обращение к атрибуту объекта вида Obj.attr и Querydataset.getBigdecimal("column_attr").

Из описанного выше может сложится впечатление, что я как-то очень скептически настроен к табличным данным и прочим реляционным конструкциям. Это вовсе не так. Существуют приложения, которые вероятно и нецелесообразно строить на базе классической ОО-парадигмы. В таком случае и несоответствие импедансов может преодолеваться иными способами, а может и вообще отсутствовать. Но все это относится уже к вопросу эффективности и применимости самого ОО-подхода к проектированию и программированию, а здесь мы все-таки сравниваем СУБД.
19 мар 05, 10:12    [1399478]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Alexey Rovdo

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

Я это и без Вас знаю, с точностью до моего интуитивного понимания ОО-ООБД, которое возможно не совпадает с Вашим. Но проблема в том, что мы обсуждаем "Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД.". Ну при чем тут инструменты написания приложений, которыми Вы размахиваете и тут и в https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=138641&pg=20 ? Забудьте об инструментах раз и навсегда. Вам уже раз 20 об этом говорили разные люди. Мы обсуждаем СЕРВЕРА.

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

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

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

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

Что показывает? Ваша цитата из рекламного проспекта? Ничего она не показывает. Я могу сказать, что марсиане прилетели и это "ясно показывает" что жизнь на Марсе есть.

>При этом приложения также оказываются ПЕРЕНОСИМЫМИ между разными СУБД без изменения исходных кодов.

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

Я уже много раз просил Вас не тратить своего и нашего (моего) времени и не цитировать тут агиток для менеджеров. Это не тот уровень.

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

Что, опять будем сравнивать длину кода или как?

То, что Вы лично не знаете как строить реляционные решения и как пользоваться СКЛ-ем не говорит, о том, что для решения прикладных задач язык СКЛ хуже, например, джавы. Вообще-то он очень часть гораздо лучше. И никаких схем мапинга.
22 мар 05, 03:52    [1403972]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Ну и что вы тут понаписали?

Вы доказываете, что чистый ОО подход неприменим при работе с РСУБД поскольку в этом случае

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

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

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

И прекратите выдергивать из контекста мои высказывания. Я уже понял, что язвить и играть словами вы умеете на высоком уровне. Может хватит?
22 мар 05, 11:02    [1404587]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ЛП
Guest
бррр... чего-то наверное у меня с головой плохо.
Alexey Rovdo
Если вы обязательно хотите разместить логику вместе с самими данными, то ООСУБД для этого не подходят.

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

Тут утверждалось, что в ООСУБД хранятся объекты.
А теперь вдруг оказывается, что в ООСУБД не хранятся объекты, и даже что ООСУБД для этого не подходят. Если от объекта откусить логику, то то, что останется - это вовсе даже не объект, а просто-напросто данные к нему.

Так что хранится в ООСУБД? Объекты? Или данные объектов? Ну так ведь и в РСУБД тоже хранятся данные объектов. Хде разница между ООСУБД и РСУБД?
(хороший вопрос для 57-ой страницы)

Только, пожалуйста, не надо съезжать на третий слой и логику на клиенте. В чем разница в серверной части? Только в том, что в ООСУБД данные объектов хранятся таким способом, что некий гипотетический третий слой их сможет без напряга отмапить в client-side объекты? Вернее даже в client-side структуры (в сишной терминологии)?
22 мар 05, 17:25    [1406290]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

Откуда:
Сообщений: 137
ЛП


Если от объекта откусить логику, то то, что останется - это вовсе даже не объект, а просто-напросто данные к нему.



Именно. По хорошему надо хранить только данные, включая иерархические
22 мар 05, 17:29    [1406303]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

Откуда:
Сообщений: 137
В смысле, не "надо хранить" а "хранятся" Код методов вообще не хранится. Только как экзотические случаи можно маппить всякие триггеры на методы объекта. Но это есть изврат
22 мар 05, 17:32    [1406313]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Guest.
Guest
GemStone/S
The world's first commercially-shipped object-oriented database management system; designed to store Smalltalk objects. Had a C interface for a while, and then spawned a variant for storing Java objects. Began shipping in 1987, still available today (see www.gemstone.com/products/s). Was always distinguished from its competition by the fact that it was "active" - in other words, it could store and run object methods "in the server".
22 мар 05, 17:50    [1406397]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
ЛП
Guest
Dimonische
Именно. По хорошему надо хранить только данные, включая иерархические

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

Код методов вообще не хранится. Только как экзотические случаи можно маппить всякие триггеры на методы объекта. Но это есть изврат

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

Так я могу и нотепад назвать ООСУБД.
22 мар 05, 17:51    [1406400]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ЛП
Guest
Guest.
GemStone/S
The world's first commercially-shipped object-oriented database management system; designed to store Smalltalk objects. Had a C interface for a while, and then spawned a variant for storing Java objects. Began shipping in 1987, still available today (see www.gemstone.com/products/s). Was always distinguished from its competition by the fact that it was "active" - in other words, it could store and run object methods "in the server".

Спасибо за цитату, однако не могли бы разъяснить немного.
In the server не значит in the database
Вдруг в этом мудром GemStone опять какой-нибудь плюшевый application-server встроен, которому пофигу где данные хранятся - в ООСУБД, не в ООСУБД, в нотепаде, в экселе...
22 мар 05, 17:55    [1406419]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Недоучка
Guest
2 ЛП: "Так что хранится в ООСУБД? Объекты? Или данные объектов? Ну так ведь и в РСУБД тоже хранятся данные объектов. Хде разница между ООСУБД и РСУБД?
(хороший вопрос для 57-ой страницы)"


Действительно, наконец-то дошли до вопросов с которых надо было начинать...
ИМХО разница только в интерфейсе. И все. Остальное - либо идентично, либо очень похоже.
Ну а насчет хранения (и, самое главное - исполнения) методов на сервере, так это все вопросы реализации той либо иной ООСУБД. Никто ведь не возмущается по поводу РСУБД - "Как, ХП и триггеры работают только на сервере? Безобразие!".
Согласен, было бы очень здорово, написав метод класса каким-либо простым способом указать где он будет исполняться - на клиенте, на сервере, на апп-сервере... А еще лучше, чтоб система "на лету" определяла место исполнения - в зависимости от нагрузки...
Боюсь, что это пока утопия для любой технологии. (Либо страшный сон - когда идеи MS победят повсеместно)
22 мар 05, 18:20    [1406508]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 52 53 54 55 56 [57] 58 59 60 61 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить