Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 63 64 65 66 67 [68] 69 70 71 72 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Недоучка

>А Вы со мной не спорьте, Вы мне тупенькому объясните, или книжку подскажите, где написано, что "В ПОЛЬЗОВАТЕЛЬСКОМ ПРИЛОЖЕНИИ И В ООБД ОБЪЕКТЫ РАЗНЫЕ"...

Я же сказал, надоело ликбезом заниматься, ваше образование и Ваша тупость это Ваши проблемы, мне до них дела нет. Был вопрос:

Недоучка>>> Любопытно, чем они отличаются ПРИНЦИПИАЛЬНО?

был ответ:

c127>> Ничем.

Как я понял по существу возражений нет, тему можно считать закрытой.
31 мар 05, 07:12    [1428674]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Недоучка
Guest
c127
2 Недоучка

>А Вы со мной не спорьте, Вы мне тупенькому объясните, или книжку подскажите, где написано, что "В ПОЛЬЗОВАТЕЛЬСКОМ ПРИЛОЖЕНИИ И В ООБД ОБЪЕКТЫ РАЗНЫЕ"...

Я же сказал, надоело ликбезом заниматься, ваше образование и Ваша тупость это Ваши проблемы, мне до них дела нет. Был вопрос:

Недоучка>>> Любопытно, чем они отличаются ПРИНЦИПИАЛЬНО?

был ответ:

c127>> Ничем.

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


Любезный c127!
Вынь из задницы кипятильник, остынь и не бубни... Ляпнул глупость - имей мужество это признать. (Никто тебя не съест за это, со всяким бывает...) А строить из себя ВЕЛИКОГО ВСЕЗНАЙКУ - дерьмо.

2 All - Прошу прощения за "выход из темы".
31 мар 05, 07:26    [1428683]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Недоучка

>Любезный c127!
Вынь из задницы кипятильник, остынь и не бубни... Ляпнул глупость - имей мужество это признать. (Никто тебя не съест за это, со всяким бывает...) А строить из себя ВЕЛИКОГО ВСЕЗНАЙКУ - дерьмо.

2 All - Прошу прощения за "выход из темы".


Зачем так нервничать. Вас что-то беспокоит, создает дискомфорт, жжет?

Утверждая, что "строить из себя ВЕЛИКОГО ВСЕЗНАЙКУ - дерьмо." Вы тем самым сами строите из себя великого всезнайку, и учите людей жить. А потому Ваше утверждение либо ложно, либо относится и к Вам. Выбирайте, что Вам больше нравится. В первом случае прослывете глупцом, во втором польете себя же своим же вторичным продуктом. Решение как обычно за Вами.

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

Не моя вина, что Вы не видите разницы между "Любопытно, чем они отличаются?" и "Любопытно, чем они отличаются ПРИНЦИПИАЛЬНО?". Выделено Вами же. Так что все правильно. На вопрос:

Недоучка>>> Любопытно, чем они отличаются ПРИНЦИПИАЛЬНО?

Я ответил:

c127>> Ничем.

Что есть точный и полный ответ на Ваш вопрос.

Недоучка> Вы меня совсем запутали - поясните, что такое разные объекты, которые ничем не отличаются? ;-)

А вот это передергивание, поскольку это уже другой вопрос который к Вашему первоначальному отношения не имеет, ибо там речь шла об "отличаются ПРИНЦИПИАЛЬНО" (выделено недоучкой).

Ну и при чем тут я?

Еще раз предлагаю закрыть тему.
31 мар 05, 08:40    [1428741]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Павел Воронцов

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


Я, например, не отрицаю влияния потребительских штампов на выбор потребителя, и учитывать эти штампы на практике приходится всегда (т.е., если вы разумны и знаете мнение банкира, то зачем заикаться?). Но это вовсе не мешает мне понимать и тот факт, что это всего-лишь "потребительские штампы", которые во многом базируются не на объективной оценке текущих реалий, а на субъективных факторах. Но здесь то мы, как мне кажется, обсуждаем не общественное мнение, сложившееся о разных СУБД, а именно сами эти СУБД.
31 мар 05, 09:28    [1428813]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
x
Guest
Павел Воронцов
Попробуйте заикнуться в беседе с банкиром, которому Вы пишите софт, что ваша система не обеспечивает целостность на уровне СУБД, а только в связке с приложением! Знаете куда он Вас .. что он Вам скажет?
К сожалению подавляющее большинство банковского софта не имеют ограничений целостности и защиты в базе. Даже внешние ключи определены не у всех (замедляют работу). А есть и более клинические случаи с отсутствующими первичными ключами (а зачем - есть же индексы). А не далее как вчера познакомилcя с базой у которой нет уникальных индексов (точнее они конечно есть по факту, но свойство уникальности не установлено). Причем внедрять этот продукт мы все равно будем - требование бизнеса.

Увы...
31 мар 05, 09:51    [1428861]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

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

Вы зря недооцениваете умственные способности заказчика. Он далеко не дурак и мыслит не только штампами. У него жесткие требования, которые к нему предъявляют его клиенты и его бизнес. Целостность и безопастность должны быть обеспечены в любом случае, даже если при этом пострадают простота и скорость проектирования системы.

Я не говорю, что в связке "хранилище-апп сервер" нельзя обеспечить целостность и безопастность. Просто для достижения этих значимых для заказчика характеристик надо порой прилагать больше усилий и рисков больше. И заказчик об этом знает. Может это и штамп, но уж очень похожий на правду.
31 мар 05, 09:52    [1428864]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

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

Увы...
Ну что тут скажешь - только увы....
31 мар 05, 09:54    [1428867]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


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



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

serg99

ХП как правило не взаимодействует с пользователем (не является интерактивной), не взаимодействует непосредственно с внешними приложениями или с внешними устройствами.


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

serg99

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


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

serg99

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


А может действительно все дело в названии?

serg99

Приложение может использовать ХП, но ХП это не приложение. Как скажем не является приложением процедура в VideoBIOS меняющая режимы видеодаптера.


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

serg99

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


Вы почему-то считаете невозможными такие "договоренности" игнорируя их наличие в мире СУБД. Что есть SQL и ODBC как не "договоренность"? А документация на программные продукты не помогает "проинструктировать" программистов использованию СУБД? Но такие же спецификации и руководства есть и в мире серверов приложений. Почему вы их не относите к "договоренностям"?

serg99

Что бы мы не встроили в СУБД, оно уже не будет приложением. По опредлению приложение «внешне» относительно СУБД.


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

serg99

Не понятно так же почему обеспечение согласованности для ООБД настолько сложное что требует вставки туда ХП сравнимых по сложности с Jboss.


Я уже говорил, что это вопрос дискутируемый. Но вот вам пример: как декларативно ограничить диапазон значений объектов класса, если в разных его подклассах-наследниках операторы <, > переопределяются?

serg99

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


Код, обеспечивающий целостность данных, должен существовать в одном экземпляре. И с этим (как я уже тысячу раз говорил) я не спорю. Описанная вами и Воронцовым ситуация - простая иллюстрация неправильного разделения уровней приложения и больше ничего. Все эти проблемы имеют множество вариантов решения и никак не противоречат моей позиции.
31 мар 05, 10:03    [1428892]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2405
Блог
Alexey Rovdo
Описанная вами и Воронцовым ситуация - простая иллюстрация неправильного разделения уровней приложения и больше ничего.
Спасибо на добром слове. Вы мне всё больше Андрея Леонидовича напоминаете, увы.

Проблема не в том, чтобы выделить уровни приложения, а в том, что с данными работает много приложений. И далеко не все из них оперируют объектами. И представление данных для разных приложений разное. А бизнес-правила, по которым эти данные должны изменяться - одни. А приложения могут и новые появиться (и появляются).
31 мар 05, 10:32    [1428987]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Павел Воронцов

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


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

Я упомянул уже приложение по хранению статических данных. Да, можно было бы предоставить всем клиентам доступ к Ораклу непосредственно. Но Наши клиенты этого не хотят. Потому что мы предоставляем доступ намного проще чем Оракл. Мы имеем функции специфичные для бизнесов, которые с нами общаются. Фактически, мы реализовали Объектную Базу по предметной области без поддержки языка запросов. Клиенты не могут запускать SQL. Поверьте мне, если бы они хотели, я был бы просто вынужден его бы добавить. Но они не хотят и причина проста - нафига им разбираться с другими(чужими) таблицами, хп, связями и т.д. и п.р. Мы предоставляем простой доступ. Все счастливы.
31 мар 05, 10:49    [1429054]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


Чистой воды прокламация. Этот текст достоин рекламных плакатов, но не может быть аргументом.

vadiminfo

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


Я тоже умею играть словами, но сейчас - неохота.

vadiminfo

Alexey Rovdo

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

Хорошо коли так. Но некоторые говорили, что их Дос не напрягает, и не хотели переходить на Винды. А еще раньше с калькулятора на комп.
Т.е. такие ссылки нельзя назвать лучшим доказательством.


А там (в моем посте) и не было написано, что это доказательство чего-то там, наоборот - там было написано:

Я бы хотел отдельно отметить и вашу фразу "Стоит ли ставку делать на волюнтаризм в виде прихода соглашекний на перекор общей практике?"

т.е. мое высказывание - это своего рода ЗАМЕЧАНИЕ. И касается оно того, что "общая практика" понятие, на которое разные люди смотрят весьма по разному.

vadiminfo

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


Я не против целостности данных, и очень даже за ... бла-бла-бла
Но где заканчиваются данные и средства обеспечения их целостности и начинается система ?

vadiminfo

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


Про Versant я уже говорил - поддерживает. Но вы подходите к вопросу сравнения концептуально! разных СУБД не с позиции сравнения общих и специальных свойств систем, построенных на базе разных СУБД (и проблем их построения), а пользуетесь жестким шаблоном, который сформирован не теорией и не абстрактными понятиями, а рядом конкретных реляционных продуктов. Т.е. по вашему система, не соответствующая этому шаблону в любую сторону, заведомо хуже прототипа. Очевидно, что при таком подходе никаких систем лучше прототипа быть не может - в лучшем случае выйдет 100%-е соответствие шаблону и полная эквивалентность. Яркий пример того, что я здесь имею ввиду это отношение к хранимкам. Похоже единственным определением ХП, которое здесь прокатит будет что-то вроде: "ХП - это такие штуки которые выглядят и работают так же и с тем же, что и те штуки, которые называются хранимыми процедурами в MS SQL Server" ни добавить, ни убавить. В таком контексте и все возражения против моего - более широкого - толкования ХП становятся понятны.

vadiminfo

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


Да замените вы в своих словах "приложение" на "ХП" или "триггеры" и получите то же самое, типа "А что, если в одной БД придется прописывать ограничения целостности в нескольких триггерах", "А что если нам надо иметь несколько копий одной БД" и т.д. и т.п. Все это проблемы правильного разбиения задачи на логические уровни.

vadiminfo

Речь идет о поддержке целостности данных средствами СУБД. Можете ничего не встраивать в СУБД, или встроить туда что угодно, но поддерживать.


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

vadiminfo

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


Вы опять мне рассказываете о том, что ограничения целостности важны. Важны! С этим не спорю.

vadiminfo

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


Хороший пример! Именно приняв соглашение о том, что ток течет от плюса к минусу мы вообще можем говорить о его направлении. Когда принимали это соглашение ничего не знали об электронах, которые как оказалось перемещаются от минуса к плюсу, но это вовсе не мешает проводить все вычисления в соответствии с уже принятым соглашением. А в какую сторону течет переменный ток? Тут даже физической привязки никакой нет - чисто вопрос соглашения. Вам когда-нибудь приходилось рассчитывать электрические цепи? Весь рассчет начинается именно с того, что мы принимаем соглашение о том, что вот здесь ток течет в таком-то направлении и все (совершенно не важно какое соглашение мы приняли).
31 мар 05, 10:55    [1429083]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2405
Блог
Dimonische
Павел, вы почему-то уверены, что предоставить доступ к данным через предоставление доступа к базе - это лучшее что можно сделать. Уверяю Вас, во многих сложных системах это не так.
Dimonische
Ничуть не бывало. Конечный пользователь работает через тот интерфейс и с тем представлением данных, которые ему удобней и понятней.
Я упомянул уже приложение по хранению статических данных. Да, можно было бы предоставить всем клиентам доступ к Ораклу непосредственно. Но Наши клиенты этого не хотят. Потому что мы предоставляем доступ намного проще чем Оракл. Мы имеем функции специфичные для бизнесов, которые с нами общаются. Фактически, мы реализовали Объектную Базу по предметной области без поддержки языка запросов. Клиенты не могут запускать SQL. Поверьте мне, если бы они хотели, я был бы просто вынужден его бы добавить. Но они не хотят и причина проста - нафига им разбираться с другими(чужими) таблицами, хп, связями и т.д. и п.р. Мы предоставляем простой доступ. Все счастливы.
А я Вам сказал, что у вас довольно удачное решение. Я и сам парочку таких проектов когда-то делал со статическим (почти) хранилищем и кучей запросов на выборку. И что? Вы меня либо не слушаете, либо я что-то не так говорю... Повторяю - я не против Версанта, ООБД, новых технологий и апп серверов. И более того - я всё это (вот версант не пробовал) когда надо, когда это оправданно - применяю. Алексей же пытается доказать, что некое хранилище + апп сервер и СУБД - это одно и то же. А это не так.
31 мар 05, 11:02    [1429118]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Алексей,

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

Это существенно снижает продуктивность дискуссии.
31 мар 05, 11:02    [1429120]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Павел Воронцов
Алексей же пытается доказать, что некое хранилище + апп сервер и СУБД - это одно и то же. А это не так.


Алексей прав вот в каком случае: если никому не давать доступ к базе а дать спецификакции на Webservice, RMI, REST сервис - то получится таже база (концептуально) - только на уровне аппсервера.
31 мар 05, 11:04    [1429133]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2405
Блог
что-то я с тэгами напутал...

To Dimonische

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

Откуда: Москва
Сообщений: 913
Павел Воронцов

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


Тут весь вопрос в том как смотреть на данные. Полагаю это уже тема сравнения ООП и иных подходов. Если данные - это объекты организованные в классы, то никаких проблем включить эти классы в атрибуты других объектов нет. Несколько нетипичная для ООП операция - прозрачный перевод объектов одного класса в объекты другого (не связанного с ним иерархически) класса обычно называется "проекцией" (т.е. выдрали отдельные атрибуты из одного класса и отобразили (спроецировали) их на отдельные атрибуты другого класса. Не владею вопросом досконально, но по-мему сейчас необходимый инструментарий для этого появляется в ОО-языках и интерфейсах (таких, как JDO). В ООСУБД VDS такая возможность имеется (с некоторыми оговорками). Но в большей степени это именно задача самих ОО-языков.
31 мар 05, 11:08    [1429146]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

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


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

Сначала неплохо было бы затрвердить мысль, что в Версанте ЕСТЬ ТРИГЕРЫ И ХП.
31 мар 05, 11:12    [1429173]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Павел Воронцов
Member

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

Просто надо знать и видеть преимущества и недостатки разных подходов. Я пока-что недостатков в Версанте вижу больше, чем достоинств. По крайней мере в тех задачах, которые решал и решаю, я бы его пользовать не стал.
31 мар 05, 11:14    [1429183]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
самопал
Guest
Alexey Rovdo
Фактически, мы реализовали Объектную Базу по предметной области без поддержки языка запросов.

Т.е. ООСУБД "заточены" именно под такое использование: создание объектной модели и хранение состояния этой объектной модели - базы "данных объектов"? В таком случае, действительно, каждый объект самостоятельно (или взаимодействуя с другими) должен гарантировать допустимость состояния. И язык запросов не обязателен - мы запрашиваем объекты об их состоянии, а не формируем множество новых утверждений на основании хранимых в БД (в случае SQL). И тогда не нужны триггеры и хп, но ОСУБД должна хранить и выполнять методы этих объектов? Но тогда приложения не должны выполнять эти методы, а вызывать СУБД для их выполнения.
31 мар 05, 11:15    [1429186]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Павел Воронцов

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


Но это и есть то, о чем говорю я. Целостность и безопастность не есть исключительная прерогатива СУБД. Целостность и безопасность МОЖНО обеспечить и в связке "хранилище-апп сервер".

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

Откуда: Новосибирск
Сообщений: 2405
Блог
Alexey Rovdo
Тут весь вопрос в том как смотреть на данные. Полагаю это уже тема сравнения ООП и иных подходов.
Вот именно, я об этом и твержу. Если смотреть на данные, как на стратегический ресурс бизнеса, а на схему данных как на набор бизнес-правил, то данные становятся ценны сами по себе. Без привязки к конкретным объектным структурам конкретного приложения.
Alexey Rovdo
Если данные - это объекты организованные в классы, то никаких проблем включить эти классы в атрибуты других объектов нет. Несколько нетипичная для ООП операция - прозрачный перевод объектов одного класса в объекты другого (не связанного с ним иерархически) класса обычно называется "проекцией" (т.е. выдрали отдельные атрибуты из одного класса и отобразили (спроецировали) их на отдельные атрибуты другого класса. Не владею вопросом досконально, но по-мему сейчас необходимый инструментарий для этого появляется в ОО-языках и интерфейсах (таких, как JDO). В ООСУБД VDS такая возможность имеется (с некоторыми оговорками). Но в большей степени это именно задача самих ОО-языков.
Ну я рад за Версант, что кажется такие средства появились. Это очень славно, хотя и, как Вы правильно сказали, операция абсолютно нетипичная для объектного проектирования. Эта-то нетипичность и пугает.
31 мар 05, 11:21    [1429214]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Я все ждал одного вопроса, но вижу что в явной форме его никто не задаст. Хотя тема наконец озвучена.

Что же делать с запросами в ООСУБД?

Если все хранимые процедуры вынесены в сервер приложений, то получается, что нельзя определить функцию и использовать ее в запросе (в Versant - можно) ? Еще более туманно выглядит вопрос о том, как обрабатывать запросы типа

SELECT * FROM Class WHERE Oblect.method(x) = y

А если операторы переопределяются в подклассах класса, то как обрабатывать запросы вида

SELECT * FROM Class WHERE Object = const_Object2

Свое мнение выдам в следующем посте.
31 мар 05, 11:31    [1429260]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

Откуда:
Сообщений: 137
самопал
И тогда не нужны триггеры и хп, но ОСУБД должна хранить и выполнять методы этих объектов? Но тогда приложения не должны выполнять эти методы, а вызывать СУБД для их выполнения.


Самопал, я ,честно говоря, не понял что вы хотели сказать

Однако, относительно того, почему методы объектов "трудно выполнять" в самой ОСУБД, я могу предположить вот что:

Итак, у нас есть Java объект и его метод. Мы хотим, чтобы этот метод выполнялся и в базе и где-то в другом месте - например на клиенте после получения данного объекта из базы.

Проблемы:

1. Надо обеспечить доступ разных языков к базе данных. Если у нас Java объект, а тело метода - Java байткод, но совершенно не ясно как такой метод будет запускать C++ приложение.

2. Метод этот выполняется не в вакууме. Когда метод выполняется внутри БД, там есть обвязка базы - всякая текущая сессия БД, статические переменные и пр. Это обвязки ессно нет у клиента. Что будет делать метод у клиента? падать с NullPointerException?

В итоги поэтому (мне кажется) у Версанта методы не хранятся в базе а хранятся только поля и связи.
31 мар 05, 11:32    [1429265]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
самопал
Guest
2 Dimonische:
мне просто трудно представить, что существуют такие объектные модели, корректное состояние которых в любой момент времени можно обеспечить, не вызывая методы объектов модели.
Поскольку объектная модель для базы одна, то и вызываемый разными клиентами код методов должен быть тем же.

А если в Versant есть триггеры, и они работают с объектами, то где берется код методов для конструирования "живого" экземпляра? И где этот код выполняется? В СУБД? На клиенте?
31 мар 05, 11:42    [1429324]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


Итак, у нас есть Java объект и его метод. Мы хотим, чтобы этот метод выполнялся и в базе и где-то в другом месте - например на клиенте после получения данного объекта из базы.
Проблемы: ...


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

Похоже в Versant думают примерно так же и работают именно в плане обеспечения легкости интеграции своих продуктов с современными технологиями серверов приложений.
31 мар 05, 11:45    [1429343]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 63 64 65 66 67 [68] 69 70 71 72 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить