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

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
2 Alexey Rovdo
Поздравляю! Первая победа вами в этом топике одержана - это про софткей, забираю свои слова обратно. Правда это оффтоп, можно победу и не защитывать :))

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

Откуда: Симферополь
Сообщений: 4045
Широкие жест, tygra, не хватает только в конце чего-то типа "все равно ты дурак"
1 апр 05, 15:09    [1434182]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Alexey Rovdo
А я по прежнему считаю, что определение Кодда относится к РМД. Хотя бы потому, что и понятия такого ОМД в 1980 еще не было.
Какое отношение наличие или отсутствие ОМД в 1980 или еще каком году имеет отношение к определению термина, общего для теории баз данных вообще? Вы хоть понимаете, что сказали? Попробуем только перечислить известные модели данных:
• Hierarchical Model,
• Network Model,
• Relational Model,
• Object/Relational Model,
• Object-Oriented Model,
• Semistructured Model,
• Associative Model,
• Entity-Attribute-Value (EAV) model,
• Context Model
Неужно вы полагаете, что от факт отсутствия какой-либо из этих моделей данных может кардинально зависеть само это понятие? Меняется ли понятие "язык программирования" от факта наличия/отсутствия в каком-либо году языка Perl? Языка Java? Должно ли появление, скажем, языка C#, привести к пересмотру понятия "язык программирования"?
Ну, а ести хотите краткое определение РМД, вот:
автор

A succinct, precise definition of a data model is:
"A general theory of data which defines structural (organization), integrity and manipulation features."
It is straightforward to specify these precisely for the relational data model:
Theory: predicate logic and set mathematics
• Structure: Domains, attributes, tuples, relations
• Integrity: domain, column, table and database integrity
• Manipulation: R-operations (restrict, project, join, etc.)
1 апр 05, 15:29    [1434300]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Широкие жест, tygra, не хватает только в конце чего-то типа "все равно ты дурак"

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

А пока что буду читать - клавиатура перегрелась :))

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

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

Ну, а ести хотите краткое определение РМД, вот:

A succinct, precise definition of a data model is:
"A general theory of data which defines structural (organization), integrity and manipulation features."
It is straightforward to specify these precisely for the relational data model:
Theory: predicate logic and set mathematics
• Structure: Domains, attributes, tuples, relations
• Integrity: domain, column, table and database integrity
• Manipulation: R-operations (restrict, project, join, etc.)


Ок. Определение Дейта мне нравится больше, чем определение Кодда, которое вы приводили выше. Пусть модель данных есть:

A general theory of data which defines structural (organization), integrity and manipulation features

Полагаю каких-то споров в научном мире по поводу этого определения со времени его появления не было. Так что в отношении этого определения я все свои заявления дезавуирую! (забавно, c "моделью данных" разобрались, но есть ли определение данных и что такое модель ?)

Обращаю ваше внимание на интересный факт. Целостность входит в понятие модели данных по Дейту, но вот конкретные механизмы обеспечения целостности он считает зависимыми от модели. Т.е. "domain, column, table and database integrity" - это особенности РМД. С другой стороны Дейт справедливо считает, что любая модель данных должна включать:

the structural, integrity and manipulation equivalents for his "model" and how are they different, let alone better, than the relational ones.

С этой точки зрения ОМД не является полной теорией (в т.ч. и способы обеспечения целостности модели в ней до конца не прописаны)...
Ну а мнение Дейта нам известно:

Models, models, everywhere
My mind is on the blink;
Models, models, everywhere
Nor any time to think.

The database is rot: O Christ!
That ever this should be!
Yea, slimy models E'd and R'd
All through the poor DB.
1 апр 05, 17:37    [1435091]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
serg99
Member

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

Мне не верится что Вы не знаете чем отличается апп-сервер со встроенным хранилищем персистентных объектов от типовой СУБД масштаба предприятия.


Таки ЧЕМ ? (при условии соблюдения соглашений, описанных мною выше).
Честно говоря у меня просто нет времени начинать обсуждение этой безусловно интересной но очень обширной темы. Прошу меня извинить.
1 апр 05, 17:57    [1435166]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Выше уже много раз пытались определить, что же такое ООМД. И пришли к выводу, что ООМД - это что-то очень туманное и дать ее внятное описание никто не может. Поэтому здесь я говорю "Я не знаю, что же такое ООМД".

Ну Вы даете. Вы же представить ООСУБД. Я надеялся узнать от Вас что-нить. А у Вас ООСУБД непонятным ООМД?


Alexey Rovdo

А нужен ей или не нужен сервер приложений окончательно решать только тому, кто начнет использовать в работе ООСУБД (в случае GemStone за него уже решили).

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

Alexey Rovdo

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

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

Alexey Rovdo

Вся проблема именно в толковании этих терминов и не только этих.

Так Вы пересмотрели свои взгляды не терминологические споры? Я стараюсь их избегать с Вашей подачи и использую то, чему в институте учили и есть в литре. Причем в разных источниках. Редко встречающееся стараюсь не использовать. А Вы предлачаете что? Что вообще нигде не встречается, потому что только что в голову пришло?

Alexey Rovdo

Нужны ли методы объектов для обеспечения целостности данных? В зависимости от ответа на это вопрос подходы разбиваются на две ветви:

Вы специально ставите вопрос с ног на голову? Это дело ООМД, что нужно для обеспечения целостности, т.е. как ее обеспечить? А что нужно методам вообще вопрос ООП.

Alexey Rovdo

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


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

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

Alexey Rovdo

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

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

Alexey Rovdo

Следует шире взглянуть на систему и пересмотреть наше понимание терминов "целостность данных" или "СУБД".

Смело. Как Вы думаете за 35 лет на это не навзглядывались уже по разному. Ничего достойного всеобщего признания не увидели, а мы увидим?

Alexey Rovdo

Тогда то, что мы называем обычно ООСУБД, в действительности СУБД не является

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

Alexey Rovdo

если только мы не согласны принять положение 1 и считать эти продукты СУБД в смысле 1) - возможно, это праильнее называть Persistence Object Storage

И назвали уже. Есть перманентные языки программирования. Они не СУБД. Но мы же их не рассматриваем? Нас интересуют СУБД.
Alexey Rovdo

Но пара Persistence Object Storage + Сервер приложений (при принятии соглашений, о которых я выше много говорил) полностью удовлетворяет всем классическим критериям СУБД и "внутри" у нее вероятно ОМД

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

Alexey Rovdo

"В одном файле = в БД". А вот с MS SQL и Oracle вы уже согласны отойти от такого отождествления?

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

Alexey Rovdo


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


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

Alexey Rovdo

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



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

Alexey Rovdo


Сейчас вы (и многие другие) напоминаете мне человека

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

Alexey Rovdo


Я уже привык к тому, что в итоге всегда остается только Oracle и сравнивать приходится только с ним (даже если со строны ООСУБД речь идет о продуктах для встроенного, файл-серверного или пр. применения).

Вот опять я не понял, что Вы имели в виду исходя из текста, на который это ответ. Там было, что если представитель типа СУБД, что-то поддерживает, то можно говорить, СУБД этого типа, это поддерживают. А Вы мне про Ерему.
Но я знаю более или менее всего два СУБД: Оракл и Аксцесс. Потому могу что-то пояснять только на их примерах.
2 апр 05, 01:15    [1435981]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

Откуда:
Сообщений: 137
vadiminfo
[quot Alexey Rovdo]
Выше уже много раз пытались определить, что же такое ООМД. И пришли к выводу, что ООМД - это что-то очень туманное и дать ее внятное описание никто не может. Поэтому здесь я говорю "Я не знаю, что же такое ООМД".


Джентельмены.

Давайте забудем (и по крайней мере сделаем вид что отвлеклись от) все что здесь уже говорилось про объектные базы и Версант. Предлагаю более вообще не обсуждать теорию.

Простейшая формулировка как хранит данные и работает Версант (в отличие от реляционных баз):

1. Версант - это "якобы объектное хранилище". Методы объектов не выполняются и не хранятся. Хранятся только данные (структуры данных). Как в РСУБД. Буду нывать далее [font sise=1 color=red] структурами данных Версант[/font]. Струры данных самые разнообразные - это и массивы, коллекции (вложенные коллекции), и указатели на другие объекты и пр. На эти коллекции маппируются вложенные коллекции классов (1-n). На указатели на объекты - ссылки n-m.

2. Версант (ядро) ничего не знает про Яву, с++, Smalltalk, whatever.
Средства доступа к Версанту на Яве "преобразуют" Ява объекты в структуры данных Версант. Средства доступа к Версанту на с++ "преобразуют" с++ объекты в структуры данных Версант. Предыдущие 2 предложения применимы к любым "обектным" языкам. Не буду их копировать.

3. Средства доступа.
1. Командная строка (аля sqlplus). Сама по себе не объектна. Соответственно, все запросы из командной строки возвращают структуры данных Версант. И тупо их печатают.
2. Средства доступа к Версанту на Яве.
2.1 Доступ по спецификации JDO. Это средство доступа ответственно за преобразование пришедших данных Версант в классы Ява. В соответствии со стандартом JDO, имеет свой собственный язык JDOQL. Это же средство ответственно за трансляцию JDOQL в запросы/вызовы процедур/чтоугодно нативное для Версант.
2.2 Доступ по АПИ Версант. Обеспечивает доступ непосредственно к структурам данных Версант. Запросы (по моему) на языке VQL. Имея этот доступ, можно реаливать любой мэппинг пришедших структур данных Версант на классы Ява.
2.3 Доступ по технологии Transparent Persistance. Просто вызывая функции Ява но изменению значения полей объектов, автоматически происходит преобразование данной системой доступа объектов в структуры данных Версант и их запись. Основной плюс - полное отсутствие обращений по обслуживанию сохранения объектов (поэтому и называется Transparent...)
2.4 Доступ по спецификации JDBC. Не знаю, не работал.

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

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

4. Средства ссылочной целостности - полные аналоги check constraints, foreign key, primary key. Есть хранимые процедуры и триггеры.

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

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

Ну Вы даете. Вы же представить ООСУБД. Я надеялся узнать от Вас что-нить. А у Вас ООСУБД непонятным ООМД?


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

vadiminfo

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


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

vadiminfo

Вы представляете – парни сделали СУБД с недоделками и говорят, а все остальное Вы сможете с помощью сервер приложения или библиотек каких-нибудь?


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

vadiminfo

Alexey Rovdo

Нужны ли методы объектов для обеспечения целостности данных? В зависимости от ответа на это вопрос подходы разбиваются на две ветви:

Вы специально ставите вопрос с ног на голову? Это дело ООМД, что нужно для обеспечения целостности, т.е. как ее обеспечить? А что нужно методам вообще вопрос ООП.


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

vadiminfo

Alexey Rovdo

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

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


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

vadiminfo

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


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

vadiminfo

Alexey Rovdo

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

Ну, знаете, так можно туда еще и ОС встроить? У сервера приложений другие ф-ии, чем у СУБД. Он должен действовать как клиент, даже если его хранить в БД.


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

Кстати, а вы знаете, что на рубеже 80-90 гг. действительно имели место серьезные дебаты на тему встраивания ОС в СУБД?

vadiminfo

Alexey Rovdo

Следует шире взглянуть на систему и пересмотреть наше понимание терминов "целостность данных" или "СУБД".

Смело. Как Вы думаете за 35 лет на это не навзглядывались уже по разному. Ничего достойного всеобщего признания не увидели, а мы увидим?


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

vadiminfo

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


Та же VDS конечно СУБД. И это так просто потому, что она удовлетворяет всем возможным трактовкам. Т.е. для нее допустимы все варианты, описанные мною выше в топике.

vadiminfo

модель данных может быть без ограничений целостности.


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

vadiminfo

А Вы предлагаете ...


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

vadiminfo

... но я всегда обойду его просто послав запрос на обновление из стандартного окна запросов ... подстраховки нет.


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

vadiminfo

вообще все что можно в ИС хранить в БД.


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

vadiminfo

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


Ура! Ура! Ура! Подписываюсь на 100%

Таким образом, если система выполняет функции, полностью соответствующие функциям СУБД, то ее можно рассматривать и пользоваться ею так же, как и СУБД.

vadiminfo

Вот в данном случае. Я Вас спросил, что значит Ваше утверждение, о том, что Версант поддерживает ограничения целостности, в то время как ООСУБД не поддерживает без сервера приложений? Ведь Версант – ООСУБД? Т.е. раз Версант поддерживает, то и ООСУБД поддерживает?


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

vadiminfo

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


Это я о наболевшем. Впрочем, не принимайте все исключительно на свой счет.

PS: Всем, кто интересуется ООСУБД, рекомендую для ознакомления отчет
An Evaluation of Object-Oriented DBMS Developments: 1994 Edition. (Frank Manola). (часть 1, часть 2).
Несмотря на почтенный возраст этого документа, многие обсуждаемые здесь вопросы там раскрыты достаточно полно.
2 апр 05, 13:07    [1436150]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
самопал
Guest
Dimonische
4. Средства ссылочной целостности - полные аналоги check constraints, foreign key, primary key. Есть хранимые процедуры и триггеры.

5. План запросов - есть хрень показывающая план запроса.


Интересно было бы увидеть, на что это похоже. (На конкретных примерах).
В частности, как обеспечить, например, следующее ограничение для схемы "работа - служащие":
job.HireDate < job.FireDate &&  job.HireDate > job.employee.BirthDate+'16 years' 

Где и какой код для этого должен быть? В методах хранимых объектов? В триггере?
2 апр 05, 14:42    [1436244]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
самопал
В методах хранимых объектов? В триггере?


Это решаете вы сами.

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

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

job.HireDate < job.FireDate &&  job.HireDate > job.employee.BirthDate+'16 years' 

Где и какой код для этого должен быть? В методах хранимых объектов? В триггере?


Ща найду в доке и напишу как будет в триггере
2 апр 05, 16:37    [1436360]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Dimonische

>2. Версант (ядро) ничего не знает про Яву, с++, Smalltalk, whatever.
Средства доступа к Версанту на Яве "преобразуют" Ява объекты в структуры данных Версант. Средства доступа к Версанту на с++ "преобразуют" с++ объекты в структуры данных Версант. Предыдущие 2 предложения применимы к любым "обектным" языкам. Не буду их копировать.


Тут уже упоминалось ситуация, можно ли поподробней. Известно, что в джаве объект, это всегда указатель на объект, а в С++ это может быть и сам объект и указатель на объект. Как это храниться в базе и чем различаеются сиуации с объектом и с указателем с точки зрения хранения в базе?
3 апр 05, 06:35    [1436850]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


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

Внутренние механизмы обработки ссылок и указателей отличаются в зависимости от того, на каком языке написана сама ООСУБД. Так VDS, FastObjects t7/.NET написаны на C/C++, а FastObjects j1/j2 - на Java. Впрочем, во всех случаях и Java-ссылки и C-указатели предназначены для обращения к объектам в памяти, поэтому при сохранении в ООБД они преобразовываются в OID связанных объектов (форматы OID в разных ООСУБД разные). При выборке хранимого объекта они снова превращаются в ссылки или указатели.
3 апр 05, 12:49    [1436945]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
BaZa
Guest
Dimonische

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


Мне просто интересно: какое из требований к объектному хранилищу не выполняется Versant'ом?
3 апр 05, 13:17    [1436966]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Есть красивая идея - ООП. И ООСУБД только часть этой идеи.

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

Alexey Rovdo

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

Вы все-таки думаете, что модель данных что-то второстепенное. Потому так легко допускаете отказ от термина ОМД.
Моделей данных придумано много как Вам сказал mir, но тока у РМД есть такое мат обоснование. Это достоинство, но не значит, что названия других моделей не возможно употреблять.

Alexey Rovdo

Сервис выполнения программного кода на ОО-языках высокого уровня, тесно взаимодействующий с программным компонентом, обеспечивающим транзакционную обработку, реакцию на события, хранение данных и обработку запросов к ним"

Это пока не переварил.

Alexey Rovdo

Вы опять пытаетесь искать в моих высказываниях нечто компрометирующее ООСУБД Versant?

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

Alexey Rovdo

А ответ на него - дело того, кто решил работать с ООСУБД

Все-таки чтобы решить работать с ООСУБД, важно чтобы ответ был от самого ООСУБД.

Alexey Rovdo

В ОО-парадигме функции триггеров и хранимых процедур нужно перекладывать на методы объектов и интерфейсы реакции на события.

Нет возражений. Тока из Ваших постов получается, что не переложили еще пока. Вот и возникают вопросы.

Alexey Rovdo

Кстати, а вы знаете, что на рубеже 80-90 гг. действительно имели место серьезные дебаты на тему встраивания ОС в СУБД?

Не знаю. Зато я знаю, что ОС с колокольни моей специализации в инфотехнологиях можно считать системой управления базой алгоритмических знаний. Это я Вам к тому, чтобы Вы знали, что кроме проггеров есть еще и базисты, которые прогам отдают в некоторых вопросах вторую роль по сравнению с данными. Наверное, из-за этого то, что для Вас кажется важным мне представляется менее значимым, и наоборот – важное для меня Вам представляется вторичным.
Alexey Rovdo

Но заметьте к практической разнице при написании программ это не приводит

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

Alexey Rovdo

Та же VDS конечно СУБД. И это так просто потому, что она удовлетворяет всем возможным трактовкам. Т.е. для нее допустимы все варианты, описанные мною выше в топике.

Так это Вы сказали, что ООСУБД не СУБД. А не я.

Alexey Rovdo

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

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

Alexey Rovdo

Приняв соглашение что-то не делать мы решаем фундаментальные проблемы.

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

Alexey Rovdo

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

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

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

Не так мы далеко зайдем. Это тока породит дискуссию о том, что есть БД. Возможно многостраничную..
3 апр 05, 18:01    [1437157]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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

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

vadiminfo

Вы все-таки думаете, что модель данных что-то второстепенное. Потому так легко допускаете отказ от термина ОМД.
Моделей данных придумано много как Вам сказал mir, но тока у РМД есть такое мат обоснование. Это достоинство, но не значит, что названия других моделей не возможно употреблять.

Я легко допускаю отказ от термина просто потому, что на практические проблемы это не имеет никакого влияния. Впрочем, лично я с вами согласен - с термином ОМД несколько удобнее, чем без него. Так что договариваемся
употреблять его.

vadiminfo

>>"Сервис выполнения программного кода на ОО-языках высокого уровня, тесно взаимодействующий с программным компонентом, обеспечивающим транзакционную обработку, реакцию на события, хранение данных и обработку запросов к ним"

Это пока не переварил.

В том и прикол - вы ищете смысл в самом названии, а я ищу разницу в выполняемых функциях. Функции мы выше уже много раз обсудили. Формат предлагаемого соглашения тоже. А название можете придумать и сами. Впрочем, следует понимать, что все это имеет отношение только к варинтам ветви 2 из моего списка. Если же вам больше импонирует вариант 1, то такого вопроса нет и его можно закрыть.

vadiminfo

>> А ответ на него - дело того, кто решил работать с ООСУБД

Все-таки чтобы решить работать с ООСУБД, важно чтобы ответ был от самого ООСУБД.

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

Alexey Rovdo

>> В ОО-парадигме функции триггеров и хранимых процедур нужно перекладывать на методы объектов и интерфейсы реакции на события.

Нет возражений. Тока из Ваших постов получается, что не переложили еще пока. Вот и возникают вопросы.

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

vadiminfo

Зато я знаю, что ОС с колокольни моей специализации в инфотехнологиях можно считать системой управления базой алгоритмических знаний. Это я Вам к тому, чтобы Вы знали, что кроме проггеров есть еще и базисты, которые прогам отдают в некоторых вопросах вторую роль по сравнению с данными. Наверное, из-за этого то, что для Вас кажется важным мне представляется менее значимым, и наоборот – важное для меня Вам представляется вторичным.

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

vadiminfo

Зато приводит к разнице в управлении данными, а через это и в написании программ.

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

vadiminfo

Так это Вы сказали, что ООСУБД не СУБД. А не я.

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

vadiminfo

Alexey Rovdo

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

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

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

vadiminfo

Кроме того, я говорил Вам, что ООМД поддерживает ключи – там не пустое множество ограничений целостности. Просто пока с Ваших слов в этом аспекте ОМД уступает РМД.

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

vadiminfo

... А еще кому-то по барабану наши с Вами соглашения. Мы же не сможем написать ГОСТ?

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

vadiminfo

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

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

На деле же следует оценивать системы не по названиям (или соответствию им), а по их прикладным характеристикам. Выше я делал попытку сравнения конкретных конфигураций. Но собственно прикладные вопросы никого не заинтересовали. Все предпочли углубиться в обсуждение названий. А ведь перечень основных прикладных параметров был сформулирован и особых возражений не вызвал (и интереса тоже).
3 апр 05, 21:38    [1437282]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
>В Java никакого механизма для работы с указателями нет (это сделано для того чтобы не дать программе обращаться к любому адресу в памяти). Но это вовсе не значит, что обращение к данным объектов всегда сопровождается их дублированием. В Java есть понятие ссылки.

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

Dimonische говорил:

>2. Версант (ядро) ничего не знает про Яву, с++, Smalltalk, whatever.
Средства доступа к Версанту на Яве "преобразуют" Ява объекты в структуры данных Версант. Средства доступа к Версанту на с++ "преобразуют" с++ объекты в структуры данных Версант. Предыдущие 2 предложения применимы к любым "обектным" языкам.


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

Следующий вопрос. Если для каждого ОО языка программированя есть средства, преобразующие объекты языка в объекты версанта, то можно ли потом с объектами, созданными джавой работать из С++ и наоборот?
4 апр 05, 05:24    [1437393]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
vadiminfo
Манипулирования данными (другой компонент МД) нет, например, в ER. Но ER – модель данных. Мы про это все вроде говорили када-то в этой теме.
Поправочка. ER-модель на самом деле содержит и средства манипулирования, и некоторые ограничения целостности. Все это Питер Чен предусмотрел. Просто об этом мало кто знает. Дело в том. что эти аспекты ER-модели оказались не очень удачными, поэтому они как-то сошли на нет. Строго припадая к первоисточникам, ER-модель Чена вводилась как модель данных. Однако в том урезанном виде, как она используется десятки лет на практике, она моделью данных не является. Поскольку ER-нотация довольно мощна и абстрактна, она хорошо подошла для семантического (концептуального) моделирования, а аспекты манипулирования "отвалились". То есть сейчас она предназначена для моделирования предметной области, но не для моделирования данных в строгом смысле.
4 апр 05, 09:41    [1437559]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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

Следующий вопрос. Если для каждого ОО языка программированя есть средства, преобразующие объекты языка в объекты версанта, то можно ли потом с объектами, созданными джавой работать из С++ и наоборот?


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

Скажем есть Java-класс:

class Product
{
   String title_;
   short year_;
   Company company_;
   SetOfObject managers_; // of type Manager
}

Полный аналог этого класса на C++ будет таким:

persistent class Product
{
   PtString title_;
   short year_;
   ondemand<Company> company_;
   lset <ondemand<Manager>> managers_;
};

Т.е. две программы (на Java и на C++), используя эти описания смогут обращаться к одним и тем же данным одних и тех же объектов. Возможно следующая ниже картинка сможет пояснить то, как FastObjects общается с программами, написанными на разных языках (в VDS ситуация обстоит похожим образом).

К сообщению приложен файл. Размер - 0Kb
4 апр 05, 10:52    [1437867]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Мне проще всего проиллюстрировать это на примере FastObjects t7.

Скажем есть Java-класс:
........
Полный аналог этого класса на C++ будет таким:
....

Кто должен создать класс на С++? Я? Руками? Автоматически? Кто будет прописывать методы? Их нужно заново писать руками? И если я что-то добавляю в объект в коде Java (метод), я должен руками этот метод добавить в объект в коде С++? А если не добавлю? А если добавлю, но не так?

Получается - в сотый раз говорится - что данные зависят от клиента.

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

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

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

[Получается - в сотый раз говорится - что данные зависят от клиента.

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


А если "нужных ХП" будет две-три-пять-... то чем это отличается от двух-трех-пяти-... разных программ? (пожалуй действительно в сотый раз)

"Такая ООСУБД" - это ООСУБД Gemstone и O2 (Ontos) . Посмотрите - раскажете нам. Сам не имел пока возможности с ними познакомиться.
4 апр 05, 12:29    [1438337]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Кстати, tygra. Ваша фраза о том, что "данные зависят от клиента" неявно предполагает, что вы методы объектов относите к данным, т.е. по моей (представленной выше) классификации четко определились с тем, что для обеспечения целостности модели при использовании ООП необходимо опираться именно на методы объектов (п. 2).
4 апр 05, 12:32    [1438357]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

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

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

ЗЫ Ну прямо ощущение после таких объяснений, что я с .... дебилом разговариваю - извините, но вы сами стараетесь, чтобы такое ощущение появилось, ваши некоторые вопросы и ответы никак не совпадают с мыслями о том, что вы действительно что-то понимаете в обсуждаемом предмете. На один - достаточно простой вопрос - вы даете совсем другой, и совсем неожиданный ответ. Может действительно не понимаете? Я не оскорбления ради - может мы с человеком, действительно не понимающим разговариваем? Или с .... Иногда складывается именно такое ощущение. Тогда может начать с букваря? С азбуки?

автор
Кстати, tygra. Ваша фраза о том, что "данные зависят от клиента" неявно предполагает, что вы методы объектов относите к данным, т.е. по моей (представленной выше) классификации четко определились с тем, что для обеспечения целостности модели при использовании ООП необходимо опираться именно на методы объектов (п. 2).

Конечно, методы долны быть неотделимы от данных. Как в случае с ХП. Но ваши методы сюда не лезут. :))

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

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

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


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

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


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

К слову, даже в типовой клиент-серверной конфигурации, когда именно клиентские приложения (запущенные на множестве клиентских машин) обращаются непосредственно к ООСУБД, мы тоже можем обеспечить абсолютную идентичность кода на всех клиентах. Такая возможность заложена в .NET. Достаточно разместить exe-шник на одном Web-сервере и в одном месте, и клиенты будут всякий раз запускать именно одну (истинную) версию кода. Разумеется, при таком подходе изолированность модели от кода клиенских программ ниже, поскольку целостность сохраняется только при том условии, что клиентское приложение у нас в каждый момент времени существует только в одной единственной версии. А переписывание приложения на новом языке программирования приведет и к необходимости переписывания кода методов, что уже может породить проблемы, о которых вы говорите.
4 апр 05, 14:24    [1439014]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 66 67 68 69 70 [71] 72 73 74 75 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить