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

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

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


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

самопал

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


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


А почему нельзя называть такую встроенную СУБД просто Persistent Object Storage?
31 мар 05, 11:52    [1429397]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
самопал
А почему нельзя называть такую встроенную СУБД просто Persistent Object Storage?
Так это он и есть в конечном итоге!
31 мар 05, 11:55    [1429415]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Называть то можно как душе угодно.
Важно только то, какой смысл мы вкладываем в те или иные понятия.
31 мар 05, 12:02    [1429463]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
Alexey Rovdo
Называть то можно как душе угодно.
Важно только то, какой смысл мы вкладываем в те или иные понятия.
О том и речь. В понятие СУБД много что вкладывается, и когда Вы приходите и говорите "А вот посмотрите какую супер-пупер навороченно-объектно-ориентированную СУБД мы делаем!" у всех тут же появляются вопросы. А потом оказывается, что это объектный апп-сервер с хранилищем унутре. Но снаружи ооочень на СУБД похоже. Люди разочаровываются...
31 мар 05, 12:09    [1429502]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

Откуда:
Сообщений: 137
самопал
2 Dimonische:
мне просто трудно представить, что существуют такие объектные модели, корректное состояние которых в любой момент времени можно обеспечить, не вызывая методы объектов модели.
Поскольку объектная модель для базы одна, то и вызываемый разными клиентами код методов должен быть тем же.


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

Вот эти методы назовем ХП и трегерами и запихнем в базу. Напишем на собственном языке базы и не паримся какой у нас клиент.

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


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

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


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

А давайте попробуем сформулировать требования к такому Persistent Object Storage. Посмотрим что получится.

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

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


Павел, просто попутно мы еще аппсерверы проповедуем ) Так что вам просто показалось "что это объектный апп-сервер с хранилищем внутре". Последнее верно для Gemstone
31 мар 05, 12:27    [1429598]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

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

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

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

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

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

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

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

Я упомянул уже приложение по хранению статических данных. Да, можно было бы предоставить всем клиентам доступ к Ораклу непосредственно. Но Наши клиенты этого не хотят. Потому что мы предоставляем доступ намного проще чем Оракл.[/quot]
Что проще доступа к БД может быть?
автор
Мы имеем функции специфичные для бизнесов, которые с нами общаются.

Я может ошибаюсь, но с программными комплексами, да еще через вебсервисы, общаются никак не "бизнесы", а по меньшей мере программисты.
автор
Фактически, мы реализовали Объектную Базу по предметной области без поддержки языка запросов. Клиенты не могут запускать SQL. Поверьте мне, если бы они хотели, я был бы просто вынужден его бы добавить.

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

Простой - это какой? Они что, имеют у себя одну кнопку, у вас есть один метод, который телепатически считывает из мозга подключившегося, что ему нужно, и выдает результат?
Какой отношение вообще имеют ХП и таблицы к доступу клиентов? Их не должно волновать, что у вас внутри - может вы на ассемблере пишете. Их волнует только результат и возможность его получить.
Вас не должно волновать, что там снаружи предоставляет доступ клиентам - вы организуете всю работу внутри, а уж как выдать конечный результат забота собственно не СУБД и бизнес-логики системы.
В итоге получается, что ваши клиенты тут не при чем - никто вас не заставлял использовать объекты для работы с БД и делать это на стороне апп-сервера. Вы могли с тем же успехом написать нужные ХП и дергать их из asp.net, который стоит на IIS.
Не вижу никаких причин для использования объектов и апп-серверов для их обработки.
Пример: наш магазин предоставляет доступ клиентов посредством вебсайта (что естественно), но также он предоставляет доступ через вебсервисы для получения информации о товарах, которую могут забирать все, кто хочет (и sql.ru в том числе), но также я сделал виндового клиента к нашему магазину, который дает возможность в человеческом режиме просматривать списки товаров, оформлять заказы и т.д. без лишней html-обвязки и т.п. Я не написал ничего вне СУБД для обеспечения логики работы всего этого - кроме обеспечения доступа клиентов. Такие разные клиенты используют одни и те же методы, если хотите, для предоставления информации без какого-либо ущерба и подгонки под конкретных клиентов. В случае апп-сервера я что, три раза должен был повторить один и тот же код для обеспечения единства бизнес-логики?

Устал уже. В окончание:
Alexey Rovdo
Хороший пример! Именно приняв соглашение о том, что ток течет от плюса к минусу мы вообще можем говорить о его направлении. Когда принимали это соглашение ничего не знали об электронах, которые как оказалось перемещаются от минуса к плюсу, но это вовсе не мешает проводить все вычисления в соответствии с уже принятым соглашением

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

Уффффффф....

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

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

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


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

Относительно цитаты, да, у меня именно один метод, к которому они подключаются и который выдает результат. Этот метод они попросии добавить, мы добавили.
31 мар 05, 13:04    [1429808]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

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

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

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

Кстати tygra вам не мешало бы просветиться на тему того, как собственно мы все мыслим. Оказывается, что в большинстве своем именно штампами - так уж человк устроен. Мыслить абстрактно очень тяжело, но иногда того стоит - попробуйте, может поймете.
31 мар 05, 13:18    [1429880]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

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

Моих коллег это сообщение заинтересовало. Не могли бы Вы привести название банков?



Alexey Rovdo

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

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



Alexey Rovdo

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

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

Alexey Rovdo

Про Versant я уже говорил - поддерживает.


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

Alexey Rovdo

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

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

Alexey Rovdo

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

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

Alexey Rovdo

"А что, если в одной БД придется прописывать ограничения целостности в нескольких триггерах"

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

Alexey Rovdo

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


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

Alexey Rovdo

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

Знаете, мы так далеко уйдем в философию - что есть мое Я, и что есть вне Меня. Нет никакого тока, а есть модель некая, которая хорошо согласутся с другми результатами. Нет никаких законов физики, а есть соглашения. На самом деле есть представления явлений. Про представления, мож кто и согласился до нас, как их лучше описывать. Но сами явления существуют, частно не обращая внимания на наши соглашения. Еще во времена Вейера - формулы в математики выглядели ужасно. Потом придумали лучшее, а по Вашему согласились. Для соглашений нужны разумные основания. И еще важно кто и в чем соглашается.
31 мар 05, 13:21    [1429892]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Дискуссия зашла в очередной тупик - и фиг с ней.



Ну что же, подведу некий итог в приложении к объектно-ориентированным СУБД Versant.

Являются ли эти продукты Persistent Object Storage в описанном выше понимании? Без сомнения являются!

Являются ли эти продукты СУБД? Ответ на этот вопрос требует четкого ответа на то, что-же такое СУБД. У сторонников разных систем могут быть на это разные взгляды. Но Versant - не исследовательская группа, а коммерческая фирма и ей нужно продавать свои продукты, а не заниматься исследованием разнообразных концепций. Поэтому понимая и идя навстречу сторонникам объектных систем, Versant подстраивается и под взгляды тех кто привык оценивать СУБД по их похожести на продукты MS и Oracle. Вас не устраивает Persistent Object Storage с поддержкой транзакций, конкурентного доступа, индексов и запросов - пожалуйста, вот вам хранимки, триггеры, SQL и прочее, к чему вы так привыкли (в рамках дополнительного к VDS модуля Versant SQL - все-таки это только для тех, кто считает такой и именно такой функционал обязательным для СУБД). С FastObjects ситуация похожая - там только весь функционал попроще.

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

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

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

Alexey Rovdo

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

Т.е. Вы считаете, что в рел модели данные сильно зависят от приложения? Иногда считают вообще, что Кодд, изобретал рел БД именно с целью добиться значительной независимости БД от приложения. И Вы думаете, что он не добился?


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


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

vadiminfo

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


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

Про реляционную понятно - РСУБД должна поддерживать РМД, определение РМД известно. Спору нет.

vadiminfo

Он появляется в трехуровневой клиент серверной архитектуре, а модель данных присутсвует не только кроме этого в двухуровневой, но и в файл-серверной сетевой технологии и даже вообще не в сетевой (В Досе).


Это не принципиально. В файл-серверном случае мы можем говорить о неком наборе библиотек, вместо приложений на апп-сервере.

vadiminfo

Alexey Rovdo

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

Но главное, чтобы поддерживала СУБД. Ведь мы им занимаемся?


Мне кажется, что с некоторой натяжкой можно произнести следующее:

ОМД (если понимать под этим нечто похожее на РМД) не влазит в ООСУБД. По крайней мере для того, чтобы удовлетворить всевозможные требования по обеспечению целостности ей нужен полноценный сервер приложений. Значит ли, что после этого мы должны переименовать ООСУБД во что-то другое? Или же мы сможем отнести к ООСУБД только продукты, в состав которых встроен свой сервер приложений (GemStone)? Но тогда, полагаю, при сравнении с другими продуктами мы в первую очередь упремся именно в недостатки этого конкретного встроенного сервера приложений.
31 мар 05, 14:08    [1430150]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
ох, лучше бы Вы этого не произносили...
31 мар 05, 14:29    [1430270]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Alexey Rovdo
Полагаю, в том числе и потому, что требования к "модели данных" (к самому этому понятию) еще не устоялись. Есть РМД, но значит ли, что все требования, которым удовлетворяет РМД мы должны распространить на все другие возможные модели? Вот и возникает проблема - СУБД должна поддерживать модель данных, а где эта модель, а что такое модель?

Дорогой Алексей. Буквально несколькими страницами ранее в этой теме шло довольно активное обсуждение понятия "модель данных". Вы книжки по теории БД хорошие не читали (коль не знаете, что это), так хоть в этом форуме прочтите. Определение Кодда есть, оно достаточно формальное. Ну ей-богу, рассуждаете о высоких материях, а фундаментальных вещей не знаете? Ведь этим вы подрываете всякое доверие к вашей квалификации именно как специалиста в области информационных систем.
31 мар 05, 14:36    [1430313]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Вот, специально для вас:
E. F. Codd, Data Models in Database Management, IBM Research Laboratory, 1980
[A data model] is a combination of three components:
• a collection of data structure[s]…
• a collection of operators or inferencing rules, which can be applied to any valid instances of the [pertinent structures] listed in 1, to retrieve or derive data from any parts of those structures in any combinations desired;
• a collection of general integrity constraints, which implicitly or explicitly define the set of consistent database states or changes of states, or both…
31 мар 05, 14:43    [1430350]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

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

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

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

Я про метод то писал почему - в любом случае придется разбираться.... Да ладно, фиг с ним со всем. :))
Главное, чтобы работало все у всех.

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

Откуда: Новосибирск
Сообщений: 2402
Блог
Главное, чтобы работало все у всех

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

Откуда: Москва
Сообщений: 913
mir
Вот, специально для вас:
E. F. Codd, Data Models in Database Management, IBM Research Laboratory, 1980
[A data model] is a combination of three components:
• a collection of data structure[s]…
• a collection of operators or inferencing rules, which can be applied to any valid instances of the [pertinent structures] listed in 1, to retrieve or derive data from any parts of those structures in any combinations desired;
• a collection of general integrity constraints, which implicitly or explicitly define the set of consistent database states or changes of states, or both…


Замечательное определение РЕЛЯЦИОННОЙ МОДЕЛИ ДАННЫХ. Было доработано и уточнено Дейтом (вернее он предложил свою более подробную трактовку этого определения).

Еще пара цитат:

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


Even a cursory inspection of data management practice reveals that the majority of practitioners-–be they novices, or experienced, users or vendors--operate in a “cookbook”, product-specific mode, without really knowing and understanding the fundamental concepts and principles underlying their field, e.g. what data means, what data model, database, DBMS, data independence really are, and so on.
This is not entirely their fault: neither does the industry require, nor does the educational system provide an education—as distinct from product training—in data fundamentals, which are ignored, distorted, or incorrectly dismissed in daily practice as “just theory” and, therefore, without practical value.
The consequences are very costly: the IT industry operates like the fashion industry, because uninformed practitioners are unable to see through the so-called “paradigms” and “models” and the ensuing technologies and products (read: fads) proliferated by marketeers, “experts” and the trade press, who suffer from an equal lack of knowledge. The problem is so acute that, claims of progress notwithstanding, technology is actually regressing!

(с) C.J.Date
31 мар 05, 15:46    [1430716]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
serg99
Member

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


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

Alexey Rovdo
А СУБД это приложение? А если клиентсокое приложение пользуется услугами по хранению и манипуляции данными, предоставляемыми другим приложением, можем ли мы это приложение отнести к СУБД? Где заканчивается приложение и начинается СУБД, если они сконфигурированы для работы в паре и только так?
Любое приложение БД изначально сконфигурировано для работы в паре с СУБД. Отличие СУБД состоит в том что она ничем кроме обслуживания подсистемы хранения долговременных данных не занимается и может одновременно обслуживать несколько приложений использующих общие данные. Есть еще ряд требований к тому что обычно называют СУБД (целостность и т.д. и т.п.). Хранение данных само по себе не решает какую либо прикладную задачу оно обслуживает решение прикладных задач такими приложениями как Бухучет, Архитектурноге проектирование и т.п. Обслуживающую роль играют и те средства манипуляции данными которые могут быть встроены в СУБД и которые работают как правило в рамках одной транзакции. Прикладная задача это достижение определенных целей в той или иной сфере ЧЕЛОВЕЧЕСКОЙ деятельности. Соответственно приложение обеспечивает взаимодействие с пользователем, реализуя прикладную логику и помогая решить функционально полную прикладную задачу. Деление приложение-СУБД это собственно функционально -логическое деление, которое насколько я понимаю достаточно распространенное в профессиональной среде и подразумевающее в том числе изолированность/независимость СУБД от приложений. Почему собственно некоторые из участников дискуссии отказываются вообще рассматривать Версант как СУБД думая что в нем модель данных предметной области разделена между хранилищем и приложением, которые к тому же сильно друг от друга зависят. Такую систему можно например рассматривать как приложение с удаленным хранилищем. Но мне бы не хотелось влезать в терминологические споры, я просто высказываю свое мнение. Для системного программиста например все что запускается из EXE файла является приложением. А в некоторых ОС и драйвер "мыши" запускается из EXE файла.

Я бы Вам посоветовал вместо того что бы утверждать что в СУБД встроен некий сервер приложений, что многих вводит просто в ступор, рассказать о том есть ли в СУБД независимый от приложения запросный язык и есть ли в СУБД средства динамического контроля целостности/согласованности данных (к примеру аналоги триггеров), которые АВТОМАТИЧЕСКИ отрабатываютя при изменении данных в БД, одинаковы для РАЗНЫХ приложений и которые НЕВОЗМОЖНО обойти ни изменением существующего приложения(или апп сервера) ни созданием нового приложения(апп-сервера).

Alexey Rovdo
serg99

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


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

Если Вы опять про «соглашения», то их действенность определяется пролетарской сознательностью ПРИКЛАДНОГО программиста. Если Вы готовы ставить целостность и непротиворечивость модели данных предметной области в зависимость от того будут ли все прикладные программисты выполнять соглашения, то с точки зрения анализа надежности системы в целом появляется трудно учитываемый фактор связанный даже не столько с возможностью вредительства, сколько просто с увеличением вероятности человеческой ошибки.

Alexey Rovdo
serg99

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


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

Мешает принципиальная разница в выполняемых функциях между апп-сервером и СУБД.

Alexey Rovdo
serg99

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


Для кого-то может быть BIOS - это черный ящик, который "имеет цельность" , "независим от платы" и т.п. Но уверяю вас, и туда можно записать все что душе угодно. Просто мы приняли соглашение этого не делать.
У Вас немного странная логика. Я говорю о логических взаимосвязях понятий. Оттого что и ХП и приложение можно изменить совсем не следует что это эквивалентные понятия. Как скажем из того что я могу изменить и библиотечную функцию Printf и само приложение ее использующее, совсем не следует, что функция printf – это то же приложение.

Alexey Rovdo
serg99

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


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

Alexey Rovdo
serg99

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


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

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

Alexey Rovdo
serg99

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


Я уже говорил, что это вопрос дискутируемый. Но вот вам пример: как декларативно ограничить диапазон значений объектов класса, если в разных его подклассах-наследниках операторы <, > переопределяются?
Вы сами говорили что в Версанте хранятся значения атрибутов объектов. Что тогда такое «значение объектов»? Кроме того я не стал бы смешивать объектный подход к программированию (ООП) и объектный подход к хранению данных. Это разные вещи.


Alexey Rovdo
serg99

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


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

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

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


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

serg99

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


serg99

то их действенность определяется пролетарской сознательностью ПРИКЛАДНОГО программиста. Если Вы готовы ставить целостность и непротиворечивость модели данных предметной области в зависимость от того будут ли все прикладные программисты выполнять соглашения, то ...


Во ВСЕХ ситуациях такая зависимость существует.

serg99

Оттого что и ХП и приложение можно изменить совсем не следует что это эквивалентные понятия.


Как понятия и термины приложения и ХП конечно НЕЭКВИВАЛЕНТНЫ. Об их отличиях вы много сказали. И я с вами согласен. Я же смотрю на конкретные реализации. Например, ХП в составе MS SQL и "внешняя" программа, выполняющая ТЕ ЖЕ функции в связке с MySQL (при следовании описанным мною выше соглашениям) эквивалентны?

serg99

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


Вижу отличие от формального описания ХП только в словах "с помощью коннектов". Сразу возникает вопрос. А как доступ к данным получают ХП? И чем это принципиально (функционально) отличается от "коннектов"?

serg99

Кроме того я не стал бы смешивать объектный подход к программированию (ООП) и объектный подход к хранению данных. Это разные вещи.


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

serg99

Ваша позиция понятна – продать Версанта побольше.


Разговор уже давно вышел за рамки продажи Versant. Я могу вам продать любую СУБД - милости прошу на www.softkey.ru (даже те продукты, которые в каталоге отсутствуют мы тоже продаем). В конце-концов на Versant свет клином не сошелся - просто из существующих сегодня объектно-ориентированных систем хранения именно Versant предлагает наиболее надежные и функционально полные решения. Но, к слову, очень рекомендую обращаться к нам за лицензиями на Oracle и MS SQL. Ценовая политика гибкая.
31 мар 05, 16:33    [1430973]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Alexey Rovdo
Замечательное определение РЕЛЯЦИОННОЙ МОДЕЛИ ДАННЫХ.
Да с чего бы? Может, там упоминаются "отношения"? Реляционная алгебра? Это определение модели данных. Реляционная модель данных определяется там отдельно. Цитату Кузнецова перечитайте еще раз. Он прямо говорит "понятие модели данных является общим". А "наиболее эффективно используется" как раз говорит что другие "модели данных" вообще мало использются. Это просто медицинский факт.
Вы такой упорный в своих заблуждениях, прям страшно. За вас.

За цитату из Дейта спасибо в том смысле, что она говорит, что вы не безнадежны, ибо Дейта читаете. Мы-то здесь таких отличных цитат Дейта и Паскаля можем много привести. Хотя цитата практически ставит вам диагноз. Ведь они оба однозначно высказываются насчет ООБД и их адептов. Ох, однозначно.
Забавно, но вы, оппонируя мне, привели 2 цитаты, обе из которых характеризуют вашу точку зрения не лучшим образом. Правда, смешно.
31 мар 05, 16:35    [1430981]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Забавно, но вы, оппонируя мне, привели 2 цитаты, обе из которых характеризуют вашу точку зрения не лучшим образом. Правда, смешно.


Забавно то, что вы считаете будто я оппонирую Дейту и Кодду (и вам) и имею что-то против существующих формальных определений. Но к самим формальным определениям у меня нет никаких претензий (разве только фактическое отсутствие надлежащего формализма для ОМД, разумеется, напрягает).

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

И именно об этом, кстати, и говорит Дейт.
31 мар 05, 16:47    [1431055]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 64 65 66 67 68 [69] 70 71 72 73 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить