Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 56 57 58 59 60 [61] 62 63 64 65 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Первые предпочитают смотреть на БД, как на ядро информационной системы.
В БД могут быть интегрированы данные, например, всего предприятия. Данные храниятся вместе с информационной моделью - т.е. они, как Вы выразились самодостаточны. Т.е. в БД все есть, чтобы получить информацию, необходимую для принятия решения. Эта модель обеспечивает наиобльший уровень абстракции. Приложения, могут обеспечивать представления данных для разных пользователей. Они обеспечивают меньший уровень абстракции.
Это связано с пользой от независимости данных от приложений. Это польза осознана была достаточно давно и выражена, например, в трехуровневой архитектуре ANSI-SPARCS 1975.


Вы зря противопоставляете ANSI SPARC тому что я говорил об объектных СУБД. Информационные модели, предложенные в 70-х (концептуальная, логическая, физическая), не противоречат объектному подходу. Просто целью всего процесса моделирования здесь являются четкие спецификации классов, а уровни абстракции остаются теми же.

В 1989 году в ANSI была создана специальная группа X3/SPARC/DBSSG Object-Oriented Database Task Group по проблемам стандартизации объектных хранилищ данных. Ее финальный отчет вышел в 1991 и представляет собой довольно интересный документ, охватывающий множество вопросов. Многие из этих вопросов и принципов впоследствии стали главной темой обсуждений ODMG, образованного как раз в 1991. Как известно, взгляды ODMG и ANSI на развитие объектных систем впоследствии несколько разошлись (ANSI пыталась инкорпорировать объектные функции в стандарт SQL3, а ODMG предлагала альтернативные решения в рамках своих спецификаций). Но в далеком 1991 таких явных противоречий еще не наблюдалось и хотя никаких четких спецификаций на объектные системы не существовало, взгляд на то какими эти системы и спецификации могут быть, был вполне четким и во многом отражает их нынешнее состояние. Приведу, например, небольшую выдержку именно по части моделирования (раздел 3.4):

In the entire information modeling community, there is an increasing emphasis on
‘‘object-oriented’’ planning, requirements specification, analysis, design, and enterprise modeling.
In the context of an ODM system, object-oriented information modeling consists of analyzing an enterprise and its information management problems to produce a specification of classes at appropriate levels of detail. Thus the information modeler is identifying and designing classes. These classes are not usually specified in terms of detailed Object Language statements of the ODM; but a class defined at a conceptual level by an information modeler should have a direct mapping to one or more class definitions written by the application developer, class definer and/or database designer. In the course of defining classes, the information modeler and application developer take into account classes that already exist.
The use of classes at different stages in the development process of information-intensive systems is expected to lead to more information reuse, allow for more uniformity in development methodologies used at different stages of the development process, and make the boundary between information modeling and application development less distinct.
...
Under previous database paradigms, users of database systems might play one or more of the following roles. These same roles exist in the ODM paradigm:
• End user — accesses information directly through ad-hoc query interfaces, and indirectly through turn-key programs.
• Application developer — builds end-user applications.
• Information or data modeler, system analyst — identifies classes and analyzes operations of the application; performs tasks such as auditing, reporting, forecasting, and planning.
• System installer or database administrator — performs system administration functions such as installation, backup, tuning, system maintenance, etc.
• System developer or maintainer — implements system internals.

In addition, the ODM paradigm brings with it some new roles:
• Class designer 19 — specifies public class and method interfaces.
• Method programmer — implements methods.
• Class library developer or vendor — develops and/or maintains class libraries.

Since in ODM systems, both system and application objects may be defined as classes, these latter user roles cut across the traditional roles yielding roles like:
• ODM systems programmer — implements kernel objects; writes primitive methods
such as access methods.
• Application method programmer — implements methods defining the operations of
an application.

The taxonomy above is only representative since other user roles can be distinguished. For instance:
• Domain class designer — works with application communities like Mechanical CAD
and Electrical CAD to define common object descriptions (e.g. PDES/STEP).
• Information modeler — works within an enterprise to develop conceptual classes that can provide a common model of the organization.
• Class librarian — maintains a data dictionary of class libraries.

A loose association between user roles and a layered organization of class libraries may be made. System designers implement ODM system kernel classes; domain or enterprise class developers develop widely useful classes; application programmers build on these to implement derived classes; and end users create or modify instances of classes through some end-user interface. This leads to a view of an ODM system as a layered system, where each layer corresponds to one or more class libraries built by one or more kinds of user. In such a system, system administration functions, for example, are not viewed as a fundamentally different set of functions and interfaces, but rather as just one of many class libraries containing specializations of functionality from a more general purpose class
library.


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

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

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

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

Я не стану утверждать, что объектно-ориентированный подход к проектированию систем и обработка данных в приложениях, написанных на ОО-языках, лучше, чем описанный выше и обычно практикуемый стиль работы с реляционными системами. Но надо понимать, что это именно разные стили проектирования и построения систем, преимущества и недостатки которых могут в разных ситуациях проявляться по разному.
28 мар 05, 11:45    [1419060]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Ошибаетесь, vadiminfo. Я ничего в "эту тему" не собираюсь "притащить". Я только обращаю внимание на очевидный факт: три (!) года на одном месте, господа ! И объясняю почему это происходит. Только и всего...
И почему Вы и Ваши коллеги "выбрали эту тему" для меня теперь уже загадка. Если знаний не хватает (причем катастрофически не хватает), могли бы начать с чего-нибудь по-проще (хотя для профессионалов "эта тема" очень проста)...
28 мар 05, 13:56    [1419583]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Недоучка
Guest
c127
...Я уже говорил, что В ПОЛЬЗОВАТЕЛЬСКОМ ПРИЛОЖЕНИИ И В ООБД ОБЪЕКТЫ РАЗНЫЕ.


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

c127
В приложении это объекты пользователького интерфейса, в конечном счете все к ним сводится, а в БД это объекты бизнес логики. В ГУИ это экранные формы, а в БД это, например, накладные, товары, скидки, проплаты и пр. Поэтому отображение строить нужно будет всегда, и еще неизвестно что легче объекты отобразить в структуру реляционных данных или же одни объекты отобразить в другие.


А если в моей программе (клиентской части) есть классы invoce, pay_order и т.п. следует ли понимать, что они - часть GUI?

Здается мне, что таракановыводитель для головы Вам не помешает...
28 мар 05, 14:08    [1419636]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Alexey Rovdo

Но такие приложения не являются полноценными ОО-программами и не манипулируют объектами как таковыми


Для того, чтобы быть ОО-приложениями достаточно реализовывать ОО - парадигму программирования. Любая прога на JAVA - будет ОО - приложением.



Нет - это не так. Само по себе использование Java (а тем более C++) не является достаточным для того, чтобы говорить об объектно-ориентированном стиле программирования. Никто не мешает писать на Java программы в процедурно/функционально-ориентированном стиле. Java, хотя и является ОО-языком, но достаточно многогранен. Он, конечно, стимулирует переход на ОО, но не выставляет жестоких рамок. В этом смысле более требовательны такие языки как Smalltalk, Oberon и конечно Eiffel (кстати по отличиям самих этих языков хорошо видно и то, что ОО можно понимать по разному и предъявлять разные критерии при отборе "истинных" ОО-программ).

Так что ваше утверждение "Любая прога на JAVA - будет ОО - приложением" ошибочно в корне.

Но мне действительно не хотелось бы переводить дискуссию в русло обсуждения терминологии и возвращаться к долгому выяснению того, кто и что понимает под термином "объект". С другой стороны, я понимаю, что моя трактовка ОО-приложения тоже требует пояснения, хотя бы для того, чтобы мы понимали о чем идет речь. Хотелось бы для начала адресовать вас к моим более ранним пояснениям , в которых я вполне четко описал отличия "настоящих объектов" в моем понимании от "суррогатных контейнеров", внутри которых данные представлены в реляционной форме.
28 мар 05, 14:19    [1419698]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
[оффтопик]
Друзья! Только ради аллаха не отвечайте ничего Андрею Леонидовичу. Я вот сделал это недавно, да меня добрые люди с форума приватно образумили. Это ведь чистая клиника. Надо его просто не замечать, может он и сойдет на нет.
28 мар 05, 15:00    [1419927]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Ребят, с127, vadiminfo.

Мы тут постоянно парим друг другу мозги просто потому что смотрим с разных позиций.

Например, для меня сначала проектировать Базу а потом приложение - полный бред. Я 100 раз сталкивался с тем, что процессы постоянно уточняются с клиентом и после 1 года работы, база выглядит совершенно не так как в начале, и, главное, надо быть богом, чтобы её написать так изначально.

Относительно Versant Open Access.
Кто-то из вас говорил, что не может поверить, что эта штука может работать - одинаково и с реляционными и нереляционными системами.

Ребят, это Ява - стандарт JDO (http://jcp.org/en/jsr/detail?id=12 - JDO 1.x,
http://jcp.org/en/jsr/detail?id=243 - JDO 2.0)

Только человек, который варится в Яве может вам сказать, что да, таки может эта штука работать. Как доказать басистам, вам, это я не знаю.
28 мар 05, 15:18    [1420021]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
Dimonische
Например, для меня сначала проектировать Базу а потом приложение - полный бред. Я 100 раз сталкивался с тем, что процессы постоянно уточняются с клиентом и после 1 года работы, база выглядит совершенно не так как в начале, и, главное, надо быть богом, чтобы её написать так изначально.
Вы нам льстите. А я вот за 10 лет работы наоборот убедился, что проектировать базу потом - полный бред. И изменчивость требований заказчика тут не при чём. Но мы действительно смотрим на предмет с разных сторон - тут Вы полностью правы. И точка расхождения - это именно трактовка базы данных (либо как "персистентного хранилища", либо как базиса, основы информационной системы).
28 мар 05, 15:32    [1420085]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
To Dimonische

Кстати, не могли бы Вы в соседней ветке прокомментировать свои ОО селекты?
28 мар 05, 15:36    [1420114]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 Alexey Rovdo
Что касается ANSI SPARC, то сам его стандарт не нашел явного применения. Но фундаментальное положение о независимости данных нашло. Я его привел в подтверждение осознанности именно этого факта. Поскольку Вы ставили под сомнение полезность независимости.



Alexey Rovdo

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


Так и я про то же Вам и говорил. Это и должно обеспечить независимость данных.

Alexey Rovdo

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



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


Alexey Rovdo

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

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


Alexey Rovdo

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

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

Alexey Rovdo

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

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

Alexey Rovdo

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

Из литры, что есть у меня, я вижу, что ОО - подход такой же. Есть ООМД. Ее проектируют и обеспечивает это ООСУБД. Вся модель в БД. Если нет, то это недостаток ИС в общем случае. Даже если есть сервер приложений. Даже если есть какие-то истинные объекты в приложении с истинной навигацией. модель данных должна быть в БД. Это всегда лучше. Иначе зависмость данных от приложения. А этот недостаток может перевесить много других достоинств вместе взятых.
28 мар 05, 15:41    [1420141]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
2 vadiminfo
Мои комплименты. Последний ваш пост почти повторяет мои мысли.
28 мар 05, 16:13    [1420278]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Поскольку Вы ставили под сомнение полезность независимости.
...
Так и я про то же Вам и говорил. Это и должно обеспечить независимость данных.
...


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

vadiminfo

Ну что мы с Вами будем уличать кого-то там в распространных ошибках?


Не принимайте на свой счет. Мне как раз кажется, что у нас с вами получилось очень содержательное обсуждение. :-)))

vadiminfo

Ну приложение всегда имеет отношение к обработке данных. Иначе, например, как данные вообще попадут в БД? Даже запросы, не говоря уже о ХП вызываются тока из приложений. Откуда еще?


Представьте себе, некоторые DBA на этом форуме уверены, что данные можно ОБРАБАТЫВАТЬ средствами СУБД.

vadiminfo

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


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

vadiminfo

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


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

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

vadiminfo

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


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

vadiminfo

Т.е. обеспечивать манипулирование данными - тоже относится к модели данных. А модель данных должна быть в БД.


Поясните ???

vadiminfo

Их отсутствтвие может противоречить стандартам SQL3.
Без них модель может оказаться не совсем самодостаточна, так как чаcть модели переместится в приложение.
Поэтому Ваше предположение слишком сильное.


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

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

vadiminfo

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


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

vadiminfo

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


Я все-таки считаю, что в известных мне ООСУБД данные не зависят от приложения. Просто мы обычно обсуждаем простые случаи, когда модель данных и модель приложения совпадают (и к этому всегда нужно стремиться). Но, разумеется, могут быть и более общие ситуации, когда к одному хранилищу данных имеют доступ разные приложения с разными моделями (иерархией классов). Т.е. может случиться так, что модель данных ООБД не совпадает и даже не является основой для модели данных приложения. Что ж, это просто усложнит написание приложения, но не сделает невозможным обращение к данным, поскольку их структура хранится вместе с ними. В простейшем случае речь идет об отображении (проекции) хранимых классов на классы приложения (этакое объектно-объектное отображение).
28 мар 05, 17:16    [1420632]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

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

Т.е. это следует понимать, как то, что с данными на сервере могут работать разные приложения совершенно по-разному не следуя никакой бизнес-логике и др. правилам и при работе таких нескольких приложений с данными что мы будем иметь?????? Жопу, получается! Потому что сервер БД ничего, кроме хранения самих по себе данных не может контролировать. И это именно то, против чего в том числе высказался vadiminfo, mir, еще кто-то ну и собственно я.

-- Tygra's --
28 мар 05, 17:28    [1420705]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ЛП
Guest
tygra
Т.е. это следует понимать, как то, что с данными на сервере могут работать разные приложения совершенно по-разному не следуя никакой бизнес-логике и др. правилам и при работе таких нескольких приложений с данными что мы будем иметь??????

Логику на клиенте мы будем иметь. Как в древних файл-серверных системах.
tygra
Жопу, получается!

Разумеется жопу.

Остается надежда на то, что где-нибудь существует ОБД, хранящая не только данные, но и логику в каком-либо виде.
(ась? GemStone, где ты?)
28 мар 05, 17:40    [1420753]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

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


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

автор
Представьте себе, некоторые DBA на этом форуме уверены, что данные можно ОБРАБАТЫВАТЬ средствами СУБД.


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

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

В общем точнее сказать так

Представьте себе, некоторые програмисты, не имеющие опыта работы с СУБД, что данные не нужно ОБРАБАТЫВАТЬ средствами СУБД.

И вообще Как-то спутался этот топик и топик, посвященный VERSANT'у. Во всяком случае общие темы там, а его обсуждение здесь.
28 мар 05, 18:27    [1420950]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Я только не понял одного. Кто-то считает, что в РСУБД существует какая-то фундаментальная фича, которая магическим образом заставляет тупого разработчика все делать правильно, наставляя на путь истинный ?

Ко всему вы сами пишете "не следуя никакой бизнес-логике и др. правилам", т.е. бизнес-логика в приложении все-таки есть, но какие-то "другие" (вероятно зловредные) приложения ее почему-то обходят. Возникает вопрос: зачем они ее обходят? С какого бодуна?

Похоже вы считаете, что реализация бизнес-логики в случае РСУБД выглядит как-то особенно по-другому. Я с этим не согласен. Бизнес-логика - это один из уровеней приложения. А реализован этот уровень в виде хранимых процедур (на T-SQL, PL-SQL, Java и пр.), в виде dll-библиотек, в виде отдельного приложения или как-то еще - вопрос реализации и, разумеется, удобства развертывания. И он относится к характеристикам СУБД постольку-поскольку. Если же вы считаете, что инкорпорированная бизнес-логика - непременный атрибут хранилищ данных, к которым можно применить термин "независимость данных от приложения", то скажите об этом явно.
28 мар 05, 18:40    [1420989]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

...

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


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

Следует обратиться к классическим определениям СУБД.

Что же касается вашего примера с зависимостями, то никакого анализа и обработки данных я в нем не вижу. Эта проблема решается элементарными средствами обеспечения целостности.
28 мар 05, 18:55    [1421027]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

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


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

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

Alexey Rovdo
U-gene

...

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


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

Следует обратиться к классическим определениям СУБД.

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


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

И какое вам дать "классическое определние СУБД" - от Мейера, Дейта, Кодда, Мартина, Когаловского, Кузнецова, Замулина? В любом случае, что-то мне подсказывает, что определяя СУБД они все они так или иначе обозначают ее как ресурс "независимый" и "разделяемый" , чего в случае с VERSANT'ом не видим. Я повторю, версант - это не СУБД и данные его - это не БД поскольку
1) Системой Управления данными в гораздо большей степени является сама ОО-программа (вы сами это написали!)
2) Данные, сохраняемые VERSANT'ом не могут называться Базой Данных, поскольку с ними может работать только одно приложение от которого эти данные зависят (см. пред. пункт).

В общем, я бы советовал Вам взять Дж.Мартина "Организация баз данных в вычислительных системах". Изд. 2-е 1980 Мир (Москва) и прочитать первые две-три главы. Там все очень хорошо написано, что такое СУБД, откуда и зачем они взялись. Говоря образно, не буква, но дух хорошо выражен. Я уверен - Вы поймете.

Опять же про зависимостти. В людом случае речь идет о согласованном изменении данных описывающих моделируемую предметную область - вы назвали это бизнес правилами, я назвал это завсисмостями. Ну не все ли равно, одной строкой это можно выразить или нужен код на 20 экранов? Есть входные праметры, есть выходной параметр (или параметры). Менятся входные - должны поменяться выходные. Вы это сделаете методом на клиенте, я, если захочу сделать это в СУБД, использую хранимку или триггером. Беда в том, что ежели клиенты разные, то возникают проблемы, которых в моем случае попросту не возникнет... я не говорю про VERSANT, поскольку у него такая проблема не стоит по определению.
28 мар 05, 19:58    [1421165]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Молодец, mir !
Но, пожалуйста, не нужно еще и упоминать Андрея Леонидовича (что же Вас так заКЛИНИло - действительно, КЛИНИка). Ведь Андрей Леонидович не виноват (надеюсь) в том бреде, который Вы здесь периодически пишите. Упоминайте, пожалуйста, настоящих специалистов по "этим трем СУБД". Я уверен, что настоящим специалистам удастся, в конце концов, сравнить "эти три СУБД". Лет через двадцать-тридцать...
28 мар 05, 22:27    [1421335]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

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

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

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

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

Alexey Rovdo

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

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

Alexey Rovdo

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

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

Alexey Rovdo

Поясните ???

Манипулирование данными тоже составная часть модели данных. Это происходит от того, что мы создаем БД не для того, чтобы занять персонал их набором. Можно придумывать сколь угодно выразительные средства для моделирования, но если в них нет средств манипулирования данными, то толку от этого будет не так много. Ведь мы создали БД с целью наиболее легкого способа получения инфы. Скорее всего, без этого, зависимости данных от приложений не избежать. Не только получение, но и изменение состояний БД будет целиком лежать на приложении. Если без него нельзя получить, инфу то это сильная зависимость.
В частности, я ее получу и с девелопером или любой другой утилитой, способной запускать запросы и вызывать ХП.
Что касается ХП то, они входят в стандарт SQL3. PSM - постоянно хранимые модули.

Alexey Rovdo

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

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

Про Дейта. Он безапеляционно отверг сам SQL как "искажение" реляционной модели, а вместо него вместе с Дарвеном предолжил язык D (1992). Насчет триггеров ничего не ясно из моих источников, а на счет ХП - язык D должен обладать вычислительной полнотой. Нужно ли хранить модули самого D? Скорее да чем нет.

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

Alexey Rovdo

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

Если Вы про ХП, то разумеется. И мы здесь и пытаемся все это прояснить.
Если про манипулирование данными, про язык БД, то они привязаны к модели данных и СУБД. Без них вроде нет ни того ни другого. А одни ОО-приложения разве заменяют ООСУБД?

Alexey Rovdo

Сам по себе объектный подход вовсе не запрещает нам строить клиенты любой степени "тонкости".

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

Alexey Rovdo

Я все-таки считаю, что в известных мне ООСУБД данные не зависят от приложения.

И я на это надеюсь. Иначе бы они проиграли бы еще на старте. Без этого далеко не удешь в соревнованиях с РСУБД.

Alexey Rovdo

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

Модель данных приложения все-таки, скорее всего, должна получаться
в результате конкретизации - снижения уровня абстракции модели данных БД. В БД сотрудник - в приложении преподаватель.
И тем более вы сами писали, что все данные в БД. Значит приложение поддерживает только их представления. Т.е. модель данных приложения - это внешняя модель данных. А сами данные вместе с их моделью хранятся в БД, а не в приложении. Если модель приложения обладает какой-то собственной моделью данных, не основанной на модели ООБД, то она, скорее всего, должна содержать данные этой своей модели. Т.е. превратиться в аля СУБД. Или как?
Другое дело какие-то другие модели, не данных, а еще чего-то. Вот им самое место в приложении. Наряду, конечно, с внешней моделью данных.
28 мар 05, 23:35    [1421409]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Недоучка

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

Ничем.

>А если в моей программе (клиентской части) есть классы invoce, pay_order и т.п. следует ли понимать, что они - часть GUI?

Ну подучите матчасть хоть немного, надоело заниматься ликбезом. Я нигде не говорил, что там ТОЛЬКО ГУИ, там может быть все что угодно, включая саму СУБД. Но это уже не клиент-сервер. Но ГУИ на клиенте будет обязательно, поэтому и отображение нужно будет строить обязательно. По-видимому это отображение Вы строите на клиенте, но это ничего не меняет, оно все равно занимает время.
29 мар 05, 01:28    [1421485]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Alexey Rovdo
Тут уже нужны конкретные примеры. Какие ограничения целостности нельзя выразить с помощью декларативных ограничений? И как часто такие ситуации встречаются на практике?

Тут дело не только выражении ограничений. Дело в том, что декларативные ограничения позволяют СУБД отслеживать целостность, но только за счет "отвергания" операций, нарушающих ее. Триггер же может позволить сохранить целостность за счет компенсирующих изменений. При этом операция успешно выполнится, а целостность -- сохранится.
Как пример можно привести хранение агрегатных значений с целью повышения производительности. Очевидное ОЦ -- соответствие хранимых значений агрегатов первичным данным (их области определения). Это ОЦ можно выразить декларативно, но это приведет к невозможности изменить первичные данные. Триггер же позволит просто скорректировать агрегатное значение. Поскольку обойти триггер нельзя, целостность гарантируется.
29 мар 05, 07:10    [1421597]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Недоучка
Guest
c127
Я уже говорил, что В ПОЛЬЗОВАТЕЛЬСКОМ ПРИЛОЖЕНИИ И В ООБД ОБЪЕКТЫ РАЗНЫЕ


c127
2 Недоучка

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

Ничем.

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

c127
Ну подучите матчасть хоть немного, надоело заниматься ликбезом. .

Я думаю, подучится стоит Вам, чтоб не пороть чушь, надувая щеки и делая умное лицо...
29 мар 05, 09:10    [1421718]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Я повторю, версант - это не СУБД и данные его - это не БД поскольку
1) Системой Управления данными в гораздо большей степени является сама ОО-программа (вы сами это написали!)
2) Данные, сохраняемые VERSANT'ом не могут называться Базой Данных, поскольку с ними может работать только одно приложение от которого эти данные зависят (см. пред. пункт).


Это всего-лишь ваша (неправильная) интерпретация написанного мною.

U-gene

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


Я уже писал, что в ООСУБД VDS (с помощью специального расширения Versant SQL) и триггеры, и хранимые процедуры поддерживаются. Вопрос только в том, что лично я не считаю триггеры и хранимые процедуры, обязательным атрибутом СУБД. Следуя вашей логике, я тоже могу написать "Беда в том, что ежели хранимые процедуры разные, возникают проблемы ... ". Т.е. я хочу сказать, что разные приложения с разными методами из ниоткуда не появляются. И в конечном итоге нет никаких причин делать разными методы в приложениях, работающих с одной базой данных (тем более, что есть специальные средства именно для таких случаев). Так что есть только вопрос реализации и удобства развертывания, но не какая-то фундаментальная проблема, не позволяющая корректно строить сложные информационные системы.
29 мар 05, 10:52    [1422125]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 Alexey Rovdo

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

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

Поймите, я не говорю что Версант - плохая система, или то, что она не нужна. Очевидно, что это достаточно мощная система, которая без сомнения должна быть востребована, но это не есть система управления базами данных, поскольку никаких баз данных здесь нет - есть перситное хранилище данных объектов конкретного приложения.
29 мар 05, 11:36    [1422384]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

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

Но есть возможность!
Поэтому я сделаю приложение. которое будет писать в БД всякую муть - и все пройдет на ура, потому что данные в БД никак и ничем не контролируются - только кдиентским приложением, которое я сам и напишу :))

ЗЫ Все же есть ощущение, что Alexey Rovdo в обсуждаемой ООБД немного чего сделал, а уж про РСУБД ничего и говорить не хочется, потому что рассуждения очень-очень странные, уровня начинающего программиста БД, который на 100% уверен в том, что он делает, хотя опыта нет совсем - этакие розовые мечты, типа приваеденной выше.

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

-- Tygra's --
29 мар 05, 11:37    [1422389]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 56 57 58 59 60 [61] 62 63 64 65 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить