Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 [8]      все
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Павел Воронцов
О, как же я хочу услышать ответ на этот вопрос! Я тоже хочу узнать

"А где бы посмотреть формализацию так называемой ОМД, ... или какая там альтернатива РМД осуждается?"

Дайте мне информацию!


Уважаемые господа с127 и Андрей Леонидович! Надоело читать вашу перебранку и обсуждение генеалогии друг друга. Всем же остальным хотелось бы напомнить тему данного топика:
"А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий".
Даже по названию темы можно понять, что в вопросе идентификации ОМД нет каких-то общепризнанных стандартов. По крайней мере я придерживаюсь такой точки зрения. А ехидные вопросы типа "где бы посмотреть формализацию так называемой ..." имеют очень простой ответ. Любой производитель СУБД, который относит свою систему к объектной или объектно-реляционной понимает под термином "объектная" что-то вполне определенное, так что каждый может почитать документацию на Oracle, Sybase, Versant, Postgress, ... и узнать о том как понимают объектную ориентацию СУБД разработчики конкретной системы. Те же, кто это сделает, могут увидеть, что понимают то они это по разному. Поэтому и нет ничего удивительного в том. что здесь высказываются различные точки зрения на данный вопрос, и нет ничего удивительного в том, что такие монстры как Oracle, IBM и Sybase пытаются продвинуть свое видение этого вопроса (каждый в свою пользу).
Но было бы любопытно отделить зерна от плевел и понять то, какие же критерии являются наиболее универсальными и подходящими для идентификации любой отдельно рассматриваемой СУБД (отнесения этой системы к объектной).
27 дек 04, 10:47    [1210852]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Константин Лисянский
А если не секрет, зачем Вы этот вопрос задали? Пытаетесь что-то понять, или чему-то нас научить?

С уважением,
Константин Лисянский
http://lissianski.narod.ru


Возможно, я пытаюсь чему-то научиться у вас?
Ко всему прочему у меня есть и другая цель - мне хотелось бы понять именно то, что людям приходит в голову в первую очередь, когда они слышат термин "объектная СУБД" (и то, насколько это соответствует реальному в моем понимании положению вещей).
27 дек 04, 10:52    [1210873]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
lazy fox
Guest
Alexey Rovdo
что людям приходит в голову в первую очередь, когда они слышат термин "объектная СУБД"


Ну мне приходяд менеджеры... параноики... жопа... Извините, я всегда о ней думаю
27 дек 04, 11:06    [1210934]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2409
Блог
Alexey Rovdo
Уважаемые господа с127 и Андрей Леонидович! Надоело читать вашу перебранку и обсуждение генеалогии друг друга. Всем же остальным хотелось бы напомнить тему данного топика:
"А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий".
Даже по названию темы можно понять, что в вопросе идентификации ОМД нет каких-то общепризнанных стандартов. По крайней мере я придерживаюсь такой точки зрения. А ехидные вопросы типа "где бы посмотреть формализацию так называемой ..." имеют очень простой ответ. Любой производитель СУБД, который относит свою систему к объектной или объектно-реляционной понимает под термином "объектная" что-то вполне определенное, так что каждый может почитать документацию на Oracle, Sybase, Versant, Postgress, ... и узнать о том как понимают объектную ориентацию СУБД разработчики конкретной системы. Те же, кто это сделает, могут увидеть, что понимают то они это по разному. Поэтому и нет ничего удивительного в том. что здесь высказываются различные точки зрения на данный вопрос, и нет ничего удивительного в том, что такие монстры как Oracle, IBM и Sybase пытаются продвинуть свое видение этого вопроса (каждый в свою пользу).
Но было бы любопытно отделить зерна от плевел и понять то, какие же критерии являются наиболее универсальными и подходящими для идентификации любой отдельно рассматриваемой СУБД (отнесения этой системы к объектной).
Вот потому и хочется знать точно - а что же оно такое, это самое О в аббривеатурах ООП, ОСУБД, ОДМ? Чтобы идентифицировать нечто как подходящее под некий класс, хорошо бы иметь формальное описание. Можно конечно пойти и тем путём, который Вы тут обозначили, но тогда не надо говорить о "провале РМД" как это любит делать Андрей Леонидович. Равное надо сравнивать с равным. Модель данных (реляционную) с моделью данных (где она?) Теорию (реляционную) - с теорией. А есть только практика. И предлагается попытаться вычленить теорию из рекламных заявлений разных производителей. Спасибо, не хочу.

ЗЫ. Только не сочтите за личный наезд - у нас тут с Андреем Леонидовичем собственные религиозные войны, вы просто под руку подвернулись. Извините если что не так. Удачи в поисках "наиболее универсальных и подходящих для идентификации" критериев.
27 дек 04, 12:07    [1211231]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
vadiminfo
Member

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

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


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

Alexey Rovdo

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


Это как раз то и не совсем очевидно. Поскольку объектов то много в БД. И потому в этом плане, возможно, зависит не только от модели данных. Модель в принципе этим не "занимается" - это все-таки больше физический аспект, хотя, конечно, влияние есть.

Alexey Rovdo

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

Что касается оценки ситуаций на практике, то тут нужно приводить ссылки на тех, кто проводил подобные исследования. Ведь речь идет о проектах. Но, известно, что только Оракл, DB2 и MS SQL более 86% всех инсталляций СУБД. Еще море других РСУБД. Оправданность перехода на ООСУБД с РСУБД определяется не только легкостью перехода, но и целесообразностью его. Поскольку существую типы приложений - бизнес приложения, где до сих пор РСУБД успешней ООСУБД. Не забывайте, что у РМД есть кое-что очень ценное, чего у других нет: теор. Мат. обоснование, простота в проектировании для этих типов, высокая независимость данных от приложений и т.д.

Alexey Rovdo

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

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

Alexey Rovdo

Что касается перспективы ОРМД, то про нее мне говорить сложнее.

Согласен.

Alexey Rovdo


Тем не менее мне кажется, что эти системы гораздо более уязвимы, чем РМД и ОМД. И именно потому, что пытаются сидеть на двух (а то и трех) стульях сразу.

Но можно сказать, что они пытаются использовать преимущества и РМД и ООМД. Почему Вы пишите ОМД? Ведь в ОМД входит и ERR, например, а не только ООМД. А ERR точно ничего и не хочет знать ни о какой производительности – она инфологическая (потому абстрагируется от компов).

Alexey Rovdo

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

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

Alexey Rovdo


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

На счет методик не знаю, а вот насчет моделей данных и их реализаций в СУБД – есть три типа СУБД. Логически или нет, но претендуют на использование при создании разных типов приложений. Две из них ООСУБД и ОРСУБД – претендуют на то, чтобы прийти на смену реляционным. Первая радикально отказывается от РМД, вторая пытается его развивать. Первая выкидывает много ценного, что есть в РМД и потому, судя по Вашим словам, делает шаги в сторону РМД. (Вы писали про возможность SQL в них). Так или иначе, скорее всего, будущее не так очевидно как Вы пишете. Более того, если Вы признаете, что есть типы приложений, где вытеснить РМД будет сложно (а это основной тип приложений – бизнес приложения), то у ООМД нет возможности захватить весь рынок. А это существенная проблема в ее будущем, поскольку для БД имеет значение интеграция данных и все такое.
27 дек 04, 13:03    [1211472]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Андрей Леонидович
Guest
Уважаемый Alex.Czech !

Не просто "выглядят естественнее", а прослойки НЕТ.

По поводу "ужасности" языка было написано уже много с обеих сторон. И я тоже ничего нового сказать не смогу. Кроме того, что я увидел первый раз MUMPS и SQL практически ОДНОВРЕМЕННО (!). И после всестороннего анализа, многие аспекты которого я уже приводил, выбрал, все-таки, MUMPS.
Кстати, когда я показываю "мампсистам" (конечно, уже "привыкшим") настоящие запросы на SQL (на MUMPS одна конструкция, которую Вы уже видели, и сложнее уже ничего не может быть), то "абракадабра" - это наиболее ласковое определение.

Раз обещал: эксперимент.
Количество экземпляров объекта "Проводка" = 1'074'659
Дата первой проводки = 01.01.1996
Дата последней = 16.11.2001
Средний результат по 10 опытам: время "нашего" "запроса" в случае перебора экземпляров непосредственно в объекте "Проводка" составило 89% от времени выполнения приведенного текста "запроса" с перебором проводок через индекс по характеристике "Дата" (когда заданный диапазон дат охватывает все проводки).
27 дек 04, 20:09    [1213192]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Андрей Леонидович
Guest
Уважаемый Alexey Rovdo !

Я достаточно подробно ответил на вопрос в заголовке темы. Если нужно что-то уточнить, с удовольствием уточню.
27 дек 04, 20:11    [1213194]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Андрей Леонидович
Guest
Уважаемый с127 !

Автор темы попросил нас прекратить "перебранку" (хотя я, вроде, не бранился), и я его слушаюсь. Откройте, пожалуйста, для перебранки со мной специальный раздел, раз "Сравнение СУБД" Вас не интересует.
27 дек 04, 20:16    [1213200]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alex.Czech
Guest
Андрей Леонидович
Уважаемый Alex.Czech !

Не просто "выглядят естественнее", а прослойки НЕТ.

По поводу "ужасности" языка было написано уже много с обеих сторон. И я тоже ничего нового сказать не смогу. Кроме того, что я увидел первый раз MUMPS и SQL практически ОДНОВРЕМЕННО (!). И после всестороннего анализа, многие аспекты которого я уже приводил, выбрал, все-таки, MUMPS.
Кстати, когда я показываю "мампсистам" (конечно, уже "привыкшим") настоящие запросы на SQL (на MUMPS одна конструкция, которую Вы уже видели, и сложнее уже ничего не может быть), то "абракадабра" - это наиболее ласковое определение.


"Прослойки НЕТ" меня не устраивает по ряду причин... у меня все равно прослойка ЕСТЬ :)

Про MUMPS и его "ужасность" спорить, конечно, глупо... это просто мое субъективное мнение против вашего. Разве что опрос провести какой-нибудь :)
28 дек 04, 10:16    [1213794]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alexey Rovdo
Member

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



Alexey Rovdo

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

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

Alexey Rovdo


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

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


1. Война миров

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

Вся эта борьба нашла непосредственное отражение и в популярной литературе. Самый яркий пример я уже приводил здесь - это книга Дейта и Дарвина, которая стала своего рода символом эпохи и подвела определенную черту под проигранным объектными системами сражением. [https://www.sql.ru/forum/actualthread.aspx?tid=146505&pg=-1#1191875]Выше[/url] вы привели в пример другое авторитетное издание - "Database Systems: The Complete Book". Давайте теперь посмотрим на то, когда была написана эта книга. Итак опубликована она 10.02.2001. Но ей предшествовали две книги этих же авторов: "A First Course in Database Systems" (опубликована где-то в 1997г.) "Database System Implementation" (опубликованна 6.11.99), которые и стали для нее основой (
подробнее). А если копнуть глубже и пойти на страницу авторов, то оказывается, что книги писались на базе курсов, читавшихся в Стэнфордском университете в 1995-1996гг. Что тут можно сказать? Книга то хорошая и правильно отражает всю ситуацию на тот момент и именно в том ключе, который я представил выше. Но мы уже живем в 2004 (скоро 2005) году, а "динозавры" (ООСУБД) все-таки не вымерли. Почему?

2. Новый взгляд

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

3. Позиция производителей

Все сказанное выше - лишь лирические замечания, если рассматривать их вне контекста развития рынка. Поэтому важнейшее значение имеет позиция производителей разных систем. Тут особого разнообразия не наблюдается. Все крупнейшие игроки заявляют (всячески продвигают идею), что их системы пригодны и удобны для всех случаев жизни, а системы конкурентов - отстой и скоро вымрут. Что Oracle, что Microsof, что Versant - все хотят отхватить кусок побольше. Но это не удивляет и является совершенно нормальным. Удивляет поведение тех людей, которые освоив одну из популярных систем, предпочитают закрывать глаза на достоинства других. Причем делают это с удивительным упорством, граничащим с некомпетентностью.

4. Резюме

Возможно, апологеты Oracle или DB2 сочтут все сказанное мною пустыми нападками на их любимые системы. Кому-то покажется, что я агитирую за переход на ООСУБД. Но моя позиция довольно банальна - быть прагматичным, помнить о наличии левой руки и "включать голову" прежде чем "трясти".
28 дек 04, 11:40    [1214193]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
vadiminfo
Member

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

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

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

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

Четверты пп Резюме.
Ну, есть такое - кажется что Вы заинтересованы в успехе ООСУБД, а не над их схваткой с ОРСУБД или РСУБД. Аполагеты Оракла или DB2 тоже могут придерживаться аналогичной позиции про левую руку, голову и т.д. Но все-таки это пока еще не совсем резюме.
28 дек 04, 13:01    [1214607]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alexey Rovdo
Member

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

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

1. В качестве базового описания ОМД и работы с объектными хранилищами данных вполне подходят стандарты ODMG 3.0 и JDO. К сожалению в свободном доступе я ODMG 3.0 не видел. Но вполне содержательная выдержка есть здесь.

2. Перспективы существования самих объектных СУБД в обозримом временном промежутке мне не кажутся очень уж туманными. Надо понимать, что сам по себе метод хранения данных волнует не многих. А вот способ и трудоемкость разработки информационных систем - есть вопрос большой важности. Во многом всплеск интереса к ООСУБД в последние годы обусловлен развитием Java, XML и сервисно-ориентированной архитектуры. Оказалось, что методики разработки, всегда сопутствовавшие ООСУБД, очень хорошо подходят для создания информационных систем в указанной парадигме. Поэтому в ближайшие годы ООСУБД обеспечен подъем (по крайней мере до тех пор, пока в состав традиционных систем от Microsoft, Oracle и IBM не будут встроены столь же удобные механизмы, облегчающие разработку). В частности, обладая информацией о продуктах Versant, могу смело утверждать, что не вижу никаких причин для их ухода с рынка в ближайшие 5-10 лет. Если компания пережила 15 лет борьбы и сумела набрать столько серьезных клиентов, то вряд ли возможен ее быстрый уход (хотя бы потому, что количество существующих инсталляций достаточно велико и пользователи не заинтересованы в срочном переходе на другие решения).

3. Если бы я был совершенно беспристрастен, то мне бы не стоило упоминать о преимуществах каких-то конкретных систем (Versant). Но я пристрастен. Но пристрастен я и потому, что вижу - там, где применение ООСУБД Versant Developer Suite будет более эффективным и рациональным, используют Oracle или DB2. А MS SQL я вижу там, где логичнее поставить Versant FastObjects. А вот примеры обратного мне в России не известны (хотя в мировой практике они наверняка присутствуют). Представьте себе, что вы пришли в кинотеатр, а ваше место занято - вполне логично, что вы будете кричать и добиваться его освобождения (и осуждать вас за это я не стану). Так и объектные СУБД. Обладая хоть и небольшим, но вполне заметным кусочком мирового рынка, они совершенно незаслуженно игнорируются в России - а зря - за это приходится расплачиваться (например, покупая западные информационные системы вместо систем собственной разработки, чье развитие зашло в тупик не в последнюю очередь из-за неверного выбора платформы).

Здесь я уже достаточно удалился от темы классификации ООСУБД, поэтому хотел бы вернуться в это русло и спросить у тех, кто с этим знаком. Было бы интересно поподробнее рассмотреть объектные функции, имеющиеся в Oracle и/или DB2 с тем, чтобы понять их основные отличия от чистых ООСУБД именно по этим параметрам.
28 дек 04, 15:40    [1215469]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Ну вот опять началась продажа.... Алексей я сам работаю в компании в названии которой три буквы и восемь полосок. Но стараюсь всетаки больше говорить на технические темы, а не о продаже. Ибо если мы начнем о продаже надо бутет открывать еще один топик. А оно надо??? Не надо за комунизм агитировать и говорить что ОО это лучше всего и это крутая альтернатива... Большинство бизнес задач можно и без ОО решить. Объектные возможности не есть _самоцель_. Они нужны одним для быстрее разработать, другим заработать. (что не факт)

По поводу рассмотреть вопрос, а зачем. Давай ты посмотришь на OO расширения DB2/Informix/Oracle (в алфавитном порядке) и расскажешь нам... :)
Ломать копья и говорить что моя религия лучше чем твоя это абсурд... Тебе хочется поддержать этот топик живым (ты его начал) Ты и действуй.

P.S. Вышесказанное моя личная точка зрения.
28 дек 04, 15:57    [1215578]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
vadiminfo
Member

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

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

Какие факторы Вы имеете ввиду? Ведь об этом тема. Мне интересно Ваше мнение на этот счет.

Alexey Rovdo

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

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

Alexey Rovdo

Во многом всплеск интереса к ООСУБД в последние годы обусловлен развитием Java, XML и сервисно-ориентированной архитектуры. Оказалось, что методики разработки, всегда сопутствовавшие ООСУБД, очень хорошо подходят для создания информационных систем в указанной парадигме.

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



Alexey Rovdo

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

Как Вы это видите? Ведь это требует какого-то сложноватого анализа - выбор СУБД для проекта. Все-таки выбор ООМД в серьезном проекте на сегодняшний день выглядит как большой риск.

Alexey Rovdo

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

Все-таки Ваши сравнения сбивают меня с толку. Представьте, что не известно чье это место, и номеров у мест нет. Вместо "Так и объектные СУБД" можно сказать "Так и любое СУБД".

Alexey Rovdo

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

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




Alexey Rovdo

я уже достаточно удалился от темы классификации ООСУБД, поэтому хотел бы вернуться в это русло и спросить у тех, кто с этим знаком. Было бы интересно поподробнее рассмотреть объектные функции, имеющиеся в Oracle и/или DB2 с тем, чтобы понять их основные отличия от чистых ООСУБД именно по этим параметрам.

Классификации ООСУБД? Какие там есть классы? К какому классу относится Версант? Она построена на существующем каком-то ОО языке программирования? Каком? Вот я вычитал, что этот язык она не расширяет, а использует дополнительные библиотеки классов, поддерживающие перманентность, агрегирование, объектные типы данных, транзакции и т.д. А Вы слышали что-нибудь про SIM, которая пошла по пути создания совершенно нового языка баз данных и СУБД, обладающее ОО возможностями? Там используется собственная семантическая модель данных. Что Вы про это думаете?
28 дек 04, 22:00    [1216594]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
vadiminfo
Какие факторы Вы имеете ввиду? Ведь об этом тема. Мне интересно Ваше мнение на этот счет.

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

Сфер, где объектные СУБД имеют значительные преимущества, относительно не много и этот кусок рынка большой тройке просто не интересен (он мал).

Судьба объектных систем через 10-15 лет действительно не ясна, в то время как в будущем систем реляционных можно не сомневаться по крайней мере лет 30. Например, IBM уже имеет опыт одновременного развития двух ветвей - иерархической (IMS) и реляционной (DB2). Вероятно издержки довольно высоки и прежде, чем кидаться в омут приходится просчитывать очень многое.

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

vadiminfo

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


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

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

vadiminfo

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


Ну полного счастья не было и не будет никогда - сие, знаете ли, закон природы. :)

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

vadiminfo

Как Вы это видите? Ведь это требует какого-то сложноватого анализа - выбор СУБД для проекта. Все-таки выбор ООМД в серьезном проекте на сегодняшний день выглядит как большой риск.


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

vadiminfo

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


Так вот мне самому интересно, в чем Versant отличается от объетных возможностей других СУБД и где тот водораздел, который позволяет отнести одни системы к объектным, а другие к объектно-реляционным. Вот, например, про Cache очень любят писать, что она объектная. Но мне то кажется, что это не так. Я также много узнал о том, что в Oracle и DB2 тоже есть функционал для работы с объектами, но какой? Я с объектной функциональностью этих систем не работал и мое мнение сформировано на базе обзоров и статей на эту тему. Судя по общению в этом форуме, многие знают о наличии каких-то объектных расширений в названных системах, но судя по всему никто с ними реально не работает. А вывод я могу сделать из этого такой - все это еще находится в рудиментарном состоянии и работать с этим неудобно, зато есть чисто объектные системы, в которых инструментарий вылизывался десятки лет и которые строятся на базе стандартов.
И здесь я могу ответить и на ваш вопрос по поводу SIM. Я не знаю, что такое SIM, но мугу высказать свое мнение по поводу специальных языков - очень тяжелое направление. Причем языки могут быть очень хороши о подходы великолепны, но как только разработчик видит, что ему прийдется изучать какой-то новый язык - он отворачивается и забывает о существовании этой системы. А чтобы он этого не делал ему нужен пряник неимоверной величины. Возможно, языки разрабатываемые сегодня смогут завоевать популярность, но это случится не раньше чем через 20-30 лет. Сегодня же мы имеем стандарты ODMG 3.0 и JDO , которые вполне адекватно определяют методы интеграции в C++, Java и Smalltalk (C# и другие языки платформы .NET расширяются по аналогии) функциональности для обеспечения сохраняемости объектов (object persistence). И выглядит это довольно просто - вы объявляете любой класс как класс "поддерживающий сохраняемость" и после этого объекты такого класса могут быть сделаны сохраняемыми (т.е. они будут записаны в БД). Манипулируя с сохраняемыми объектами в рамках транзакций вы обеспечиваете сохранение всех изменений в БД. Изменяя объекты вне транзакций вы изменяете их только в памяти приложения.

С уважением и с наступающим Новым Годом,
Алексей Ровдо
29 дек 04, 12:24    [1217786]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Мимо пробегал...
Guest
Я вот одного не пойму...

автор
...объекты такого класса могут быть сделаны сохраняемыми (т.е. они будут записаны в БД)...


предположим, я хочу найти нечто вроде

SELECT ...что-то... FROM SomeClass WHERE SomeClass.Method() = ...чему-то...

Это что, все объекты класса SomeClass должны будут .....мммм..... актуализироваться на клиенте, дабы выполнить Method()? Или СУБД такая смартная, что может это у себя делать?
29 дек 04, 18:11    [1219696]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alex.Czech
Guest
Мимо пробегал...
Я вот одного не пойму...

автор
...объекты такого класса могут быть сделаны сохраняемыми (т.е. они будут записаны в БД)...


предположим, я хочу найти нечто вроде

SELECT ...что-то... FROM SomeClass WHERE SomeClass.Method() = ...чему-то...

Это что, все объекты класса SomeClass должны будут .....мммм..... актуализироваться на клиенте, дабы выполнить Method()? Или СУБД такая смартная, что может это у себя делать?


Ну а чего собственно в этом такого смартового ? Никого же не удивляет что запросы типа

SELECT * FROM SomeTable WHERE fn(SomeTable.ID) = 5
зашибись выполняются без всякой актуализации на клиенте. Чем ООСУБД хуже ?
29 дек 04, 23:49    [1220069]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
c127
Guest
2 Андрей Леонидович

>Уважаемый с127 !

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


Перебранка с Вами, конечно, дело веселое и несет положительные эмоции, но специальный топик ради нее открывать лень.

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

Alexey Rovdo

>"А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий".
Даже по названию темы можно понять, что в вопросе идентификации ОМД нет каких-то общепризнанных стандартов.


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

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

Так вот нельзя ли тут выложить ссылку на эти внутренние стандарты Вашего любимого продукта?
30 дек 04, 02:48    [1220164]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alexey Rovdo
Member

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

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

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

Так вот нельзя ли тут выложить ссылку на эти внутренние стандарты Вашего любимого продукта?


В первом абзаце вы поставили вопрос, а во втором сами же на него ответили - внутри каждого серьезного проекта существует стандарт. Но это вовсе не означает, что все внутренние стандарты в различных СУБД одинаковы и/или общепризнаны. Я подхожу к вопросу в меру своих знаний отдельных продуктов и могу аргументированно показать почему эти продукты относятся к категории действительно объектных систем. Опять таки, только про эти продукты я могу сказать, что они соответствуют спецификациям ODMG 3.0 и JDO (можно ли считать именно соответствие этим спецификациям критерием объектности той или иной системы ?). Тем не менее существуют и другие системы, подробной информацией о которых я не располагаю. Я предложил тему, рассказал о продуктах Versant, узнал много нового об оптимизаторах запросов и преимуществах SQL (причем на примере тех задач, которые никогда и не считал сильной стороной объектных систем), но так ничего и не узнал об объектных функциях и стандартах иных систем (Cache, DB2, Oracle ... ).

Зачем это все? Дело в том, что именно ответ на поставленный вопрос сам по себе уже несет достаточно много информации о том, в каких случаях имеет смысл использовать объектные системы (разные, а не только "мои любимые"). Спор в терминах "крутизны" того или иного продукта и оперирование лишь сущностями терминологического характера (РСУБД/ОРСУБД/ООСУБД) интересен только до определенного предела и имеет скорее эмоциональную окраску. Тем более, что спорить можно только понимая реальные различия и ограничения систем. Так что мне по-прежнему интересно - что же, кроме идеологической ненависти приходит в голову разработчика при словах "объектные СУБД".
Полагаю, что мне прийдется самому исследовать эти отличия и снова предложить свою трактовку. Обращаю, однако, ваше внимание на то, что мое предположение о том, что с объектными функциями популярнейших ОРСУБД просто никто не работает, пока не опровергнуто.
30 дек 04, 12:30    [1221313]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Мимо пробегал...
Я вот одного не пойму...

автор
...объекты такого класса могут быть сделаны сохраняемыми (т.е. они будут записаны в БД)...


предположим, я хочу найти нечто вроде

SELECT ...что-то... FROM SomeClass WHERE SomeClass.Method() = ...чему-то...

Это что, все объекты класса SomeClass должны будут .....мммм..... актуализироваться на клиенте, дабы выполнить Method()? Или СУБД такая смартная, что может это у себя делать?


На примере Versant FastObjects:

Сами методы не хранятся в FastObjects вместе с объектами. Т.е. вы можете выполнить такой запрос и все объекты действительно должны будут актуализироваться на клиенте. Но если этот клиент является сервером приложений, то никакой проблемы в этом нет - актуализировавшись они попадут в кэш и при повторном доступе к этим объектам сервер приложений к серверу БД обращаться не станет.
Это концептуальная особенность FastObjects, предполагающая отделение хранения данных, их описания (описания классов для хранимых объектов находятся в отдельной базе данных) и методов. Следует учесть, что сама база данных вообще может находиться на множестве серверов, а доступ к хранимым объектам можно получить из разных программ, написанных на разных языках программирования. Существуют ООСУБД хранящие методы вместе с объектами, но такой подход накладывает свои ограничения.
30 дек 04, 13:20    [1221561]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
AI
Member

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

А если моя информационная система развертывается и работает на любой базе, так ли уж меня должно волновать то, как внутри этой базы будут лежать данные - в виде таблиц или в виде объектов?


Расскажите подробнее, как хранятся данные в виде объектов. Я это прошу сделать ужу не первый раз, но Вы очень технично уклоняетесь от этого.

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

Расскажете мне, что в объектных свойствах оракла Вас не удовлетворяет, кроме того, что оракл - все-таки еще и РСУБД.
30 дек 04, 13:58    [1221759]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
AI
Расскажите подробнее, как хранятся данные в виде объектов... Кроме того, я еще раз для Вас повторяю, что в том же оракле "таблица" - понятие логическое, поскольку данные реально могут храниться в виде совершенно различных структур.

Расскажете мне, что в объектных свойствах оракла Вас не удовлетворяет, кроме того, что оракл - все-таки еще и РСУБД.


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

PS: По поводу хранения данных в Versant я после праздников обязательно что-нибудь отвечу.
30 дек 04, 16:13    [1222490]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
с127
Guest
2 Alexey Rovdo

>В первом абзаце вы поставили вопрос, а во втором сами же на него ответили - внутри каждого серьезного проекта существует стандарт. Но это вовсе не означает, что все внутренние стандарты в различных СУБД одинаковы и/или общепризнаны.

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

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

Я ведь тоже не из вредности повторяю этот вопрос, все-таки надеюсь, что кто-нибудь ответит.
31 дек 04, 02:19    [1223395]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
vadiminfo
Member

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

А я вообще считаю, что ОМД и РМД - это вопрос десятый.

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

Alexey Rovdo

Главное - это методика разработки информационной системы.

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

Alexey Rovdo

А если моя информационная система развертывается и работает на любой базе, так ли уж меня должно волновать то, как внутри этой базы будут лежать данные - в виде таблиц или в виде объектов?

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

Alexey Rovdo

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


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


Alexey Rovdo

Я также много узнал о том, что в Oracle и DB2 тоже есть функционал для работы с объектами, но какой?


Вот Вам к стати подтверждение того, что существует барьер при переходе от РМД к ОРМД и тем более ООМД. Если про РМД можно сказать что будет, то включение объектов оставляет больше неопределенностей, насчет возможных сюрпризов в последствии. Например, написание SQL уже усложняется. или, объекты могут в данной версии не реплицироваться или еще какие-нибудь ограничения могут всплыть в дальнейшем при развитии проекта. Т.е. мы захотим что-то добавить, например, репликацию, а из-за объектов этого нельзя будет сделать. Это и основной сдерживающий фактор. Например, в одном проекте еще на восьмерке был объектный тип в табле. А потом другие работали с этой таблой (она использовалась в других проектах) и постоянно натыкались на сюрпризы: ошибки непонятные на ровном месте (там мат стоял несусветный из-за этого), природа которых в том, что присутствие такого типа в табле не допускает чего-то там или баг Оракла при работе с таким типом. Объектные типы там пока еще далеки от идеала. Только крайняя нужда заставляет их использовать.
Хотя может и сама модель ОРМД не очень хороша. Больше времени на то, чтобы ее понять нужно.
У Оракла функционал приближается потихоньку к поддержке известных принципов ООП. Кроме того, есть разные рел стуктуры для них: они могут быть типами данных колонок обычных табл, но может быть табла построенная на объектном типе (в ОРМД не используется термин класс, вместо этого типы - пользовательские, объектные - кто во что горазд, еще не сложилась терминология). Кроме того, у Оракла есть специальные предопределенные объектные типы для некоторых специальных типов приложений. Например, геометрических и геоинформационных, XML. Но, я думаю, на это там стоит смотреть в перспективе. Однако, в стандарте SQL99 есть про такие типы.

Alexey Rovdo

. А вывод я могу сделать из этого такой - все это еще находится в рудиментарном состоянии и работать с этим неудобно, зато есть чисто объектные системы, в которых инструментарий вылизывался десятки лет и которые строятся на базе стандартов

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

Alexey Rovdo

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

Это же и еще одна трудность для ООСУБД. Недостаток, связанный с недостаточным опытом применения таких БД.
31 дек 04, 17:38    [1224308]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 [8]      все
Все форумы / Сравнение СУБД Ответить