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


Для создания хранимых процедур и триггеров нужно использовать Versant/SQL, и работать они могут только опять же через слой Versant/SQL, который является отдельным от Versant/ODBMS продуктом. По-моему, не очень удобно...
5 апр 05, 12:04    [1441202]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
2 Dimonische
Теперь уже вы страдаете нежеланием слушать? :))
Последние 150 постов некто говорит о том, что апп-сервер необходимая вещь для работы с версантом, потому как именно там, в апп-сервере и реализуется вся ботва по поводу объектов и их методов. Без апп-сервера нет системы, только хранилище данных.
Отсюда следует, что триггеры и ХП - для отмазки. О чем я и говорил. Вы что-то другое услышали? :))

-- Tygra's --
5 апр 05, 12:08    [1441215]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Для создания хранимых процедур и триггеров нужно использовать Versant/SQL, и работать они могут только опять же через слой Versant/SQL, который является отдельным от Versant/ODBMS продуктом. По-моему, не очень удобно...

Ну тем более - можно даже сказать, что нет в версанте никаких триггеров и ХП. В общем это что-то, похожее на файл .txt, если убрать все отдельные примочки. :))

-- Tygra's --
5 апр 05, 12:10    [1441227]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Было сказано, апп-сервера похожи на ХП. Однако не было сказано, что это одно и тоже да еще в смысле всей СУБД ...


Таки чем же конкретным они отличаются?

tygra

Зачем мне что-то выбирать? Есть СУБД, есть спецификации работы с ними и доступа к ним. Все уже выбрано.


Но производители ООСУБД поддерживают несколько спецификаций работы с ними (варианты 1 и 2 выше). Какую спецификацию вы хотите рассматривать?

tygra

А то, что вы прилепили к БД апп-сервер - это не есть СУБД, это есть система с многозвенной технологией. И все.


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

Но прежде, чем комментировать ваши высказывания лучше всего внятно разобраться с тем, что же такое клиент-серверная архитектура. И, ой, оказывается в любом клиент-серверном приложении существует несколько слоев:
1) компонент представления данных
2) прикладной компонент
3) компонент управления ресурсом

Можем ли мы сказать после этого, что типовое клиент-серверное приложение многозвенно (имеет несколько уровней) ?

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

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

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

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

tygra

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

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


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

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

tygra

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

А есть такая задача??? У меня нет - все вместе иногда, иногда раздельно.


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

tygra

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


Надеюсь все-таки, что код "внутри" СУБД у вас разделен по уровням ответственности. А мое замечание, сделанное выше, не про вас. :)

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


А как клиент подключается к СУБД? Святым духом? А драйверы, обеспечивающие сетевое соединение клиента и СУБД - не сервисы ОС?
Вы просто делаете попытку закрыть глаза на очевидное - ОС обеспечивает очень многим и клиентов и СУБД и "пользуют" они друг друга на самых разных этапах. Абстрагироваться от этого ("есть СУБД, она как-то работает...") - не значит отменить сам факт, а знание о том, как же СУБД работает на самом деле, не такое уж и таинственное. И IIS, как вы его не называйте - клиент/сервер приложений - в первую очередь просто некий сервис, который в зависимости от прихоти производителя может быть как в составе ОС, как в составе СУБД, так и сам по себе. И ничего фундаментального за этим не стоит - есть только удобство развертывания и администрирования, а также упомянутые выше "прихоти производителя" и все.
5 апр 05, 12:30    [1441294]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
самопал
Guest
Я смотрю, уже недалеко до утверждений о "многозвенности" BIOS ... :)) Шутка
5 апр 05, 12:46    [1441385]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Я думаю если туда и встраивали веб-сервер, то уж явно не за тем, чтобы систему легче было развертывать :)


Легче развертывать, чем "СУБД + отдельный веь-сервер".
Ну можно добавить: дороже продавать, проще рекламировать и т.п.

ASCRUS

СУБД мощная, позволяет описать на процедурном SQL, то есть на одном диалекте, все необходимое для жизни БД как автономной и самодостаточной,


Тут надо поправочку - РСУБД. SQL ориентирован на использование именно в реляционных системах и достаточно неудобен в объектных. Но какой язык удобен для написания процедур в объектных системах? Java и C++ вполне подходят. Но код на С++ надо компилировать и это достаточно сложная задача, учитывая все богатство этого языка. Java подходит лучше, но он так стремительно развивается, что поспеть за всеми нововведениями достаточно проблематьично. А тут еще и C# подоспел.

Когда-то разработчики таких ООСУБД, как GemStone и O2 решили, что в их системах будет встроенный сервис, отвечающий за исполнение хранимых здесь же кодов методов. Для начала им пришлось изобретать собственные ОО-языки на базе существовавших к тому времени языков программирования. Затем оказалось, что от сервисов этих - поначалу довольно ущербных - пользователи хотят гораздо большей функциональности (собственно всей, что доступна, например, при написании Java-программ) и соотвествия стандартам. Но это непосильная ноша для разработчиков ООСУБД. И именно поэтому Gemstone и Ontos не стали лидерами на этом рынке. Лидерами стали системы, которые сосредоточились на стандартной интеграции с существующими сервисами исполнения кодов на ОО-языках - и роль таких сервисов сегодня способны исполнять такие продукты как JBoss (Java), BEA Weblogic (Java), IBM Websphere (Java), MS IIS (.NET), Apache Tomcat (Java) и др.

ASCRUS

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


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

ASCRUS

Так что изначально заложенная концепция централизованности, автономности и единого диалекта скриптов (WatcomSQL) уже изначально подразумевала, что веб-сервисы, так или иначе влияющие на бизнес-логику БД должны быть в ней и только в ней, ну и при дальнейших размышлениях GRANT-ы на них, возможность получения веб-сервисами HTTP параметров, переданных клиентом и т.д. и т.п. Что и было реализовано 2 года назад и успешно набирает обороты :)


А возможно еще через 10 лет. Кто-то в аналогичном форуме даже будет утверждать, что СУБД без встроенного веб-сервиса не является СУБД. И вообще отдельный веб-сервис противоречит фундаментальному принципу целостности данных. А то что когда-то существовали "якобы СУБД" без веб-сервисов, то это просто от недомыслия их разработчиков - они же не следовали общепризнанным канонам ...
5 апр 05, 12:58    [1441447]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Достали ГУРУ без образования и о
Guest
....И ваще, если взять процессор, то он постоянно что-то вычисляет. А еще в компе есть сетевые корточки. И все это ходит по проводам и через хаб, котрые соединены разьемами RJ-45. А если кто не поверит, я могу тдать кучу ссылок. Прикинь Тигра, скока компонентов в твоем клиент-сервере.

А "учитесь смотреть шире", и "не зацикливайтесь" здесь уже было.
5 апр 05, 13:14    [1441532]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

Откуда:
Сообщений: 137
самопал
Dimonische
уже необнократно тут было сказано про хранимые процедуры и триггеры в Версанте.


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


Он полностью интегрирован в Versant и после установки является его неотемлемой частью, ну как сервис паки к базе
5 апр 05, 13:19    [1441569]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

Откуда:
Сообщений: 137
tygra
2 Dimonische
Теперь уже вы страдаете нежеланием слушать? :))
Последние 150 постов некто говорит о том, что апп-сервер необходимая вещь для работы с версантом, потому как именно там, в апп-сервере и реализуется вся ботва по поводу объектов и их методов. Без апп-сервера нет системы, только хранилище данных.
Отсюда следует, что триггеры и ХП - для отмазки. О чем я и говорил. Вы что-то другое услышали? :))

-- Tygra's --


Говорится следуещее - если хотите чтобы методы исполнялись - юзайте аппсервер. Если вам целостность - пишите процедуры и триггеры. Алексей предпочитает аппсерверы. Я предпочитаю чтобы нам ДВА писал процедуры + триггеры.
5 апр 05, 13:22    [1441590]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Эхехе, продолжаем прием заявок на посещение психотерапеута
автор
Таки чем же конкретным они отличаются?

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

Ту, которую поддерживают СУБД без ОО :)
автор
Классическое определение Томпсона говорит нам, что многозвенная технология - серия взаимозависимых задач, которые выполняются последовательно. Полагаю, однако, что вы имели ввиду "многозвенную архитектуру" и/или "многозвенные приложения".

Полагаю, что и так понятно, что имелось ввиду, без определений и т.д. :)
автор
Но прежде, чем комментировать ваши высказывания лучше всего внятно разобраться с тем, что же такое клиент-серверная архитектура. И, ой, оказывается в любом клиент-серверном приложении существует несколько слоев:
1) компонент представления данных
2) прикладной компонент
3) компонент управления ресурсом

Можем ли мы сказать после этого, что типовое клиент-серверное приложение многозвенно (имеет несколько уровней) ?

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

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

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

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

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

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

Нет, я уже написал, что несогласился, а выше привел расширенный ответ, ваш в том числе.
Вы как вообще делаете дела - одни соглашения. Причем с самим собой. Причем на уровне: есть проблема, но соглашусь, что ее нет.
автор
Т.е. вы хотите сказать, что в исходных кодах ваших приложений прикладные проблемы не выделены явно в отдельных сегментах/процедурах/триггерах/библиотеках, а перемешаны вместе с кодом, задачи которого состоят сугубо в обеспечении целостности данных? Поздравляю! Но не завидую вашему работодателю, tygra. Уволить вас ему будет очень накладно - все ваши приложения можете дорабатывать и сопровождать только вы, поскольку новый человек в такой каше никогда не разберется. Удивляет только, что вы еще умудряетесь и пропагандировать такой подход "сваливай все в одну кучу".

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

Точно, не про меня. Но про уровни ответственности - ?


-- Tygra's --
5 апр 05, 13:43    [1441680]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
самопал
Guest
Dimonische
Он [Versant/SQL] полностью интегрирован в Versant и после установки является его неотемлемой частью, ну как сервис паки к базе

Но чтобы эти триггеры срабатывали, INSERT/UPDATE нужно делать только через Versant/SQL, запросы VQL и изменения состояния через установку атрибутов объектов и сохранение PersistenceManager'ом не будут вызывать триггеры...
Поправьте, если я ошибся.
5 апр 05, 13:43    [1441681]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Говорится следуещее - если хотите чтобы методы исполнялись - юзайте аппсервер. Если вам целостность - пишите процедуры и триггеры. Алексей предпочитает аппсерверы. Я предпочитаю чтобы нам ДВА писал процедуры + триггеры.

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

-- Tygra's --
5 апр 05, 13:46    [1441698]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Уже бы хотелось понять вопрос, который обсуждается, а может задать новый. А то уже полная каша, и если кто-то начнет обсуждать теорию и практику холодного термоядерного синтеза, то это будет вроде как по теме
-- Tygra's --
5 апр 05, 13:49    [1441718]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

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

Но неплохо было бы, если внутри ХП можно было бы вызвать метод объекта. Тогда вообще было бы все хорошо. И апп-сервера нет, и методы исполняются, и ХП работают.

-- Tygra's --


Хорошо бы хорошо бы
нам моржа поймать - большого, пребольшого :)
5 апр 05, 13:50    [1441720]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

Откуда:
Сообщений: 137
самопал
Dimonische
Он [Versant/SQL] полностью интегрирован в Versant и после установки является его неотемлемой частью, ну как сервис паки к базе

Но чтобы эти триггеры срабатывали, INSERT/UPDATE нужно делать только через Versant/SQL, запросы VQL и изменения состояния через установку атрибутов объектов и сохранение PersistenceManager'ом не будут вызывать триггеры...
Поправьте, если я ошибся.


Хм, вот это реальная засада, если это так. Я попросту не знаю. Возможно, Алексей знает.
5 апр 05, 13:51    [1441725]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Достали ГУРУ без опыта работы
Guest
автор
Легче развертывать, чем "СУБД + отдельный веь-сервер".
Ну можно добавить: дороже продавать, проще рекламировать и т.п.


А то, что с этим проще и надежнее работать - что, ума не хватило добавить или смелости слить спор?

Уважаемый коллега AR. Ваши постянные передергивания и попытки гнать дурку слегка достали. Например тигра сказал
Тигра
Хорошо, хорошо, пусть с натяжкой можно сказать, что апп-сервера где-то и как-то почти похожи на ХП ...
. Точно также можно сказать, что натяжкой арифмометр похож на КПК - "а потому что считает!". Потом Вы делаете круглые глаза и спрашиваете - ну чем, чем же они отличаются? Причем Вам эти различия были объяснены и с технологической и с логической и даже слегка с формальной точки зрения (Вы сказали, что прикладные частности ГЫ-US - то факт, что из-за этих "прикладных частностей" весь технологический сыр-бор (не только здесь) и разгорается Вас не смущает), но Вы, блин, через три разворота опять ничего не понимаете - опять круглые глаза. Ну перечитайте топик сначала, раз у вас в голове дальше предыдущего поста ничего не храниться.

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

И т.д. и т.п.
5 апр 05, 13:52    [1441726]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Alexey Rovdo
ASCRUS

Я думаю если туда и встраивали веб-сервер, то уж явно не за тем, чтобы систему легче было развертывать :)


Легче развертывать, чем "СУБД + отдельный веь-сервер".
Ну можно добавить: дороже продавать, проще рекламировать и т.п.

Ничего подобного. После появления веб-сервисов в 9-ой версии цена осталась такой же, какой была ранее у 8-ой версии - 500$ сервер, 90$ одно подключение или 2500$ на процессор. В рекламе смысла то же нет - ASA флагман мобильных и удаленных СУБД, веб-сервисы там очень даже были нужны для работы мобильных СУБД на КПК/ноутбуках с удаленными серверами через интернет.

Alexey Rovdo
ASCRUS

СУБД мощная, позволяет описать на процедурном SQL, то есть на одном диалекте, все необходимое для жизни БД как автономной и самодостаточной,


Тут надо поправочку - РСУБД. SQL ориентирован на использование именно в реляционных системах и достаточно неудобен в объектных. Но какой язык удобен для написания процедур в объектных системах? Java и C++ вполне подходят. Но код на С++ надо компилировать и это достаточно сложная задача, учитывая все богатство этого языка. Java подходит лучше, но он так стремительно развивается, что поспеть за всеми нововведениями достаточно проблематьично. А тут еще и C# подоспел.

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

А вот для неформализованных ООП очень даже нужен, где существует динамически расширяемая по ходу работы структура данных, где основная задача хранение и обработка достаточно разносторонней с неизвестной структурой на момент проектирования приложения информации. Надо думать не зря именно на CACHE сейчас существует множество CRM-систем. Однако и здесь я бы желал видеть обьекты, как часть БД с хранением их метаструктуры и методов в БД как обьектного скриптового языка. Вместо SQL тут мне бы было желательно увидеть скриптовый функциональный язык. Клиенту же оставалось получать данные как XML/наборы данных и опять же на стандартных компонентах разворачивать их в наборы данных/гриды/отчеты. Однако то что описываете Вы лично меня пока совсем не устраивает. Я прекрасно представляю что такое ООП в Java или C и лично мне удобно на них делать свои парсеры, языки, IDE, компоненты и т.д., но уж никак обработку множеств. Да и потом скриптовый интерпретируемый язык для описания структуры обьектов, их методов и запросов гораздо удобнее смотриться в задачах с динамическим изменением их структуры, взять тот же Python, вот кто бы неплохо смотрелся с моей точки зрения в качестве процедурного языка в ООБД при соответствующих доработках и интеграции его обьектов в хранилище БД :)

Alexey Rovdo

Когда-то разработчики таких ООСУБД, как GemStone и O2 решили, что в их системах будет встроенный сервис, отвечающий за исполнение хранимых здесь же кодов методов. Для начала им пришлось изобретать собственные ОО-языки на базе существовавших к тому времени языков программирования. Затем оказалось, что от сервисов этих - поначалу довольно ущербных - пользователи хотят гораздо большей функциональности (собственно всей, что доступна, например, при написании Java-программ) и соотвествия стандартам. Но это непосильная ноша для разработчиков ООСУБД. И именно поэтому Gemstone и Ontos не стали лидерами на этом рынке. Лидерами стали системы, которые сосредоточились на стандартной интеграции с существующими сервисами исполнения кодов на ОО-языках - и роль таких сервисов сегодня способны исполнять такие продукты как JBoss (Java), BEA Weblogic (Java), IBM Websphere (Java), MS IIS (.NET), Apache Tomcat (Java) и др.

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

Alexey Rovdo
ASCRUS

Так что изначально заложенная концепция централизованности, автономности и единого диалекта скриптов (WatcomSQL) уже изначально подразумевала, что веб-сервисы, так или иначе влияющие на бизнес-логику БД должны быть в ней и только в ней, ну и при дальнейших размышлениях GRANT-ы на них, возможность получения веб-сервисами HTTP параметров, переданных клиентом и т.д. и т.п. Что и было реализовано 2 года назад и успешно набирает обороты :)


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

Я не против ООБД. Я против неэффективного труда, поэтому стараюсь выбрать то, что наиболее оптимальное под существующие задачи. 12 лет назад я писал достаточно крупные по тем меркам проекты, которые сейчас мне кажутся смешными и маленькими. Возможности автоматизации и аппетиты пользователей движутся вперед, соотвествующе и технологии развиваются в ту или иную сторону. Однако пока основные потребности "аппетитов" перекрываются РСУБД, хотя и очевидно, что не зря появился XML и для тех же РСУБД ужесточаются требования к интеграции, обмену данных, репликациям и .д. Появятся ООБД, которые позволят мне быстро и эффективно разрабатывать крупные проекты, более легко работая, описывая и изменяя структуру данных и логику работы с ними, особенно с неформализованными данными, чем сейчас это есть в РСУБД, тогда и повод с ними познакомиться поближе появиться. А пока они частный случай и доводы, что ООП программистам видите ли легче работать с обьектами, чем SQL, потому что множества они не понимают - не катит :)
5 апр 05, 13:54    [1441735]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Достали ГУРУ - рекламисты!!!
Guest
... ошибки исправил....

автор
Легче развертывать, чем "СУБД + отдельный веь-сервер".
Ну можно добавить: дороже продавать, проще рекламировать и т.п.


А то, что с этим проще и надежнее работать - что, ума не хватило добавить или смелости слить спор?

Уважаемый коллега AR. Ваши постянные передергивания и попытки гнать дурку слегка достали. Например тигра сказал
Тигра
Хорошо, хорошо, пусть с натяжкой можно сказать, что апп-сервера где-то и как-то почти похожи на ХП ...

. Точно также можно сказать, что ,с натяжкой, арифмометр похож на КПК - "а потому что считает!". Потом Вы делаете круглые глаза и спрашиваете - "ну чем, ну чем же они отличаются???" Алле! Вам эти различия были объяснены и с технологической, и с логической, и даже слегка с формальной точки зрения (Тут Вы сказали, что это - прикладные частности. ГЫ-ГЫ! Тот факт, что из-за этих "прикладных частностей" весь технологический сыр-бор глобально и разгорается - Вас не смущает), но Вы, блин, через три разворота опять ничего не понимаете - опять круглые глаза. Ну перечитайте топик сначала, раз у вас в голове дальше предыдущего поста ничего не храниться.

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

И т.д. и т.п.
5 апр 05, 13:59    [1441769]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


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

И я бы снова хотел вернуться к одному документу уже упоминавшемуся мной выше. Это отчет ANSI X3/SPARC/DBSSG Object-Oriented Database Task Group (OODBTG) от 1991 года. Исследуя проблемы стандартизации ООСУБД разработчики этого отчета пришли к следующему выводу (в отношении стандартов):

Thus a very strong recommendation is to re-examine traditional boundaries, both in
computer technology and in standards organizations (see Section 2.8.1, Recommendation):

2). Database may no longer be an isolatable component of a software system. Relevant standards should be developed cooperatively by database committees, programming language committees, repository committees, network management committees, and so on.
Object technology standards should be developed in a way that promotes harmony across these boundaries.


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

vadiminfo

Вы же сказали, что в ООСУБД есть трудности с ограничениями целостности.


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

vadiminfo

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


Отрицая Java и C++-программный код в роли средства обеспечения целостности данных, будьте последовательны. А чем SQL-код лучше?
Просто для РСУБД "родным" является именно язык SQL. Но для объектных данных нужен объектно-ориентированный язык и SQL для этого неудобен.

vadiminfo

Alexey Rovdo

Напоминаю, что речь идет о разнице между пунктами внутри ветви 2 по моей классификации. Но я здесь никакой разницы, влияющей как-то на НАПИСАНИЕ программ не вижу. Поясните, в чем же конкретно вы ее наблюдаете.

В одном случае Вы говорите, что можно поддержать ограничения целостности как в РМД, но страет ОМД. В другом не страдает ОМД, но страдают ограничения целостности. Значит можно предположить ухудшится БД. Ну а это надо компенсировать программированием (если получится). Вот и влияние на программирование.


Это сравнение п.1 и п.2 по моей классификации. Разумеется здесь есть разница в написании программ (ее нет внутри п.2). Но я только не соглашусь с тем, что что-то страдает. В первом случе имеет место некоторый отход от ООП (как я его понимаю), а во втором - ограничения целостности реализуются в полной мере, только реализуются иначе.

vadiminfo

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


Если рассматривать меня как представителя именно лагера ООСУБД (с чем я кстати не согласен - я скорее эксперт и стараюсь быть аполитичным, просто я что-то знаю об ООСУБД), то, наверное, стоит делать акцент на ООСУБД Versant.

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

vadiminfo

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


Именно поэтому я внес в перечень критериев для сравнения и такой пункт:

Наличие стандартов и спецификаций на протоколы доступа к сервисам системы со стороны клиентских приложений.

vadiminfo

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


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

vadiminfo

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


Про ограничения целостности в Versant вам напишет Demonishe (мне надоело). А вот представте, что мы сравниваем молотки (обычный и строительный пистолет). Вам говорят этим молотком нужно размахиваться и колотить по гвоздю, а этот - приложить к доске и нажать курок. Давайте мол сравнивать. А вы начинаете настаивать - мол надо колотить и тем и тем, а то сравнение какое-то неправильное. Но сравнивать то нужно не инструмент, а результат.
5 апр 05, 14:08    [1441812]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Долой ГУРУ - демагогов!!!
Guest
....Ну вот - опять закидоны в стиле нарицательного "Коллеги ЧАЛ"

коллега AR
Полагаю вы читали этот топик и видели то, как возникло и к чему пришло данное мнение (ООСУБД - не СУБД, а Persistence Object Storage).


Уважаемый!!! "Мнение" пришло к тому, что система, извествная как Версант, не является OOСУБД. Фраза "ООСУБД - это не СУБД" это плоды Вашей буйной фантазии!!!
5 апр 05, 14:32    [1441928]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Достали извортливые рекламщики!!
Guest
Отличный маркетинговый ход!!! Сначала мы высосали из пальца некую классификацию, а потом, как то случайно получилось, что в этой классифика VERSANT - лучшая ООСУБД. Хотите я предложу свою классификацию? все программы начинающиеся на V являются лучшими OOСУБД! все прогаммы, не начинающеся на V таковыми не являются. О! опять победил Versant!!!
5 апр 05, 14:38    [1441969]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Достала вездесущая наглая реклам
Guest
Ну есть же специальный топик по Версанту!!! ЭЙ, МОДЕРАТОР! А не перенести ли в него этак двадцать последних разворотов?
5 апр 05, 14:41    [1441982]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Достали извортливые рекламщики!!
Отличный маркетинговый ход!!! Сначала мы высосали из пальца некую классификацию, а потом, как то случайно получилось, что в этой классифика VERSANT - лучшая ООСУБД. Хотите я предложу свою классификацию? все программы начинающиеся на V являются лучшими OOСУБД! все прогаммы, не начинающеся на V таковыми не являются. О! опять победил Versant!!!


Надо релаксировать. Важна только информация повышающая нашу оплату.
5 апр 05, 14:42    [1441989]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Rovdo
Но прежде, чем комментировать ваши высказывания лучше всего внятно разобраться с тем, что же такое клиент-серверная архитектура. (http://www.mstu.edu.ru/education/materials/zelenkov/ch_7_1.html)

Разбираться в этом нужно, но лучше не по приведенной статье. Статья гниловатая. Во-первых, деление системы на три части ничем не обосновано. Можно с ходу выделить еще несколько вариантов такого «разделения». А надо ли? Чем это обосновать? Во-вторых, вся дальнейшая «теория» идет со ссылкой на компанию Gartner Group. Спору нет, контора солидная, но что-то крупными теоретиками их никто не числил. Чтобы обосновать ссылку на Gartner Group, автор пишет, что компания-де «специализируется в области исследования информационных технологий». Ну и что? Вот что они сами про себя пишут: ”Gartner, Inc. is the leading provider of research and analysis on the global IT industry.” Это мы и сами знаем, что они индустрию исследуют. И пусть. Но это не есть основание полагать, что любой их теоретический бред пойдет на «ура». А бред есть. Прочитав данную заметку вы все с удивлением узнаете, что файл-серверная технология является частным случаем клиент-серверной (вот шайтан). Вот тебе и теоретики. Хотя полагаю, что Gartner тут не при чем, это автор товарищ Зеленков накосячил.
Rovdo
Можем ли мы сказать после этого, что типовое клиент-серверное приложение многозвенно (имеет несколько уровней)?

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

Откуда:
Сообщений: 137
Достала вездесущая наглая реклам
Ну есть же специальный топик по Версанту!!! ЭЙ, МОДЕРАТОР! А не перенести ли в него этак двадцать последних разворотов?


Гы. Общественность волнуется. Обобщенного понятия ОСУБД нет чтоыбы его сравнить с СУБД. А есть здесь 3 человека которые знают в определенных масштабах Версант. И больше никто здесь по объектным базам ничего не говорит. Зовите другие объектные базы сюда сами.
5 апр 05, 14:45    [1442004]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 68 69 70 71 72 [73] 74 75 76 77 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить