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

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

Web-сервис для всех одинаков - как только он появился, его можно использовать хоть из С++, хоть из Java, хоть из эксела - он везде работает одинаково. Он один, он уже реализован - и не зависит от клиентов. Никак.
И сколько бы ни было Web-сервисов - они представлены в единственном экземпляре, на сервере, и для всех одинаковы. А вот их уже используют программы - и не важно, сколько их, хоть сотня программ.

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

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

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

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

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

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

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

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

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

tygra

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


После этого вы снова начинаете гнать волну по новому кругу - я же по новому кругу объяснять. Ну что же попробую опять сначала:

А сначала вы выбираете (сами на основании своих знаний и отношения к ООП) метод, с помощью которого вы будете обеспечивать целостность данных. Далее обращаемся к моей классификации возможных способов работы с ООСУБД и уже в ней, с учетом сделанного выбора, определяем находимся ли мы ветке 1 или 2 . С методом 1 (триггеры и ХП) все понятно. А метод 2 ПРЕДПОЛАГАЕТ НАЛИЧИЕ СЕРВЕРА ПРИЛОЖЕНИЙ. Напоминаю - вы сами выбрали этот метод, и далее мы можем обсуждать только ТТХ предполагаемой системы, а не саму обоснованность присутствия в ней апп-сервера. Очевидно, что системы со встроенным апп-сервером (GemStone) будут иметь несколько другие ТТХ, по сравнению с системами, построенными на базе апп-сервера стороннего поставщика (например, IIS+FastObjects .NET или JBoss+VOA JDO+VDS или ...).

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

Я же могу рассказать вам об особенностях работы с конкретными конфигурациями и рекомендовать некоторые из них, как наиболее удобные в тех, либо иных условиях.
4 апр 05, 15:15    [1439286]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
tygra
Вебсервис - сам по себе является клиентом СУБД. Хоть так поверните, хоть эдак. Значит все-равно данные, их целостность и бизнес-логика зависят от клиента. От одного, от десяти - не важно.

Не обязательно :) Есть СУБД, у которых собственная поддержка веб-сервисов, где код веб-сервиса ничем не отличается от хранимой процедуры. Таким образом никаких лишних слоев и серверов приложений, вся логика контролируется самой СУБД, СУБД может отдавать данные в HTML/XML, вызывать через SOAP удаленные ХП других СУБД/серверов приложений и зашаривать через SOAP свои ХП для вызова их удаленными СУБД или клиентами. Естественно для ADO.NET сразу же сделана поддержка через SOAP передачи и приема DataSet, раз уж эта технология настолько перспективна теперь. В итоге СУБД автономна и спокойно может брать данные с интернета и отдавать их клиентам/другим СУБД/браузеру через HTML, контролируя как обычно целостность, логику и позволяя клиентам работать как через протоколы доступа к данным посредством ХП, так и их оберткам в виде веб-сервисов через тот же 80-ый порт.
4 апр 05, 15:41    [1439443]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


Так откуда там ("внутри СУБД") взялась поддержка веб-сервисов? А просто взяли и ВСТРОИЛИ веб-сервер в состав СУБД! А зачем? А просто так удобнее осуществлять развертывание и сопровождение системы - все устанавливается и настраивается для совместной работы одним инсталлятором в одном месте за один проход. Точно также и администрирование осуществляется с единой консоли. Если же веб-сервер не интегрирован в состав СУБД (или интегрирован плохо), то работа у администраторов усложняется. Вот и вся разница. Ах да - "встроенный" сервер обладает ограниченной функциональностью, но никакой функциональности, отсутствующей у его "внешнего" собрата у "встроенного" сервера нет.
4 апр 05, 16:08    [1439594]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
2 ASCRUS
Да, есть такие. Кстати, там код вебсервиса - sql или чего другое? И доступ прямо из кода к БД? Ну в общем - как ХП?
Или может это просто встроенный вебсервер, который живет внутри, а не снаружи?

2 Alexey Rovdo
автор
Вы знаете, tygra, ваша позиция меня все время напрягает просто потому, что вы регулярно сами себе противоречите. Мы долго обсуждали вопрос того, зачем я приплел апп-сервера. Вроде даже пришли к пониманию
...
После этого вы снова начинаете гнать волну по новому кругу - я же по новому кругу объяснять. Ну что же попробую опять сначала:

Где же там понимание? Было сказано, апп-сервера похожи на ХП. Однако не было сказано, что это одно и тоже да еще в смысле всей СУБД :)
автор
А сначала вы выбираете (сами на основании своих знаний и отношения к ООП) метод, с помощью которого вы будете обеспечивать целостность данных. Далее обращаемся к моей классификации возможных способов работы с ООСУБД и уже в ней, с учетом сделанного выбора, определяем находимся ли мы ветке 1 или 2 . С методом 1 (триггеры и ХП) все понятно. А метод 2 ПРЕДПОЛАГАЕТ НАЛИЧИЕ СЕРВЕРА ПРИЛОЖЕНИЙ. Напоминаю - вы сами выбрали этот метод, и далее мы можем обсуждать только ТТХ предполагаемой системы, а не саму обоснованность присутствия в ней апп-сервера. Очевидно, что системы со встроенным апп-сервером (GemStone) будут иметь несколько другие ТТХ, по сравнению с системами, построенными на базе апп-сервера стороннего поставщика (например, IIS+FastObjects .NET или JBoss+VOA JDO+VDS или ...).

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

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

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

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

Я что-то уже забыл - мы какой вопрос обсуждаем?
Не пора ли опубликовать список вопросов? А то так никогда эта песня не закончится :))

-- Tygra's --
4 апр 05, 16:15    [1439635]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

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

1. Версант - это "якобы объектное хранилище".


Мне просто интересно: какое из требований к объектному хранилищу не выполняется Versant'ом?


Я фигею, неужели сложно даже прочесть следуещее предложение?
Смотри ниже.

Dimonische

1. Версант - это "якобы объектное хранилище". Методы объектов не выполняются и не хранятся. Хранятся только данные (структуры данных).


Методы объектов не выполняются и не хранятся. Что не ясно?
4 апр 05, 18:45    [1439872]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

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

То что в ER-модель были попытки описать манипулирование, я где-то слышал. Ограничения целостности там есть.
Согласно литре, однако, ER-модель - модель данных. И не просто одна из 300 или скольки известных, но, попавшая в список наиболее популярных. Почти в каждой книге по БД про нее есть. Видимо, по тем причинам, что Вы назвали. Да и пользы исключать ее из моделей данных, скорее всего, мало. В самом, деле, а что же ER тогда, если не модель данных? Ничем другим кроме модеирования данных она ведь не занимается.
Модель данных состоит из трех компонентов, скорее всего в смысле может состоять, а не обязана состоять. Просто четвертой компоненты пока нет, а меньше трех - проигрышь по отсутствующей компоненте той МД, у которой эта комонента есть. Но может быть выигрышь в другой. Например, достоинства ER в плане структурирования Вы сами здесь привели.
Ну все модели данных предназначены для моделирования ПО. А чего же еще? и РМД и ОМД.
Просто мы немножко по разному с Вами смотрим на это. У нас даже была дискуссия. Но она уводила от темы данного топика.
Я помню, что Вы Концептуальную модель не считали моделью данных, а считал. И мне кажется до сих пор, что так лучше - замкнутый подход: есть модели данных разные и мы их сравниваем. И понимаем где находимся. А так что получится? Не единообразный подход. Тут модель данных, а тут что-то другое. Что это дает в уплату за утерю единообразия?
4 апр 05, 18:58    [1439906]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

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


... Много поскипанного бреда :)

-- Tygra's --


Tygra, ну уже 150 раз сказали:

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

Т.е:
1. Можем написать хранимки на языке Версанта. Будет более независимо, если вдруг вицепрезидент ИТ скажет - дайте дотнет команде доступ к базе или я всех уволю. Тогда проблем нет, у нас все внутри версанта

2. Можем на аппсервере написать уровень поверх Версанта с проверкой целостности, где будут вызываться методы объектов.

Что не ясно?
4 апр 05, 18:58    [1439907]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
BaZa
Guest
Dimonische
BaZa
Dimonische

1. Версант - это "якобы объектное хранилище".


Мне просто интересно: какое из требований к объектному хранилищу не выполняется Versant'ом?


Я фигею, неужели сложно даже прочесть следуещее предложение?
Смотри ниже.

Dimonische

1. Версант - это "якобы объектное хранилище". Методы объектов не выполняются и не хранятся. Хранятся только данные (структуры данных).


Методы объектов не выполняются и не хранятся. Что не ясно?


"Объектность" базы — это логика построения хранилища, а не хранение/не хранение методов.
4 апр 05, 19:01    [1439914]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

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

"Объектность" базы — это логика построения хранилища, а не хранение/не хранение методов.


Нет никакой мистической объкетной логики. Все просто

Есть полям разных типов, есть массивы полей, есть ссылки на другие объекты, есть массивы ссылок. Все. нет больше ничего.
4 апр 05, 19:05    [1439931]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

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

"Объектность" базы — это логика построения хранилища, а не хранение/не хранение методов.


Нет никакой мистической объектной логики. Все просто

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

(сорри за ошибки)
4 апр 05, 19:11    [1439945]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
BaZa
Guest
Dimonische
Нет никакой мистической объкетной логики. Все просто

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


ну что тут непонятного? суть в том, как ОРГАНИЗОВАНО хранение (можно даже сказать на физическом уровне), а не в том, что именно сохранияется. народ платит Oracle/IBM/... не за то, что они реляционные, а за то, как у них организовано хранение данных. (не за теорию, а за практику)
4 апр 05, 19:13    [1439947]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
tygra
Да, есть такие. Кстати, там код вебсервиса - sql или чего другое? И доступ прямо из кода к БД? Ну в общем - как ХП?
Или может это просто встроенный вебсервер, который живет внутри, а не снаружи?

Естественно там SQL, было бы странно в этой РСУБД увидеть что то еще, ну разве что окромя поддержки хранения обьектов и процедур Java, которые уже заявленны как depricated, так как не прижились :) И SOAP процедуры на внешние источники данных описываются как "CREATE PROCEDURE (Params)... URL ... TYPE ... " и вызываются дальше через обычный EXECUTE/CALL, как будто бы это внутренняя или прокси хранимая процедура в БД. А то, что веб-сервисы могут генерить возврат данных в виде XML для ADO.NET (DataSet), вообще позволяет приложениям VS.NET работать с ней посредством SOAP, без каких либо провайдеров данных.

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

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

P.S. Никто не говорит, что на базе веб-сервисов РСУБД нужно делать сайты, хотя для интранет-сайтов выглядит быстро и красиво - запустил БД и больше ничего не надо :) Но вот как раз для ситуаций работы в связке с серварами приложений как раз самое оно получается - толстый сервер, тонкий клиент - БД отвечает за хранение и обработку данных, сервер приложения за организацию интерфейса и прием/передачу информации c еще более тонкими клиентами :)
4 апр 05, 20:10    [1440027]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Вдогонку:
это ASA висит в инете (ребята прикалывались):
http://support.rs-erc.ru/

Это веб-сервис, который обслуживает ссылку:
CREATE SERVICE "root" 
  TYPE 'RAW' 
  AUTHORIZATION OFF 
  USER "DBA" 
AS 
  select * 
  from test2(0);
Он получает HTTP контент с процедуры "test2". Она в свою очередь обращается напрямую в веб-сервису Центробанка, зарегистрированному как SOAP ХП, для получения текущего курса валюты и собирает полученный набор данных в виде HTML таблички (пример обращения с WatcomSQL к внешним веб-сервисам и пребразованию XML в набор данных выложен в FAQ Sybase).

Все удобно, наглядно, мало кода и не понятно, что еще для жизни нужно :)
4 апр 05, 20:22    [1440043]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
1. В некоторых монографиях и статьях про РМД можно встретить примерно следующее высказывание: "мы не будем изучать вопрос - все ли аспекты реальности могут быть представлены в реляционной базе данных...". Это оказалось хорошей "зацепкой" для спекуляций на тему "множества задач, которые не могут эффективно решаться в рамках реляционной технологии".
Если концепция (многопользовательской) базы данных должна использоваться для решения задачи, то не существует задачи, которая не может быть решена в рамках реляционной БД (и, тем более, в среде "реляционной" СУБД).
А "эффективность" - слишком скользкая субстанция, чтобы обсуждать ее в такой форме, и с такими знаниями.
Я уже говорил, что нормализация (как и "разумная" денормализация) - это объективная необходимость для любой технологии баз данных (любой модели данных). U-gene написал примерно так: "зачем Вы это пишите, я не знаю, но это так". А пишу я это, потому что нет в ООСУБД никакого "более" естественного" хранения "объектов". А есть всего лишь банальная денормализация. Подогнанная под так называемые "пользовательские" типы ("классический" пример: "Адрес").

2. Хорошо, что начали "строго припадать к первоисточникам". Но надо знать, что "модель Чена" (только с нормальной идентификацией и навигацией, и без "реляционных перекосов", бессмысленных для семантического моделирования) использовалась даже раньше статьи Чена. ОМД начали использовать с 1969 года. Когда Alexey_Rovdo пишет, что "ОМД не было в 1980 году", он, видимо, имеет в виду, что не нашел упоминание об ОМД в книгах, напечатанных до 1980 года. Такую же "технологию толстых книг" для изучения и понимания теории и практики баз данных применяет и vadiminfo.

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

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

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

6. "Заслуга" "постреляционных" ООСУБД - использование дореляционной идентификации и навигации. Даже до нормальной семантики в соответствии с "моделью Чена" добраться не удалось - связи многие-ко-многим с характеристиками (свойствами) связи не поддерживаются, а у Чена они "очень важны"...
4 апр 05, 21:48    [1440129]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

В том и прикол - вы ищете смысл в самом названии, а я ищу разницу в выполняемых функциях.

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

Функции мы выше уже много раз обсудили. Формат предлагаемого соглашения тоже.

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

Alexey Rovdo

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

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

Alexey Rovdo

Что значит не переложили? Методы то объектам пишет разработчик ИС. Кто за него туда что-то может переложить? Не понимаю.

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

Alexey Rovdo

Все это философия. А действительно важного вопроса - что же конкретно именно вам кажется значимым - вы так и не раскрыли.

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

Alexey Rovdo

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

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

Alexey Rovdo

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

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

Alexey Rovdo

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

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

Alexey Rovdo

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


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

Alexey Rovdo

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

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

Alexey Rovdo

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

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

Alexey Rovdo

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

Тем более их следует оценивать по фундаментальным. Мы их и пытаемся обсуждать. Например, вот уже несколько дней говорим про ограничения целостности - часть МД - фундамент СУБД.
Это с точки зрения базиста. Я выше писал вам про две категории разработчиков. Вы говорили про проггерские детали. Правильно назвав их прикладными. Но разве не естественно стремление сначала оценить фундаментальное? Ведь прикладное завист от фундаментального.
Т.е. Вы думаете, что они углубились в названия, а я, например, думаю, что не в названия, а в фундаментальное, которое имеет свои названия.
4 апр 05, 23:47    [1440189]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Alexey Rovdo

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

Эти формальные причины - определение СУБД. Определения под рукой у меня нет, я ориентируюсь на функции, которые СУБД должна с необходимостью выполнять. Если не выполняет, то не СУБД. У Дейта они перечислены на на стр.39-40 стр (An Introduction to Database Systems, sixth edition, Addison-Wesley, 1995), со ссылкой на Кодда. Там под номером 3 идет data security and integrity. А у Кодда (Codd E.F., "Relational Database: A Practical Foundation for Productivity", Communications of the ACM 25, no.2) это правила 6 и 8. Связка СУБД+сервер-приложений не может обеспечить целостность данных, поскольку если СУБД исползуется только как хранилище, а вся логика и целостность обеспечивается сервером приложений, то я могу совершенно легально подключиться к СУБД с другого сервера приложений, который о целостности ничего не знает, и нарушить эту целостность. Поэтому такую связку в строгом смысле нельзя назвать СУБД. Если же целостность и логика хранится в СУБД, например в СКЛ сервере, то другим СКЛ сервером Вы уже не подключитесь.

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

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

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

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

>Мне проще всего проиллюстрировать это на примере FastObjects t7.
...


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

Нет ответа на первый вопрос: "c127>Вот меня и интересует, как могут храниться объекты в базе, которая ничего не знает об их происхождении т.е. хранение происходит универсальным образом, при том, что в одном случае (С++) это могут быть сложные вложенные объекты, а в другом (джава) - всегда только указатели на объекты. Их же нужно располагать на диске, резервировать место и т.д.".

Т.е. как оно хранится ВНУТРИ версанта? Детали не нужны, хотя бы идею.
5 апр 05, 05:18    [1440277]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

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

ну что тут непонятного? суть в том, как ОРГАНИЗОВАНО хранение (можно даже сказать на физическом уровне), а не в том, что именно сохранияется. народ платит Oracle/IBM/... не за то, что они реляционные, а за то, как у них организовано хранение данных. (не за теорию, а за практику)


Ага, то есть вы здесь спрашиваете как в объектных базах (в нашем случае в Версанте), реализовано на физическом уровне хранение данных.

В Версанте реализовано (я думаю что ) также как в иерархических/сетевых базах. Есть вопросы (у меня) как реализовано наследование + версионность в Версанте. Т.к. моя комапания не является крупным потребителем Версанта, доки из первых рук мне не доступны.
5 апр 05, 10:19    [1440691]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

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


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

Откуда:
Сообщений: 137
Андрей Леонидович

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


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

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

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

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

Я же говорил, что некоторые ограничения целостности в ОМД.
.... поскипано...

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


Vadiminfo, уже необнократно тут было сказано про хранимые процедуры и триггеры в Версанте. Что еще Вам нужно от целостности? Может хватит уже неделями зацикливаться на проблеме которой нет?
5 апр 05, 10:33    [1440773]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Dimonische
Т.к. моя комапания не является крупным потребителем Версанта, доки из первых рук мне не доступны.


Доки доступны всем!

Они входят в состав trial-версий продуктов, которые может скачать кто угодно на www.versant.com .

Доки и описания примеров по FastObjects можно также скачать на community.fastobjects.com .
5 апр 05, 10:48    [1440862]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Vadiminfo, уже необнократно тут было сказано про хранимые процедуры и триггеры в Версанте. Что еще Вам нужно от целостности? Может хватит уже неделями зацикливаться на проблеме которой нет?

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

-- Tygra's --
5 апр 05, 11:42    [1441101]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Alexey Rovdo
Dimonische
Т.к. моя комапания не является крупным потребителем Версанта, доки из первых рук мне не доступны.

Доки доступны всем!


Алексей, не страдайте как большинство людей не желанием слушать собеседников. Мы обсуждали "физическую организацию хранениия данных". Я ответил, что по этому поводу у меня доков нет. И их на сайте дествительно нет. Однако, если бы я представлял MinistryOfDefense, очевидно что мне бы предоставили даже доку по организации ядра + плюс его исходники.
5 апр 05, 11:45    [1441115]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

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

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

-- Tygra's --


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

То, что Алексею чего-то не хочется, ничего не значит.
5 апр 05, 11:48    [1441127]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 67 68 69 70 71 [72] 73 74 75 76 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить