powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Объекты и навигация.
77 сообщений из 77, показаны все 4 страниц
Объекты и навигация.
    #33241279
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Предлагаю перенести дискуссию по сабж из соседних топиков сюда, ибо и они интересны сами по себе, и сабж видимо волнует.

Для начала навигацию я бы определил как перемещение, обход по ребрам ориентированного графа данных. Если в некоей модели данных определен какой-либо орграф данных и навигационные операции, как в CODASYL , то модель поддерживает навигацию. Типичные навигационные операции:
Перейти к родителю по связи X, Перейти к первой дочке по связи X, Добавить дочку в конец/начало набора дочек и т.д. Естественно, поддержка навигации требует автоматического обновления кучи указателей, чем и занимется СУБД.

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

Лично мне хотелось бы знать, какими средствами автоматического обновления указателей и навигации обладают ООСУБД?
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33241443
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ModelR
Лично мне хотелось бы знать, какими средствами автоматического обновления указателей и навигации обладают ООСУБД?

А давайте разберемся, зачем вообще нужны средства автоматического обновления указателей. Ведь логика построения известных мне ООСУБД строится в первую очередь на том, чтобы не портить существующие указатели и, соответственно, избегать необходимости их автоматического обновления. Хотя, разумеется, избежать таких ситуаций в принципе не возможно и ООСУБД обеспечиваются необходимыми средствами, но их типовое применение лежит в области задач администрирования.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33241737
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelRЛично мне хотелось бы знать, какими средствами автоматического обновления указателей и навигации обладают ООСУБД?

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

Что касается моей версии ООСУБД, то в ней обновление указателей отсутвует по определению, так как все объектные (в БД) указатели являются мягкими. А все указатели времени жизни экземпляра процесса живут в месте с кучей и никогда не сохраняются в БД. Это однако приводит к некоторой потере эффективности (по сравнению с идеальным случаем) так как так же как и РБД мне приходится вести деревья индексов и проводить JOIN по этим деревьям при поиске объектов по их мягким указателям.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33241937
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
shuklin Пользователя ИМХО в первую очередь будут интересовать возможности модели представления данных. Во вторую очередь - скорость, надежность и прочие технические характеристики.

Ну, нет!
Это разработчика интересуют возможности модели , а вот пользователю как-раз это все до лампочки (другое дело, что пользователь, как заказчик, не может не думать о трудоемкости и стоимости разработки). Пользователю важна именно скорость, надежность и прочие технические характеристики .
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33241945
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
«Навигация» по Толковому словарю В.И. Даля издания 1914 года:

«…знание определять точку, место корабля на карте и придя оттуда лучшим путем в назначенное место»
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33241962
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
В контексте БД приходилось встречать такие термины как
"навигация по подполю" и "навигация по связи".

Вряд ли можно говорить о навигации вообще. Нужно именно уточнять способ навигации. При таком подходе, думаю, станет очевидным и смысл, вкладываемый в эти понятия на практике.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33242663
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shuklinИМХО основное отличие РБД от ОБД - в первой данные хранятся в таблицах, а во второй - в графе.Просьба в сугубо теоретическом разговоре быть построже и попонятнее в терминологии. В частности, здесь я не понял о каком именно уровне "хранения" данных вы говорите: логическом или физическом (если вы понимаете разницу). Что касается РМД, на физическом уровне данные вовсе не хранятся в таблицах. Поэтому речь, видимо, идет о логическом уровне, т.е. о модели данных. Забудем пока о том, что строго говоря нет такой вещи как общепризнанная ОМД, допустим она есть. Тогда по вашему в ОМД базовыми понятиями являются: граф, вершина графа, дуга графа (рискну также предположить, что в вершинах хранятся объекты). Конечно же, в таком случае навигация в ОСУБД неизбежна, поскольку набор операция над графами, известный в математике, весьма специфичен и мало пригоден для задач управления данными. Это вынуждает довольно часто вместо декларативных указаний "ЧТО СДЕЛАТЬ", характерных для РСУБД, писать фактически инструкции для ОСУБД "КАК СДЕЛАТЬ". Это по сути и есть главный признак навигационного подхода. В РСУБД мы обычно говорим "приведи корабль туда-то" и все, а навигация выполняется автоматически. В ОСУБД мы довольно часто (для сколько-нибудь нетривиальных случаев) вынуждены "брать штурвал в руки" и вести корабль по извилистым каналам.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33242760
MX - ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mir shuklinИМХО основное отличие РБД от ОБД - в первой данные хранятся в таблицах, а во второй - в графе.Просьба в сугубо теоретическом разговоре быть построже и попонятнее в терминологии. В частности, здесь я не понял о каком именно уровне "хранения" данных вы говорите: логическом или физическом (если вы понимаете разницу). Что касается РМД, на физическом уровне данные вовсе не хранятся в таблицах. Поэтому речь, видимо, идет о логическом уровне, т.е. о модели данных. Забудем пока о том, что строго говоря нет такой вещи как общепризнанная ОМД, допустим она есть. Тогда по вашему в ОМД базовыми понятиями являются: граф, вершина графа, дуга графа (рискну также предположить, что в вершинах хранятся объекты). Конечно же, в таком случае навигация в ОСУБД неизбежна, поскольку набор операция над графами, известный в математике, весьма специфичен и мало пригоден для задач управления данными. Это вынуждает довольно часто вместо декларативных указаний "ЧТО СДЕЛАТЬ", характерных для РСУБД, писать фактически инструкции для ОСУБД "КАК СДЕЛАТЬ". Это по сути и есть главный признак навигационного подхода. В РСУБД мы обычно говорим "приведи корабль туда-то" и все, а навигация выполняется автоматически. В ОСУБД мы довольно часто (для сколько-нибудь нетривиальных случаев) вынуждены "брать штурвал в руки" и вести корабль по извилистым каналам.
рискну вмешаться : хорошее сравнение !
давно работаем на CACHE (MSM) - лет 15
там деревья(графы) и навигация "со штурвалом в крепких руках"
поэтому быстро-точно, попутно можно выполнять много чего еще.
видимо на автомате (автоматическая коробка передач, автопилот, PCУБД )
расход горючего на 10 % больше а жизнь скучнее
(хотя иногда залетает не туда :)
-------------
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33242807
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mir... вместо декларативных указаний "ЧТО СДЕЛАТЬ", характерных для РСУБД, писать фактически инструкции для ОСУБД "КАК СДЕЛАТЬ". Это по сути и есть главный признак навигационного подхода. В РСУБД мы обычно говорим "приведи корабль туда-то" и все, а навигация выполняется автоматически. В ОСУБД мы довольно часто (для сколько-нибудь нетривиальных случаев) вынуждены "брать штурвал в руки" и вести корабль по извилистым каналам.

А вам не кажется, что под "автоматической навигацией" в случае РСУБД понимается банальный перебор всех возможных положений корабля вплоть до того момента пока мы не обнаруживаем совпадение его текущего положения с точкой назначения. Т.е. "навигации" как таковой и нет - есть систематическое прочесывание моря.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33243121
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey RovdoА вам не кажется, что под "автоматической навигацией" в случае РСУБД понимается банальный перебор всех возможных положений корабля вплоть до того момента пока мы не обнаруживаем совпадение его текущего положения с точкой назначения. Т.е. "навигации" как таковой и нет - есть систематическое прочесывание моря.Нет, ну нельзя же НАСТОЛЬКО подставляться... Уже даже не смешно.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33243186
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mir Конечно же, в таком случае навигация в ОСУБД неизбежна, поскольку набор операция над графами, известный в математике, весьма специфичен и мало пригоден для задач управления данными. Это вынуждает довольно часто вместо декларативных указаний "ЧТО СДЕЛАТЬ", характерных для РСУБД, писать фактически инструкции для ОСУБД "КАК СДЕЛАТЬ". Это по сути и есть главный признак навигационного подхода. В РСУБД мы обычно говорим "приведи корабль туда-то" и все, а навигация выполняется автоматически.
Ваш тезис верен только в лабораторных условиях. В реальной жизни же в запросе приходится соединять десятки таблиц для получения результата. А JOIN является прямой аналогией навигации. И в этом случае РМД проигрывает ОБД из за наличия ограничений в модели данных и как следсвие - из за возростания колличества этих JOIN. Тоесть "автоматическая" навигация в РБД фактически приводит к усложнению запросов.

mirВ ОСУБД мы довольно часто (для сколько-нибудь нетривиальных случаев) вынуждены "брать штурвал в руки" и вести корабль по извилистым каналам.
В нетривиальных случаях в РСУБД приходится выруливать из лабиринтов JOIN между сотнями таблиц, наличие которых оправданно исключительно ограничениями реляционной модели.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33243246
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вот ведь интересный вопрос: является ли на самом деле JOIN аналогом навигации? Смею утверждать, что ставить здесь знак эквивалентности не верно. Действительно, существуют частные случаи использования JOIN, которые во многом похожи на использование навигации, но в общем случае - JOIN не эквивалентен навигации.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33243290
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey RovdoА давайте разберемся, зачем вообще нужны средства автоматического обновления указателей.
Указатели в сетевых системах поддерживали связи. Типичный узел мог иметь например указатели на:
-родителя,
-первую дочку,
-соседа слева,
-соседа справа.
При запросе пользователем операции "Добавить дочку Z в начало набора дочек родителя X" СУБД брала на себя все необходимые вычисления указателей в т.ч. перестроение цепочки уже имеющихся дочек.
Правильно ли я понимаю, что те ОО системы, о которых вы говорите, оставляют все эти заботы за пользователем?
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33243337
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shuklin В реальной жизни же в запросе приходится соединять десятки таблиц для получения результата. А JOIN является прямой аналогией навигации. И в этом случае РМД проигрывает ОБД из за наличия ограничений в модели данных и как следсвие - из за возростания колличества этих JOIN. Тоесть "автоматическая" навигация в РБД фактически приводит к усложнению запросов.
В нетривиальных случаях в РСУБД приходится выруливать из лабиринтов JOIN между сотнями таблиц, наличие которых оправданно исключительно ограничениями реляционной модели.
В случае эквисоединений действительно - навигационная система быстрее отработает указатель чем реляционная найдет запись даже через индексы.
Однако возможности JOIN неизмеримо шире. Более того, мы оставляем за системой даже вопрос а с какой таблицы начать поиск. Так что аналогией и то не совсем прямой, является только один вид JOINов.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33244439
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey RovdoВот ведь интересный вопрос: является ли на самом деле JOIN аналогом навигации? Смею утверждать, что ставить здесь знак эквивалентности не верно. Действительно, существуют частные случаи использования JOIN, которые во многом похожи на использование навигации, но в общем случае - JOIN не эквивалентен навигации.

Согласен, что формальной эквивалентности нет. Однако в общесмысловом плане прямая навигация очень близка к outer join

причем если взять ОБД с мягкими указателями, то близка не только по функции но и по реализации - и там и там будет аналог поиска ключа в индексе, хэш таблице или в другой структуре позволяющей провести поиск за время, не зависимое от колличества записей/объектов в БД.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33244479
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelRПравильно ли я понимаю, что те ОО системы, о которых вы говорите, оставляют все эти заботы за пользователем?

Буду говорить за свою ООБД.
Разумеется у пользователя забот с этим нет.

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

Так как база объектная, и объекты реализуются на C# для платформы .NET то деревья на основе parent-child связей пользователь может создовать из объектов собственных классов в том виде, который необходим для решения данной задачи.

Каждый объект имеет свой ID. После присвоения этого ID объекту этот ID не изменяется на протяжении жизни объекта. При этом запуск и остановка приложения или ядра БД на этот ID уже не влияет. Этот ID нужно считать указателем на объект, хотя на самом деле это не указатель а номер узла в дереве индексов. Дерево 3х уровневое, и поиск реального указателя на объект по его ID проводится за 3 операции выборки узла индекса.

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

Например
Код: plaintext
1.
IConnector childObjectConnector = parentObjectConnector.AttachConnector(objectID);
object childObjectInstance = childObjectConnector.Component;

В связи с этим, в моей реализации для .NET разработчик будет иметь некоторое неудобство. В место или дополнительно к реальным указателям на .NET объекты в Fields придется хранить и эти ID.

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

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

Граф объектов управляется посредсвом АПИ. Рядовому разработчику лезть в детали реализации индексов, деревьев и узлов графа вовсе не обязательно. Тем более что вся низкоуровневая механика сделана на C а пользовательские объекты реализуются на C#
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33244822
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shuklinВаш тезис верен только в лабораторных условиях. В реальной жизни же в запросе приходится соединять десятки таблиц для получения результата. А JOIN является прямой аналогией навигации. И в этом случае РМД проигрывает ОБД из за наличия ограничений в модели данных и как следсвие - из за возростания колличества этих JOIN. Тоесть "автоматическая" навигация в РБД фактически приводит к усложнению запросов. [quot shuklin]Родной мой, я-то как раз практик, что позволяет мне усомниться именно в вашем практическом опыте. Во-первых, соединения десятков таблиц крайне редки. Во-вторых, JOIN не является аналогией навигации, ни прямой, ни непрямой. Вы уже не впервые какие-то высказывания делаете, которые раз за разом выдают ваше невежество.

[quot shuklin]В нетривиальных случаях в РСУБД приходится выруливать из лабиринтов JOIN между сотнями таблиц, наличие которых оправданно исключительно ограничениями реляционной модели.Очередной набор из безосновательных и невежественных утверждений. Во-первых, JOIN между сотнями таблиц встречается только в воспаленном сознании. Либо при банальном неумении работать, что опять же характерно для воспаленного сознания.
Во-вторых, наличие таблиц в реляционной модели -- это ее имманентное свойство, а не ее "ограничение". Ваша последняя фраза по отсутствию смысла просто бьет все рекорды.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33244825
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Парадон, перепосылаю.
shuklinВаш тезис верен только в лабораторных условиях. В реальной жизни же в запросе приходится соединять десятки таблиц для получения результата. А JOIN является прямой аналогией навигации. И в этом случае РМД проигрывает ОБД из за наличия ограничений в модели данных и как следсвие - из за возростания колличества этих JOIN. Тоесть "автоматическая" навигация в РБД фактически приводит к усложнению запросов. Родной мой, я-то как раз практик, что позволяет мне усомниться именно в вашем практическом опыте. Во-первых, соединения десятков таблиц крайне редки. Во-вторых, JOIN не является аналогией навигации, ни прямой, ни непрямой. Вы уже не впервые какие-то высказывания делаете, которые раз за разом выдают ваше невежество. Далее, наличие "ограничений в РМД" само по себе ничего не значит. Что за ограничения? Есть ли они? Вредны ли они или полезны? Прекратите постулировать, начните доказывать.
Ну, и фраза ""автоматическая" навигация в РБД фактически приводит к усложнению запросов" опять выдает, что вы этих запросов не писали, с реальными системами не работали.
shuklinВ нетривиальных случаях в РСУБД приходится выруливать из лабиринтов JOIN между сотнями таблиц, наличие которых оправданно исключительно ограничениями реляционной модели.Очередной набор из безосновательных и невежественных утверждений. Во-первых, JOIN между сотнями таблиц встречается только в воспаленном сознании. Либо при банальном неумении работать, что опять же характерно для воспаленного сознания.
Во-вторых, наличие таблиц в реляционной модели -- это ее имманентное свойство, а не ее "ограничение". Ваша последняя фраза по отсутствию смысла просто бьет все рекорды.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33245114
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
К сожалению, г-н shuklin, занявшись разработкой ООСУБД не посчитал нужным детально изучить историю развития и практику использования этих систем в мире. Поэтому раз за разом наступает на те же грабли, на которые наступали разработчики ООСУБД последние 15 лет. Но эти грабли не прошли для них даром, а вот у Cerebrum все еще впереди.

Неверно отождествлять навигацию с JOIN и неверно сопоставлять запросы на декларативных языках SQL и OQL (или OQL-подобных). На мой взгляд нужно понять одну простую вещь - есть доступ к данным по значению, а есть доступ по ссылке. И вот в РСУБД существует только доступ по значению. Т.е. мы ищем данные, на значения которых наложены определенные условия (и операция JOIN ON в этом смысле ничем не отличается от SELECT WHERE). В ООСУБД существует и вторая возможность - доступ по ссылке. Вот его то и принято называть навигацией. Но чтобы осуществлять навигацию нам нужна "точка входа", т.е. мы должны найти некий корневой объект и далее следовать по ссылкам. Чтобы найти корневой объект в ООСУБД может использоваться либо именование объектов, либо поиск по значению (т.е. мы сначала ищем этот корневой объект, а потом занимаемся навигацией).

Особенности РСУБД однозначно стимулируют разработчиков к минимизации (в пределах разумного) числа таблиц в базе данных и всяческого избежания ситуаций с сотнями связанных таблиц и большим числом JOIN в запросах. Именно поэтому правы те, кто говорит, что ситуация с сотней JOIN практически нереальна в жизни. Такая база окажется просто не работоспособной, а разработчика надо гнать в шею. Но ведь нужно понимать, что это все не от хорошей жизни. Именно с использованием ООСУБД можно забыть о проблеме упрощения модели данных и создавать системы с сотнями, тысячами и более классов и связанных объектов. Просто это другая идеология и другие принципы работы (преимущественно пресловутая "навигация"), которые, разумеется, применимы только в системах определенных видов и оказываются неудобны в других системах.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33245167
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ага, серебрянная пуля [с пониманием]
Черт, какой смайлик выбрать, чтобы изобразить Пинноккио ?
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33245549
Dimonische
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)Ага, серебрянная пуля [с пониманием]
Черт, какой смайлик выбрать, чтобы изобразить Пинноккио ?

Друх не писал на объектных языках )

Код внизу - начальный, примерно независит от того какая база:

Сonnection conn = ...;
ResultSet result = conn.executeQuery("SELECT FROM Orders o WHERE o.suppyDate < '2005-11-03'") ;

Пусть надо получить, ( одна из ДЕСЯТКА последующих операций с Ордером),
список уникальных товаров в заказе.

В моем понимании навигация это следуещее (в Java формате например):

HashSet set = new HashSet();
while(result.next())
{
Order o = (Order)result.nextObject();
for (int i = 0; i < o.getOrderLines().length; i++ ) {
set.add(o.getOrderLines() .getCommodity());
}
}

Т.е. взятие дочерних обектов "просто так" - o.getOrderLines(), getCommodity()

На чистом SQL надо было бы сделать следуещее:

ResultSet result = conn.executeQuery("SELECT DISTINCT c.* FROM Orders o LEFT JOIN OrderLines l ON l.orderId = o.id LEFT JOIN Commodity c ON l.commodityId = c.id WHERE o.suppyDate < '2005-11-03'") ;

HashSet set = new HashSet();

while(result.next())
{
Commodity c = (Order)result.nextObject();
set.add( c );
}

т.е. любые объекты (ну, наборы полей..) надо брать из базы запросами.

С точки зрения программистов, слишком много неудобств.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33245581
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гмм не вижу неудобств. И что есть объектные языки ?
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33245725
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
To Dimonische

А кто мешает запихнуть этот селект в метод getCommodity? Или Вы думаете, что этот метод просто так, как фокусник из рукава, достаёт требуемую информацию?
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33245852
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DimonischeСonnection conn = ...;
ResultSet result = conn.executeQuery("SELECT FROM Orders o WHERE o.suppyDate < '2005-11-03'") ;

Пусть надо получить, ( одна из ДЕСЯТКА последующих операций с Ордером),
список уникальных товаров в заказе.

В моем понимании навигация это следуещее (в Java формате например):

HashSet set = new HashSet();
while(result.next())
{
Order o = (Order)result.nextObject();
for (int i = 0; i < o.getOrderLines().length; i++ ) {
set.add(o.getOrderLines() .getCommodity());
}
}
Это навигация уже после получения данных из базы. Коренное отличие этого стиля - перераспределение нагрузки с сервера БД на приложение, неважно написанно на java или Коболе. Иногда это кстати полезно.
Вопрос же касался именно навигационных запросов к БД. Типа
Код: plaintext
conn.ADD_FIRST_CHILD (myOrder,  myLine, 'OrderLinesList')
где 'OrderLinesList' - имя связи, раскраска, по которой идет навигация. Т.е какие-то ОО СУБД предоставляют такой навигационный интерфейс или это дело приложения?
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33245860
Dimonische
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел Воронцов To Dimonische

А кто мешает запихнуть этот селект в метод getCommodity? Или Вы думаете, что этот метод просто так, как фокусник из рукава, достаёт требуемую информацию?

Э, Павел, вы издеваетесь наверное?

Можно запихнуть селект. Только таких классов у меня в программе ~ 500. И методов по 5 на класс. Ту факинг экспенсив.

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

Этот же метод реализованный базон данных, именно делает ПРЯМУЮ навигацию. По моему так.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33245877
Dimonische
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelR
Код: plaintext
conn.ADD_FIRST_CHILD (myOrder,  myLine, 'OrderLinesList')
где 'OrderLinesList' - имя связи, раскраска, по которой идет навигация. Т.е какие-то ОО СУБД предоставляют такой навигационный интерфейс или это дело приложения?

Насколько я понимаю, именно это пример как реляционщик понимает объетную базу. Не обижайтесь пожалуйста. В объектной базе по хорошему просто пишут
Код: plaintext
myOrder.addOrderLine( myLine )
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33245888
Dimonische
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimonische ModelR
Код: plaintext
conn.ADD_FIRST_CHILD (myOrder,  myLine, 'OrderLinesList')
где 'OrderLinesList' - имя связи, раскраска, по которой идет навигация. Т.е какие-то ОО СУБД предоставляют такой навигационный интерфейс или это дело приложения?

Насколько я понимаю, именно это пример как реляционщик понимает объетную базу. Не обижайтесь пожалуйста. В объектной базе по хорошему просто пишут
Код: plaintext
myOrder.addOrderLine( myLine )


Или если надо конкретно на первую позицию:

Код: plaintext
1.
2.
List orderLines = myOrder.getOrderLines();
orderLines.add(myLine , 0 );
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33245993
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DimonischeЭ, Павел, вы издеваетесь наверное?Отнюдь. Вероятно просто не понимаю о чём речь и пытаюсь задать наводящие вопросы. DimonischeМожно запихнуть селект. Только таких классов у меня в программе ~ 500. И методов по 5 на класс. Ту факинг экспенсив.И что? Вы не пишите факинг реализацию для своих факин экстенсив нумбер оф мефодс? Что значит этот самыё метод, который Вы написали, что за ним стоит ? DimonischeЯ уже не говорю о том, что выполнять такие запросы в цикле - за это я лично уволил человека 2 года назад. Не за конкретно это конечно, но просто это стало последней каплей.В некоторых обстоятельствах я поступил бы точно так же. DimonischeЭтот же метод реализованный базон данных, именно делает ПРЯМУЮ навигацию. По моему так.Что значит "БД делает прямую навигацию"? Что это означает ?
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33246001
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
хоть убей не вижу чем получение значения по ссылке отличается от получения значения по ключу (для разработчика, а не для СУБД). Чем сслыка не ключ?
и соответственно такая запись через точку для меня это просто как некая другая реализация SQL. Надо признать что то-то в этом есть.

Dimonische

Или если надо конкретно на первую позицию:

Код: plaintext
1.
2.
List orderLines = myOrder.getOrderLines();
orderLines.add(myLine , 0 );

всё, дальше не надо
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33246170
Dimonische
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел ВоронцовЧто значит "БД делает прямую навигацию"? Что это означает ?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Сonnection conn = ...;
ResultSet result = conn.executeQuery("SELECT FROM Orders o WHERE o.suppyDate < '2005-11-03'") ;

HashSet set = new HashSet();
while(result.next())
{
      Order o = (Order)result.nextObject();
      for (int i =  0 ; i < o.getOrderLines().length; i++ ) {
          set.add(o.getOrderLines().getCommodity());
      }
}


Так, основной вопрос, а что происходит при o.getOrderLines()?

В яве есть такое понятие - Bytecode instrumentation.
Это значит, что код класса, который вернулся откуда либо (в нашем случае conn.executeQuery) поменян на уровне инструкций виртуальной машины Ява.

Варианты

1. o.getOrderLines() может через спрятанную ссылку (куторую добавили при возврате класса Order скрытым от нас образом внутри executeQuery) вызвать сервер Объектной базы и по ссылке получить список OrderLine (очень похоже на скрытый SQL)

2. OrderLines задекларированы как члены домена Order, и потому хранятся "вместе с классом Order" и при запросах всегда возвращаются.

3. В случае, Commodity очевидно не находтся в домене Order, посему добавляется дополнительная конфигурация типа "функция getOrderLines() класса Order кэширует связь типа Commodity". Тогда получается что-то типа

Код: plaintext
conn.executeQuery("SELECT FROM Orders o WHERE o.suppyDate < '2005-11-03'", new String[] {ORDER.ORDER_LINE.COMMODITY} );

Тогда сервер БД будет уже возвращать по функции getCommodity кэшированные товары
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33246267
Dimonische
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimonische

3. В случае 2, Commodity очевидно не находится в домене Order, посему добавляется дополнительная конфигурация типа "функция getOrderLines() класса Order кэширует связь типа Commodity". Тогда получается что-то типа

Код: plaintext
conn.executeQuery("SELECT FROM Orders o WHERE o.suppyDate < '2005-11-03'", new String[] {ORDER.ORDER_LINE.COMMODITY} );

Тогда сервер БД будет уже возвращать по функции getCommodity кэшированные товары

Да, еще нюанс. Если
Код: plaintext
new String[] {ORDER.ORDER_LINE.COMMODITY}
не указано, то метод getCommodity() полезет брать объект по commodityId. Это все равно эффективней, т.к. все объектные ид специфичны для каждой объектной базы и "прямо указывают на сектор на диске откуда считать данные", ессно если данные не в памяти. В отличие от идентификатора 100001.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33246857
Andreww
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Dimonische

>>Так, основной вопрос, а что происходит при o.getOrderLines()?

>>В яве есть такое понятие - Bytecode instrumentation.
Это значит, что код класса, который вернулся откуда либо (в нашем случае conn.executeQuery) поменян на уровне инструкций виртуальной машины Ява.

А если не Java ? Если .NET ? Там уже другой байт код, сл-но менять надо по-другому. Если работаем с Delphi7 или (о ужас!) VB6, там вообще native code, особо ничего не поменяешь. Т.е. получается, что «объектные» базы напрямую зависят от технологии разработки клиента, а может это и не базы в виде Клиент - Сервер, а просто некоторый инструментарий для конкретной платформы (нап. Java)?
Или эти «объектные базы» настолько круты, что у них есть интерфейс под большинство современных средств разработки и этот инструментарий поспевает за бесконечными обновлениями платформ ?
Как-то грустно звучит :( Т.е. если вляпались в «объект», будем тащить их до конца как до сих пор тащут COBOL и IMS. Безрадостно как-то. Oracle7-8-9-10g «выставляет "наружу" свой API и работай с ним из любой среды(хошь те Fortran хошь те VB), т.к. на уровне инструкций для подстройки платформы ничего «менять» не надо.


>Варианты

>1. o.getOrderLines () может через спрятанную ссылку (куторую добавили при возврате класса >Order скрытым от нас образом внутри executeQuery) вызвать сервер Объектной базы и по >ссылке получить список OrderLine (очень похоже на скрытый SQL)

«Добавили ссылку» кто ? Если сервер, то вопросов нет. Только на что ссылаемся то? Мы вроде как в многопользовательской среде (если я правильно всё понял) и если после получения экземпляра списка OrderLines ссылкИ на OrderLine поменяются и будут показывать куда ? Стрёмная вещь ссылки да ещё и в распределённой многопользовательской среде.

>2. OrderLines задекларированы как члены домена Order, и потому хранятся "вместе с >классом Order" и при запросах всегда возвращаются.

Если хранятся вместе, тогда вопросов нет. Но это может привести к вырождению БД в файловую систему или в систему типа «Всё в одной таблице». Там с блокировочками накладно-с.

Вобщем-то, если наплевать на зависимость от платформы, можно и так работать, но вся фигня в том, что нужно не только получать Order и OrderLines. Это вобщем-то настолько тривиально сделать, что можно и с БД особо не заморачиваться. К сожалению, кроме всяких Интернет Магазинов и небольших складов, есть всякая аналитика и отчёты. Мерзопакастнейшая вешь.
Т.е. нужны всякие суммы, средние, макс. мин, группировки немыслимые, подзапросы нехилой вложенности и прочие «радости жизни».
Вот тут всё будет намного сложнее чем :

HashSet set = new HashSet();
while(result.next())
{
Order o = (Order)result.nextObject();
for (int i = 0; i < o.getOrderLines().length; i++ ) {
set.add(o.getOrderLines().getCommodity());
}
}

Потому как никакой МЕГАСЕРВЕР, не догадается как нужно getCommodity «поменять», тут язык запросов нужен и мощный, что бы на каждый отчёт всю базу с сервера не выкачивать, к языку запросов ещё оптимизатор необходим, что бы соотнести план выполнения с текущим состоянием базы, и без замкнутой реляционной теории у которой все операции производятся над множествами построить такой оптимизатор едва ли получится. Ещё хорошо, что бы отчёты целостные были, т.е. изоляцию обеспечить, хотя бы минимальную.

Попробуйте решить простенький пример, который у нас давнооо был
/topic/9021&pg=19#804604

С интересом взгляну на решение в навигационной среде. Был тут один ШПЕЦИАЛИСТЪ, объееееектный, аж жуть, только решения от него никто так и не увидел.

Потому и сдохли сетевые и иерархические СУБД в которых порядок перемещения по данным определялся программистом и зависел от физического размещения и состава данных (при появлении нового индекса надо вырисовывать новый способ получения данных который бы учитывал этот индекс, иначе никакого выигрыша навигация-то ручная и вбита разработчиком когда индекса ещё не было) .
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33246922
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimonische ModelR
Код: plaintext
conn.ADD_FIRST_CHILD (myOrder,  myLine, 'OrderLinesList')
где 'OrderLinesList' - имя связи, раскраска, по которой идет навигация. Т.е какие-то ОО СУБД предоставляют такой навигационный интерфейс или это дело приложения?

Насколько я понимаю, именно это пример как реляционщик понимает объетную базу. Не обижайтесь пожалуйста. В объектной базе по хорошему просто пишут
Код: plaintext
.addOrderLine( myLine )

Так знал бы не спрашивал. Однако так по-моему пишут просто в Java. Где тут написано что это операция с БД, и с каким именно инстансом (коннектом) и что myLine теперь также должна ссылаться на myOrder , что автоматически должна бы делать гипотетическая ADD_FIRST_CHILD навигационной СУБД?
И где написано, что это именно список помеченный как 'OrderLinesList', ибо тот же myLine может входить в тот же myOrder по иным причинам.

Один дурак может задать столько вопрсов...
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33246986
Dimonische
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andreww2 Dimonische
А если не Java ? Если .NET ? Там уже другой байт код, сл-но менять надо по-другому. Если работаем с Delphi7 или (о ужас!) VB6, там вообще native code, особо ничего не поменяешь. Т.е. получается, что «объектные» базы напрямую зависят от технологии разработки клиента, а может это и не базы в виде Клиент - Сервер, а просто некоторый инструментарий для конкретной платформы (нап. Java)?
[quot]

Андрей, 2 вещи:

1. Байт код клиента меняет клиентский драйвер, который может быть на Яве/С#/языки с байткодом (тогда там bytecode instrumentation), С/C++/компилируемые языка (компиляция нового класса). На сервере данные хранятся в серверном виде, не зависимым от языка доступа.

2. Когда вы что-то говорите насмешливым тоном, вы должны быть мегагуру и быть уверенным том что Вы говорите. Иначе получится конфуз. Как сейчас. Когда совершенно очевидно, что вы не знаете что такое JDBC/ODBC, клиентские драйвера и пр.

[quot Andreww]

«Добавили ссылку» кто ? Если сервер, то вопросов нет. Только на что ссылаемся то? Мы вроде как в многопользовательской среде (если я правильно всё понял) и если после получения экземпляра списка OrderLines ссылкИ на OrderLine поменяются и будут показывать куда ? Стрёмная вещь ссылки да ещё и в распределённой многопользовательской среде.



Видимо, Вы не знаете что такое транзакции.


Andreww
>2. OrderLines задекларированы как члены домена Order, и потому хранятся "вместе с >классом Order" и при запросах всегда возвращаются.

Если хранятся вместе, тогда вопросов нет. Но это может привести к вырождению БД в файловую систему или в систему типа «Всё в одной таблице». Там с блокировочками накладно-с.


Откровенно говоря, это проблема разработчиков объектной БД. Сдается мне, у Вас нет такого опыта.

Andreww

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



Никто не против наличия подобного языка запросов в ООБД.
Реч идет о том, что аналитиков, которые делают SQL к базе данных (в центральном офисе ТНК например) - 25 человек. А людей, которые открывают Вебстранички или ЮАЙ - 1500 человек. И они даже не знают слова SQL. Зато для них функциональность делать на объектных базах быстрее. Потому что люди сами оперируют объектами - "а вот на это страничке откройте Заказ, а на следующей табе список Накладных, дайте возможность накидать накладные на заказ."
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33247058
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimonische, Вы это, задачку то, которую привёл Andreww решили бы сначала. Сдаётся мне что его насмешливый тон имеет под собой основания
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33247076
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
и вообще у вас несколько однообразная и недостаточно глубокая аргументация:

...Когда совершенно очевидно, что вы не знаете что такое JDBC/ODBC, клиентские драйвера и пр.
...Видимо, Вы не знаете что такое транзакции.
...это проблема разработчиков объектной БД. Сдается мне, у Вас нет такого опыта.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33247083
Dimonische
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuperDimonische, Вы это, задачку то, которую привёл Andreww решили бы сначала. Сдаётся мне что его насмешливый тон имеет под собой основания

Andrewwнужно сделать выборку для отделений (dep_id) 100 и 200 для штатов (state) 'CA', 'UT', 'NY', 'AZ' заказов всех покупателей (emp_lname) с перечислением даты заказа (start_date), суммы заказа (salary) и нарастающего итога по суммам заказов для каждого отделения отдельно согласно сортировке по датам заказов


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SELECT dept_id, emp_lname, start_date, salary,
  SUM(salary) OVER (PARTITION BY dept_id
    ORDER BY start_date
    RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS "Sum_Salary"
FROM employee
WHERE state IN ('CA', 'UT', 'NY', 'AZ') AND dept_id IN ('100', '200')
ORDER BY dept_id, start_date;

Написать что надо, подобный запрос?

Пожалуйста: (пример без специфики видимо Оракла в виде UNBOUNDED PRECEDING AND CURRENT ROW)

SELECT dept_id, emp_lname, start_date, salary,
SELECT SUM(salary) FROM Employee e WHERE e.startDate > e.1start_date AND e.id = e1.id AS "Sum_Salary"
FROM Employee e1
WHERE e1.state IN ('CA', 'UT', 'NY', 'AZ') AND e1.dept_id IN ('100', '200')
ORDER BY e1.dept_id, e1.start_date;



Что, слишком похоже на SQL? А кто-же вам вдолбил, что нет объектных запросов?
В сад.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33247086
Dimonische
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuperи вообще у вас несколько однообразная и недостаточно глубокая аргументация:

...Когда совершенно очевидно, что вы не знаете что такое JDBC/ODBC, клиентские драйвера и пр.
...Видимо, Вы не знаете что такое транзакции.
...это проблема разработчиков объектной БД. Сдается мне, у Вас нет такого опыта.


Прокомментирую только один тезис - Видимо, Вы не знаете что такое транзакции.
Вот что писал Андрей -
Andreww
«Добавили ссылку» кто ? Если сервер, то вопросов нет. Только на что ссылаемся то? Мы вроде как в многопользовательской среде (если я правильно всё понял) и если после получения экземпляра списка OrderLines ссылкИ на OrderLine поменяются и будут показывать куда ? Стрёмная вещь ссылки да ещё и в распределённой многопользовательской среде.


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

В сад.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33247120
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andreww
Попробуйте решить простенький пример, который у нас давнооо был
/topic/9021&pg=19#804604


Пример немного странный. Поле emp_lname думаю описывает имя сотрудника, а не покупателя, Salary - это зарплата, а не сума заказа. Столбец Sum_salary не имеет практического смысла (вернее смысл имеют только два значения из всего столбца).
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33247127
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimonische, вот Вы привели решение и какая картина видится из сада, какой напрашивается вывод? Только такой: т.е. получается на словах, потрындеть - вам эта навигация ну жуть как нужна, а вот как до дела доходит - то без неё задачи решаете.

Насчет транзакций
Что происходит в РСУБД в случае идентификаторов? Ответ ничего - изоляция транзакций не просто так придумана. Или может автор думает что в объектных базах не транзакций? Так надо так было и спросить.
Чесно говоря, не понял причем они тут. Говорилась что есть разница между ссылкой и идентификатором, который представляет собой некую неизменную абстракцию. Не нужно открывать транзакцию каждый раз при чтении идентификатора. А вот со ссылками похоже придётся
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33247296
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мысли по поводу навигации...
Мысль1. Можно вспомнить статью Дейта где он рассуждает о существуенных конструкциях. Соответсвенно, возникает желанеи обозвать навигацией любое использование конструкция , не являющихся отношениями, как существуенных. Я с ним согласен.

Мысль2 Однако (это показано в НМРсорри, но тут уже я на белом коне :)) определение некоторых типов может рассматриваться как определение множества взаимосвязанных переменных отношений. То есть если мы определим отношение a и b явно , то мы конечно должны делать явный JOIN. Однако - как туту неоднократно намекал, SergSuper, выражение x.y тоже мона рассмтаривать как исключительно реляционную операцию - этакий неяный JOIN. Возможность этой неявности обуславливаеться тем, что ранее эти x и y были определные как составные части структуры этого типа (причем сложноть структуры никуда не делась - она отражена в сложных именах переменных отношений и их атрибутов)

Мысль3 Ни в коем случае нельзя забывать о том, как реализованы объекты. Все ОО-псевдоапологеты, говоря, что ОО-системы это дескать быстро, забывают о том что быстрыми является не какие то ОО-принципы, а адресуемая память... ООязыки и вслед за ними ООСУБД возникли как средство упарвления адресуемыми устроствами хранения - 1)ОЗУ и 2)файлы с прямым доступом. Ссылки при этом отображаютя в адреса. Соответсвенно, как сказал Andreww, "перемещения по данным зависит от физического размещения". При этом физически в памяти они размещены так-то на лиске по другому. Возникает вопрос синхронизации двух памятей. Потом, что бы объект мог пермещатся физичеки, но ссылка бы при этом не менялась, делают мягкие ссылки. Потом возникает проблема поиска объктов по атрибутам и доступа к этим объектам. Они - поклонники ОО"СУБД" - выдумают какие нибудь специальные индексы (я в этом уверен) если ужже не выдумали. Но ведь все это - таблица магких ссылок, таблица синхрноизации ОЗУ и диска, все эти индексы, это все - таблицы! - и чем дальше , тем их становиться больше! И выясняется, что(ежели подумать) что прямой доступ у файлу - это конечно быстро, но что бы найти данные на диске , так это надо в трех таблица концы свести...неявно конечно, но надо....А вам не кажется, чт оежели по этому пути идти далье, то можно прийти в ситуации, когда все данные таки будут как-то где-то представлены в каких то таблицах? И все эти таблицы решают одну задачу , а именно - сделать данные независимыми от их физического зранения. Так не прощели не ковыряться в этом, а воспользоваться тем, что уже как тридцать лет сделано? Как воспользоваться- я знаю, но никому не скажу :) Рел системы представляют собой независимую от физического размещения систему хранения данных. Создана мощная ассоцативная(по способу доступа к данным) машина, осталось для него сделать ОО интерпертатор - кто первый?
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33247384
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimonische Павел ВоронцовЧто значит "БД делает прямую навигацию"? Что это означает ?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Сonnection conn = ...;
ResultSet result = conn.executeQuery("SELECT FROM Orders o WHERE o.suppyDate < '2005-11-03'") ;

HashSet set = new HashSet();
while(result.next())
{
      Order o = (Order)result.nextObject();
      for (int i =  0 ; i < o.getOrderLines().length; i++ ) {
          set.add(o.getOrderLines().getCommodity());
      }
}


Так, основной вопрос, а что происходит при o.getOrderLines()?

В яве есть такое понятие - Bytecode instrumentation.
Это значит, что код класса, который вернулся откуда либо (в нашем случае conn.executeQuery) поменян на уровне инструкций виртуальной машины Ява.

Варианты

1. o.getOrderLines() может через спрятанную ссылку (куторую добавили при возврате класса Order скрытым от нас образом внутри executeQuery) вызвать сервер Объектной базы и по ссылке получить список OrderLine (очень похоже на скрытый SQL)

2. OrderLines задекларированы как члены домена Order, и потому хранятся "вместе с классом Order" и при запросах всегда возвращаются.

3. В случае, Commodity очевидно не находтся в домене Order, посему добавляется дополнительная конфигурация типа "функция getOrderLines() класса Order кэширует связь типа Commodity". Тогда получается что-то типа

Код: plaintext
conn.executeQuery("SELECT FROM Orders o WHERE o.suppyDate < '2005-11-03'", new String[] {ORDER.ORDER_LINE.COMMODITY} );

Тогда сервер БД будет уже возвращать по функции getCommodity кэшированные товарыТо есть (подводим итог) реализацию метода извлечения данных из хранилища Вы хотите переложить на сервер. Благое желание. Только непонятно зачем при этои диктовать серверу как он должен хранить данные? Дело в том, что СУБД предоставляет Вам множество способов доступа к данным, Вы вольны выбрать тот или иной, а сервер будет заботиться об их хранении и целостности. Как Вы устроите у себя процедуру извлечения нужной информации - дело Ваше. Можно каженный раз писать запросики и добывать то , что нужно, когда нужно. Можно написать объектную обвязку, кеширующую нужную информацию о тех же заказах, то есть прячущю эти самые запросы от программиста за удобным интерфейсом. Можно (в Оракле например) напложить кучку объектных типов, нарисовать объектные представления и доставать сразу всё одним запросом и не морочиться дополнительными запросами с клиента. Можно (много где) написать обвязку хранимых процеду и/или функций на сервере, возвращающих всё что нужно в нужном виде. Можно сочетать и то и другое и пятое и десятое. И данные будут таки храниться в самосогласованном виде - без разницы сколько приложений эту базу насилует и какими методами. СУБД не для приложения создаётся, а для хранения, манипулирования и отслеживания целостности данных, нужных приложению. Они же (данные) могут пригодиться и другому приложению. То, о чём Вы тут пишите - ограничение способов доступа. А заодно ещё и дополнительные требования к хранению, что ещё хуже.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33247428
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimonische
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SELECT dept_id, emp_lname, start_date, salary,
  SUM(salary) OVER (PARTITION BY dept_id
    ORDER BY start_date
    RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS "Sum_Salary"
FROM employee
WHERE state IN ('CA', 'UT', 'NY', 'AZ') AND dept_id IN ('100', '200')
ORDER BY dept_id, start_date;

Написать что надо, подобный запрос?

Пожалуйста: (пример без специфики видимо Оракла в виде UNBOUNDED PRECEDING AND CURRENT ROW)

SELECT dept_id, emp_lname, start_date, salary,
SELECT SUM(salary) FROM Employee e WHERE e.startDate > e.1start_date AND e.id = e1.id AS "Sum_Salary"
FROM Employee e1
WHERE e1.state IN ('CA', 'UT', 'NY', 'AZ') AND e1.dept_id IN ('100', '200')
ORDER BY e1.dept_id, e1.start_date;


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

Не серьезный подход
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33247783
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
U-gene
... прямой доступ у файлу - это конечно быстро, но что бы найти данные на диске , так это надо в трех таблица концы свести...неявно конечно, но надо....

Мне кажется у вас неверное представление о работе типичной ООСУБД. Раскажите ка по-подробнее, где вы там три таблицы увидели.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33249484
Andreww
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Dimonische

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

>>Андрей, 2 вещи:

>>1. Байт код клиента меняет клиентский драйвер, который может быть на Яве/С#/языки с байткодом (тогда там bytecode instrumentation),

Хммм. Т.е. вы всё-таки уверены, что именно КЛИЕНТСКИЙ код ИЗМЕНЯЕТСЯ. Т.е. (вспоминая пример в посте № 1837003, я уж не буду его весь приводить, желающие могут посмотреть), set.add(o.getOrderLines().getCommodity ()) этот самый getCommodity развернётся в код который вернёт список (?) и получится что-то вроде set.add(new OrderLines(){…тут код который «сгенерировал» (!?) драйвер для конструирования объета OrderLines…})

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

>>С/C++/компилируемые языка (компиляция нового класса).

Т.е. при каждом изменении Класса в Объектной БД, я должен заново скомпилировать все клиентские приложения, или как ? Я просто пытаюсь понять ….


>>На сервере данные хранятся в серверном виде, не зависимым от языка доступа.

Это не имеет особого значения, если для компилируемых языков нужна повторная компиляция при изменениях в БД, а для платформ с VM драйвер настолько «умён», что подстраивается под любой код.


>>2. Когда вы что-то говорите насмешливым тоном, вы должны быть мегагуру и быть уверенным том что Вы говорите.

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

>>Иначе получится конфуз. Как сейчас. Когда совершенно очевидно, что вы не знаете что такое JDBC/ODBC, клиентские драйвера и пр.

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

>>Видимо, Вы не знаете что такое транзакции.

ОК. Транзакции (и заметье, я не утверждал что кто-то чего-то не знает, просто спрашивал), я действительно не представляю как они используются в объектных СУБД.
При получении объекта Order мы должны заблокировать все входящие в него объекты OrderLine т.к. в Order есть ссылки (ваши слова – «может через спрятанную ссылку которую добавили при возврате класса Order скрытым от нас образом внутри executeQuery» ?) если у сервера блокировочный механизм, или нужно сохранить где-то версии в случае версионника, что бы эти ссылки были действительными, но тут же возникает проблема , а что если у OrderLine есть ссылки на объекты SubLine, например? Их надо согласовывать ? И зачем мне чего-то блокировать или версии оставлять, если я беру Order и работаю только с ним ? В случае РСУБД, как вам уже обяснили в посте № 1838679 в случае чтения идентификатора, никаких действий по согласованности не требуется, т.к. идентификаторы в этом случае это ничего не значащий суррогат с ним работает разработчик он за него и отвечает, а вот «спрятаные» ссылки должны разрешаться БЕЗ ВМЕШАТЕЛЬСТВА РАЗРАБОТЧИКА (на то они и спрятанные) и иного механизма обеспечения согласованности кроме блокировки или хранения старой версии пока нет.

Дальше.

>2. OrderLines задекларированы как члены домена Order, и потому хранятся "вместе с классом Order" и при запросах всегда возвращаются.

>Откровенно говоря, это проблема разработчиков объектной БД. Сдается мне, у Вас нет такого опыта.

Конечно нет ! Но я пытаюсь у вас про них узнать подробнее. Вы предлагаете решение ("OrderLines задекларированы как члены домена Order"), я вам рассказываю к чему это может привести, а вы в ответ – «это проблема разработчиков объектной БД. Сдается мне, у Вас нет такого опыта», странно как-то, не находите ? Вы сказали как, я сказал чем мне это не нравится, а мне в ответ «опыта нет». :-(

>Реч идет о том, что аналитиков, которые делают SQL к базе данных (в центральном офисе ТНК например) - 25 человек.

Ну тем хуже для ТНК. Я до сих пор не встречал аналитиков (бизнес-аналитиков) у которых SQL в качестве инструмента. Всё больше пакеты всякие для OLAP. А какой там внутри xyzQL это аналитиков мало волнует, им срезы всякие нужны, по кварталам, по месяцам, по-подразделниям и прочее. Прибыль и т.д. Им решения принимать и текущее состояние дел видеть надо. С ужасом представляю как финдиректор, что бы посмотреть сумму прибыли за квартал по подразделениям открывает SQLPlus и начинает писать SELECT …

>А людей, которые открывают Вебстранички или ЮАЙ - 1500 человек. И они даже не знают слова SQL. Зато для них функциональность делать на объектных базах быстрее. Потому что люди сами оперируют объектами - "а вот на это страничке откройте Заказ, а на следующей табе список Накладных, дайте возможность накидать накладные на заказ."

Странный подход :( Т.е. если у вас заказчик потребует реализовать возможность А и возможность Б вы скажете, берёмся за возможность «Б« а «А», ну как-нибудь потом, она всего-то нужна для 10 человек….

Теперь про задачу :

Условие вы видели –

нужно сделать выборку для отделений (dep_id) 100 и 200 для штатов (state) 'CA', 'UT', 'NY', 'AZ' заказов всех покупателей (emp_lname) с перечислением даты заказа (start_date), суммы заказа (salary) и нарастающего итога по суммам заказов для каждого отделения отдельно согласно сортировке по датам заказов

>Написать что надо, подобный запрос?

Да нет. Я хотел увидеть решение в навигационной среде, ну да ладно.

>Пожалуйста: (пример без специфики видимо Оракла в виде UNBOUNDED PRECEDING AND CURRENT ROW)

Дальше запрос (ваш) :

SELECT dept_id, emp_lname, start_date, salary,
SELECT SUM(salary) FROM Employee e WHERE e.startDate > e.1start_date AND e.id = e1.id AS "Sum_Salary"
FROM Employee e1
WHERE e1.state IN ('CA', 'UT', 'NY', 'AZ') AND e1.dept_id IN ('100', '200')
ORDER BY e1.dept_id, e1.start_date;


Ну наверное всё-таки «>=» вместо «>» , но смысла это не меняет, т.к. не решает исходной задачи. Простым переписыванием запроса к Ораклу тут не обойтись. Я так понял, что это и есть язык запросов к ОБД ? Очень напоминает SQL из РСУБД. Та же декларативность (без навигации) и ассоциативный доступ вместо навигационого. Зачем с проверенных РСУБД на нечто непроверенное перескакивать, когда возможности у языка запросов те же самые и явных преемуществ нет?

Может для вас ОСУБД эта некоторая прослойка (вроде сервера приложений) между рел. хранилищем и ОО средой разработки ? Отсюда и запросы на SQL и «странные» требования к драйверу JDBC ?

Кстати запрос на SQL (не ваш) не совсем верен, в постановке указывалось, что нужен НАРАСТАЮЩИЙ ИТОГ ПО ПОДРАЗДЕЛЕНИЮ? Т.е. :

SELECT dept_id, emp_lname, start_date, salary,
SUM(salary) OVER (PARTITION BY dept_id
ORDER BY start_date
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS "Sum_Salary"
FROM employee
WHERE state IN ('CA', 'UT', 'NY', 'AZ') AND dept_id IN ('100', '200')
ORDER BY dept_id, start_date;
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33249826
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-gene. ООязыки и вслед за ними ООСУБД возникли как средство упарвления адресуемыми устроствами хранения - 1)ОЗУ и 2)файлы с прямым доступом. Ссылки при этом отображаютя в адреса. Соответсвенно, как сказал Andreww, "перемещения по данным зависит от физического размещения". При этом физически в памяти они размещены так-то на лиске по другому. Возникает вопрос синхронизации двух памятей. Потом, что бы объект мог пермещатся физичеки, но ссылка бы при этом не менялась, делают мягкие ссылки. Потом возникает проблема поиска объктов по атрибутам и доступа к этим объектам. Они - поклонники ОО"СУБД" - выдумают какие нибудь специальные индексы (я в этом уверен) если ужже не выдумали. Но ведь все это - таблица магких ссылок, таблица синхрноизации ОЗУ и диска, все эти индексы, это все - таблицы! - и чем дальше , тем их становиться больше! И выясняется, что(ежели подумать) что прямой доступ у файлу - это конечно быстро, но что бы найти данные на диске , так это надо в трех таблица концы свести...неявно конечно, но надо....А вам не кажется, чт оежели по этому пути идти далье, то можно прийти в ситуации, когда все данные таки будут как-то где-то представлены в каких то таблицах? И все эти таблицы решают одну задачу , а именно - сделать данные независимыми от их физического зранения. Так не прощели не ковыряться в этом, а воспользоваться тем, что уже как тридцать лет сделано?

Любопытно, что Ваш тезис верен с точностью до наоборот. Именно в РБД используют деревья индексов для решения описанных Вами проблем абстрагирования от физического хранения данных. Если взять к примеру MS-SQL то можно нарисовать в нем запрос без bookmark lookup что приведет к отсутствию работы с таблицами - использоваться будут только деревья. Так вот, зачем организовывать данные в таблицы, если реальную независимость от аппаратного хранения и реальную скорость тех же JOIN дают именно деревья и сети, родные для ОБД?

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

Статья по этой теме доступна здесь: http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx .
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33249856
Мимопроходивший
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OCL?
--
Мимопроходивший != Мимопроходящий
(Их разыскивает милиция)
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33249873
Dimonische
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andreww2 Dimonische

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


Вы меня тоже извините. Возможно, я чрезмерно реагирую.


Andreww
>>1. Байт код клиента меняет клиентский драйвер, который может быть на Яве/С#/языки с байткодом (тогда там bytecode instrumentation),

Хммм. Т.е. вы всё-таки уверены, что именно КЛИЕНТСКИЙ код ИЗМЕНЯЕТСЯ. Т.е. (вспоминая пример в посте № 1837003, я уж не буду его весь приводить, желающие могут посмотреть), set.add(o.getOrderLines().getCommodity ()) этот самый getCommodity развернётся в код который вернёт список (?) и получится что-то вроде set.add(new OrderLines(){…тут код который «сгенерировал» (!?) драйвер для конструирования объета OrderLines…})


Ээээ, getCommodity() возвращает объект типа Commodity (а не коллекцию) т.е это выглядит как:
Код: plaintext
1.
Commodity tovar = o.getOrderLines().getCommodity();

Andreww
set.add(new OrderLines(){…тут код который «сгенерировал» (!?) драйвер для конструирования объета OrderLines…})


Черт, как же Ява оторвалась, а... Я вообще не понял что вы хотели написать .
Я в интерфейс Set (в яве хранит уникальные значения) хотел добавить Commodity...

Andreww
Есс-но это всё в байт коде. Верно понимаю ? Можно ссылочку на такой драйвер, который это умеет, ну и на ОСУБД для которой он предназначен ?


Это умеют все ОО базы, у которых есть Ява интерфейс. Как минимум Версант VDS. Что именно вас интересует? Я на вскидку на Версантовском сайте это не нашел, однако описание техники есть для Hibernate

http://www.hibernate.org/hib_docs/v3/reference/en/html_single/

Поишите все вхождения слова bytecode

Andreww

>>С/C++/компилируемые языка (компиляция нового класса).

Т.е. при каждом изменении Класса в Объектной БД, я должен заново скомпилировать все клиентские приложения, или как ? Я просто пытаюсь понять ….


Андрей, в ОО базах классов на с++, яве и пр. (в Версанте например) НЕТ. Они внутри версанта описаны на собственном версантовом языке типа CREATE TABLE, и могут предоставляться Ява доступом, как Явовские классы, С++ доступом как С++ классы и пр.

Одно надо ясно поимать. Есть поле грохнули из БД, надо перекомписять. С РСУБД также.

>>Видимо, Вы не знаете что такое транзакции.

Andreww
ОК. Транзакции (и заметье, я не утверждал что кто-то чего-то не знает, просто спрашивал), я действительно не представляю как они используются в объектных СУБД.
При получении объекта Order мы должны заблокировать все входящие в него объекты OrderLine т.к. в Order есть ссылки (ваши слова – «может через спрятанную ссылку которую добавили при возврате класса Order скрытым от нас образом внутри executeQuery» ?) если у сервера блокировочный механизм, или нужно сохранить где-то версии в случае версионника, что бы эти ссылки были действительными, но тут же возникает проблема , а что если у OrderLine есть ссылки на объекты SubLine, например? Их надо согласовывать ? И зачем мне чего-то блокировать или версии оставлять, если я беру Order и работаю только с ним ? В случае РСУБД, как вам уже обяснили в посте № 1838679 в случае чтения идентификатора, никаких действий по согласованности не требуется, т.к. идентификаторы в этом случае это ничего не значащий суррогат с ним работает разработчик он за него и отвечает, а вот «спрятаные» ссылки должны разрешаться БЕЗ ВМЕШАТЕЛЬСТВА РАЗРАБОТЧИКА (на то они и спрятанные) и иного механизма обеспечения согласованности кроме блокировки или хранения старой версии пока нет.


Все типы транзакций существуют с некоторыми малозначительными нюансами и в ООБД.

Условно говоря, например Order->OrderLine->OrderSubline можно объявить ка один домен (композитный объект). Пусть у нас полная изоляциию. Мы вытащили Orders из Connection неким запросом. Соответвственно, все вложеные объекты, которые будут доступны через навигацию тоже взяты как полная изоляция. Т.к. с точки зрения БД, это один объект. Чтобы было более яснее, что такое домен, пусть будут такие связи : Order->OrderLine->OrderSubline->Currency. Виден домен невооруженным взглядом - Order->OrderLine->OrderSubline. Видна внешняя связь - OrderSubline->Currency.


Andreww
>2. OrderLines задекларированы как члены домена Order, и потому хранятся "вместе с классом Order" и при запросах всегда возвращаются.

>Откровенно говоря, это проблема разработчиков объектной БД. Сдается мне, у Вас нет такого опыта.

Конечно нет ! Но я пытаюсь у вас про них узнать подробнее. Вы предлагаете решение ("OrderLines задекларированы как члены домена Order"), я вам рассказываю к чему это может привести, а вы в ответ – «это проблема разработчиков объектной БД. Сдается мне, у Вас нет такого опыта», странно как-то, не находите ? Вы сказали как, я сказал чем мне это не нравится, а мне в ответ «опыта нет». :-(
Andreww
Если хранятся вместе, тогда вопросов нет. Но это может привести к вырождению БД в файловую систему или в систему типа «Всё в одной таблице». Там с блокировочками накладно-с.



Фиг знает, я привел привем как я выделяю домены. у меня не вырождается.
А почему я взъелся на транзакции уже не помню.

Andreww
>>В яве есть такое понятие - Bytecode instrumentation.
Это значит, что код класса, который вернулся откуда либо (в нашем случае conn.executeQuery) поменян на уровне инструкций виртуальной машины Ява.

А если не Java ? Если .NET ? Там уже другой байт код, сл-но менять надо по-другому. Если работаем с Delphi7 или (о ужас!) VB6, там вообще native code, особо ничего не поменяешь. Т.е. получается, что «объектные» базы напрямую зависят от технологии разработки клиента, а может это и не базы в виде Клиент - Сервер, а просто некоторый инструментарий для конкретной платформы (нап. Java)?


НЕТ, не зависят. Есть объектный сервер, есть к ниму библиотеки доступа с разных языков. Ну возьмите Оракл. ODBC/JDBC - соответсвенно Microsoft языки + Ява, есть наверняка еще кучи библиотек доступа для PHP, Perl и прочее.

Объектные базы просто имеют значительно более сложные клиенские библиотеки.

ХОТЯ, есть и именно такие базы как вы и описали.


Andreww
Или эти «объектные базы» настолько круты, что у них есть интерфейс под большинство современных средств разработки и этот инструментарий поспевает за бесконечными обновлениями платформ ?


А что тут такого крутого? Ява 1.3.х-1.4.х-1.5.х не сильно менялась с точки зрения байт-кода, а это между прочим 7 лет развития явы.

Спросите кстати тоже себя про Оракл.

Andreww

«Добавили ссылку» кто ? Если сервер, то вопросов нет. Только на что ссылаемся то? Мы вроде как в многопользовательской среде (если я правильно всё понял) и если после получения экземпляра списка OrderLines ссылкИ на OrderLine поменяются и будут показывать куда ? Стрёмная вещь ссылки да ещё и в распределённой многопользовательской среде.



ТРАНЗАКЦИИ


Andreww

>Реч идет о том, что аналитиков, которые делают SQL к базе данных (в центральном офисе ТНК например) - 25 человек.

Ну тем хуже для ТНК. Я до сих пор не встречал аналитиков (бизнес-аналитиков) у которых SQL в качестве инструмента. Всё больше пакеты всякие для OLAP. А какой там внутри xyzQL это аналитиков мало волнует, им срезы всякие нужны, по кварталам, по месяцам, по-подразделниям и прочее. Прибыль и т.д. Им решения принимать и текущее состояние дел видеть надо. С ужасом представляю как финдиректор, что бы посмотреть сумму прибыли за квартал по подразделениям открывает SQLPlus и начинает писать SELECT …



Под аналитиками я имел в виду людей которые делают SQL + ессно и прочии кубы :)).

Andreww
Странный подход :( Т.е. если у вас заказчик потребует реализовать возможность А и возможность Б вы скажете, берёмся за возможность «Б« а «А», ну как-нибудь потом, она всего-то нужна для 10 человек….


Если требуемая функциональность для 10 людей требует перестройки всей системы, и мы об этом сообщим заказчику, то этих 10 людей попросят сделать это как нибудь по другому. Скорее всего.

Andreww
Может для вас ОСУБД эта некоторая прослойка (вроде сервера приложений) между рел. хранилищем и ОО средой разработки ? Отсюда и запросы на SQL и «странные» требования к драйверу JDBC ?


Спасибо, я отличаю компонентные фреймворки - cервера приложений (EJB), ОРМ - Хибернейт/Кайен и драйвера (JDBC) друг от друга.

Спасибо, в задачу вдаваться не хочу, скучно.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33249954
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shuklinЛюбопытно, что Ваш тезис верен с точностью до наоборот. Именно в РБД используют деревья индексов для решения описанных Вами проблем абстрагирования от физического хранения данных. Если взять к примеру MS-SQL то можно нарисовать в нем запрос без bookmark lookup что приведет к отсутствию работы с таблицами - использоваться будут только деревья. Так вот, зачем организовывать данные в таблицы, если реальную независимость от аппаратного хранения и реальную скорость тех же JOIN дают именно деревья и сети, родные для ОБД?Также Вам, вероятно, будет любопытно узнать, что РМД не требует хранения данных в таблицах. Единственное требование - это представление данных пользователю в виде переменных-отношений. И только в виде них. Всё, точка. Как сервер хранит и обрабатывает данные - его проблемы. Хоть сети, хоть деревья, хоть лес деревьев, связанный сетями.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33250060
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел Воронцов shuklinЛюбопытно, что Ваш тезис верен с точностью до наоборот. Именно в РБД используют деревья индексов для решения описанных Вами проблем абстрагирования от физического хранения данных. Если взять к примеру MS-SQL то можно нарисовать в нем запрос без bookmark lookup что приведет к отсутствию работы с таблицами - использоваться будут только деревья. Так вот, зачем организовывать данные в таблицы, если реальную независимость от аппаратного хранения и реальную скорость тех же JOIN дают именно деревья и сети, родные для ОБД?Также Вам, вероятно, будет любопытно узнать, что РМД не требует хранения данных в таблицах. Единственное требование - это представление данных пользователю в виде переменных-отношений. И только в виде них. Всё, точка. Как сервер хранит и обрабатывает данные - его проблемы. Хоть сети, хоть деревья, хоть лес деревьев, связанный сетями.

В моей СООБЗ данные храняться в виде леса деревьев объектов, связанных сетями. На основе деревьев можно эмулировать табличные структуры. Спасибо за информацию! Теперь я со спокойной душей могу называть свою БД реляционно-объектно-сетевой системой управления знаниями ;)
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33250120
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторЕсли рассмотреть мою СООБЗ то объекты в ней хранятся вовсе не в виде таблиц, а в виде группы деревьев.А что - данные в этих деревья независимы от физ. уровня?

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

К чему сравниваю деревья и отношения? К тому, что многие думают, что основное преимущество РМД - представить данные в виде отношений ( что близко банальным и понятным для пользователя таблицам). Однако ИМХО преимущество РМД не только и даже не столько в этом. Гораздо важнее то, что данные, представленные в таком виде, являются абсолютно независимыми от организации на физическом уровня. ИМХО РМД - есть единственная модель данных …хотел написать "позволяющая делать то-то и то-то", но понял, что фраза "единственная модель данных" ужа сама по себе подразумевает самодостаточность данных. Если Вы можете доказать обратное, т.е. РМД не единственная модель данных (где достаточны только данные определяемые пользователем)– WELCOME!!! иа иначе все ваша аргументация "деревья – не деревья, внутри и снаружи" на меня не подействует.

Кто-то тут упомянул Турчина. Я этим несколько лет назад тоже им заморачивался. Я согласен, что РСУБД реализуют некий метасистемный переход, но цель этого перехода – не иная организация данных, а создание системы хранения, независимой от физической организации данных. Любая система, которая хочет быть таковой, должна так или иначе, на каком-то уровне строиться на основании данных, организованных в виде множества значений отношений, а иначе она будет каким-то образом зависить от организации данных на физическом уровне, и эта зависимоть будет постоянно вылазить и мешать . Тех, кто считает такую независимость неважной, я отсылаю в детский сад, где они могут на досуге прочитать книжку Дж.Мартина "Организация баз данных в вычислительных системах" (Изд. 2-е 1980 «Мир»). Книга старая но, попреженму актуальная. Особенно она будет полезна для людей, которые страдают ОО(что в общем то непредосудительно) и отвергают РМД (что ИМХО абсолютно неверно).

По поводу трех таблиц. :) Конечно я не знаю, как оно там в ООСУБД все устроено. Но ведь есть "объекты в памяти" и "объекты на диске"? Значит существует отношение между множеством адресов в памяти и набором позиций в файле. Мягкие ссылки как то реализуются? значит есть отношение между множеством физических адресов и мягких ссылок. Индексы есть (или будут?) Значит есть отношение между индексируемым атрибутом и ссылкой. То есть конечно таблиц как таковых может и не быть, но перечисленные отношения то есть... хотя бы формально? А если мы попросим систему найти объект по какому нибуть непроиндекированному атрибуту, она (опять таки формально!) должна такое отношение создать? Ну так не проще формально на каком то уровне эти данные так и организовать? Ведь на самом то деле она никак никому не мешает... Речь идет о трансляции команд языка высокого уровня в набор опреаций манипулирующих данными на физическом уровне, и эти промежуточные представления нужны только для того, что бы понять, как транслирвать команды, при условии, что ланные реально независимы от физического уровня.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33250148
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shuklinТак вот, зачем организовывать данные в таблицы, если реальную независимость от аппаратного хранения и реальную скорость тех же JOIN дают именно деревья и сети, родные для ОБД?


Затем, что они НЕ ВСЕГДА обеспечивают реальную независимость от аппаратного хранения и реальную скорость тех же JOIN Кстати, когда хранение в виде деревьев ВЫГОДНЕЕ (а не всегда, заметьте), можно использовать IOT. Oracle об этом подумал.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33250154
Dimonische
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)

Затем, что они НЕ ВСЕГДА обеспечивают реальную независимость от аппаратного хранения и реальную скорость тех же JOIN Кстати, когда хранение в виде деревьев ВЫГОДНЕЕ (а не всегда, заметьте), можно использовать IOT. Oracle об этом подумал.

(IOT - это INDEX ORGANIZED TABLE?). Если да, то пусть ИОТ будет чем-то более крутым - например возможностью указать 5 таблиц и хранить их рядом. Иначе конечно по сравнению с деревья, об этом смешно говортить.

И тогда вопрос "можно использовать" не стоит как, "войдите в sqlplus, сделайте IOT, а потом селект и у вас все будет."

Чтобы это реально работало, надо чтобы драйвера, например JDBC, реализовывали работу с этим IOT, чтобы стандартный ОРМ софт (в яве) - Hibernate, Kodo, Cayenn, Toplink, поддерживал эту функциональность, и.т.д

А если это не реальзовано, то никому не нужно.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33250160
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторЕсли да, то пусть ИОТ будет чем-то более крутым - например возможностью указать 5 таблиц и хранить их рядом.

Для этого в Oracle существуют кластеры. Смешно затевать революции, не удосужившись досконально ознакомиться с опытом, накопленным успешными предшественниками.

авторЧтобы это реально работало, надо чтобы драйвера, например JDBC, реализовывали работу с этим IOT

Способ организации данных для JDBC абсолютно перпендикулярен. Для ВСЕХ они выглядят как обычные таблицы. Просто некоторые операции на них выполняются эффективнее чем на обычных таблицах, а некоторые менее эффективно.

авторСпасибо, в задачу вдаваться не хочу, скучно.

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

Если так, мне жалко Ваших работодателей

P.S. При революциях проливается ОЧЕНЬ много крови, а бизнессмены более заинтересованы в сохранении инвестиций. Потому они и предпочитают эволюционные методы революционным

P.P.S. Те бизнессмены, которые поступают наоборот вымирают в результате естественного отбора
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33250245
Dimonische
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)
Для этого в Oracle существуют кластеры. Смешно затевать революции, не удосужившись досконально ознакомиться с опытом, накопленным успешными предшественниками.


О да, бьюсь в оргазме от возможности соединить МАКСИМУМ ДВЕ таблицы.

Gluk (Kazan)
Способ организации данных для JDBC абсолютно перпендикулярен. Для ВСЕХ они выглядят как обычные таблицы. Просто некоторые операции на них выполняются эффективнее чем на обычных таблицах, а некоторые менее эффективно.


Знаю

Gluk (Kazan)

авторСпасибо, в задачу вдаваться не хочу, скучно.

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

Если так, мне жалко Ваших работодателей


На работе мне деньги платят
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33250277
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторНа работе мне деньги платят

А здесь Вы ... маетесь ?



Дальнейшую дискуссию с Вами, Шуклиным и коллегой ЧАЛом считаю бесполезной
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33250284
shuklin
В моей СООБЗ данные храняться в виде леса деревьев объектов, связанных сетями. На основе деревьев можно эмулировать табличные структуры. Спасибо за информацию! Теперь я со спокойной душей могу называть свою БД реляционно-объектно-сетевой системой управления знаниями ;)


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

И вообще все беды с производительностью SQL DBMS - от хранения на физ. уровне значений отношений именно в табличном виде почти шутка
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33250296
Dimonische
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)
Дальнейшую дискуссию с Вами, Шуклиным и коллегой ЧАЛом считаю бесполезной

Аллах велик и всем найдется место
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33250913
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
U-gene
По поводу трех таблиц. :) Конечно я не знаю, как оно там в ООСУБД все устроено. Но ведь есть "объекты в памяти" и "объекты на диске"? Значит существует отношение между множеством адресов в памяти и набором позиций в файле.


Да, такая таблица есть. Она содержит соответствие между OID и адресом объекта в оперативной памяти. При обращении к любому объекту сперва проверяется эта таблица (не загружен ли уже искомый объект в память?).

U-gene
Мягкие ссылки как то реализуются? значит есть отношение между множеством физических адресов и мягких ссылок.


Тут уже не все так однозначно и требуются пояснения. Что есть "мягкая ссылка" в применении к ООСУБД? Дело в том, что, к примеру, в FO "мягкая ссылка" обычно является мягкой только пока она не сохранена в БД. В момент записи она становится "жесткой ссылкой". Разумеется, для разрешения такой ссылки (в момент сохранения) в БД должен присутствовать некий индекс, позволяющий по "мягкому" ID найти полный OID. Но ведь индекс (см. далее)

U-gene
Индексы есть (или будут?) Значит есть отношение между индексируемым атрибутом и ссылкой. То есть конечно таблиц как таковых может и не быть, но перечисленные отношения то есть... хотя бы формально?


Конечно, индексы есть. Но ведь индексы - это в подявляющем большинстве случаев не таблицы, а деревья...

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

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

Вот тут постоянно муссируется тема "вот есть реляционная модель данных, а где объектная...". А может и нет ее - объектной модели? А может правильнее смотреть на объектные системы как на конструктор для создания моделей? Т.е. используя ООСУБД мы создаем модель данных для конкретного приложения?
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33251217
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-gene авторЕсли рассмотреть мою СООБЗ то объекты в ней хранятся вовсе не в виде таблиц, а в виде группы деревьев.А что - данные в этих деревья независимы от физ. уровня?
Естессно независимы. А как иначе оно б работало? БД объектов остается логически целостной не зависимо от колличества перезапусков ядра системы и циклов сборки мусора.

U-geneВ РМД все данные и все манипуляции с данными огорганизованы исключително на основании данных, явно определяемых пользователем ...Замечаете какая фишка? - все манипуляции с данными происходят исключительно на основании только тех данных, которые сам пользователь определил, ввел в систему.
В последней версии Cerebrum аналогично . Кстати, это основное концептуальное изменение, по сравнению с VNPI2 (1999).


U-geneОднако ИМХО преимущество РМД не только и даже не столько в этом. Гораздо важнее то, что данные, представленные в таком виде, являются абсолютно независимыми от организации на физическом уровня.

ИМХО та степень зависимости от уровня хранения, которой обладает РМД и есть ее подавляющий недостаток. Она слишком большая! Гораздо больше чем у ОО и сетевых моделей! Неужели никто не видит, что уровнем физического хранения для РМД являются таблицы? Это же примитив. Даже дерево гораздо интереснее с математической точки зрения. И даже в дереве (XML к примеру) данные гораздо менее зависимы от физического уровня, так как дерево, как физический уровень обладает большей представительной силой. О сети объектов можно уже и не говорить.


U-geneЗначит есть отношение между индексируемым атрибутом и ссылкой.
А кто здесь против отношений? Отношения вовсе не есть эксклюзивная собственность РМД. И нечего эту математическую абстракцию запихивать в примитивные таблички а потом объявлять, что таблицы - единственный способ представления отношений. В Cerebrum отношения очень даже исспользуются. Причем сопостовление идет именно по значениям заданным пользователем. Разумеется я за использование отношений. Я против применения таблиц как физичекого уровня хранения данных и отношений между ними. Это слишком примитивно. И опять же я только против применения таблиц как физического уровня хранения а не против самих таблиц. В Cerebrum сеть для удобства редактирования представляется пользователю в виде тех же пресловутых табличек. Как средство юзер интерфейса таблицы очень даже удобны.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33251236
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey RovdoМне кажется, что вы ошибаетесь вот в чем. Объектные СУБД не противостоят реляционным во всем. Есть ряд технологий, которые они - напротив - заимствовали у реляционных. Однако следует понимать, что будучи очень похожими на физическом уровне, ООСУБД гораздо богаче на уровне логическом. Т.е. в ООСУБД на физическом уровне вполне реализуемы все те же решания, которые есть в РСУБД (и если сегодня они еще не развиты до той же степени, что и у ведущих РСУБД, то это только вопрос времени). Логика ваших рассуждений сводится к тому, что раз уж они выглядят похоже на физическом уровне, то и нет смысла в отличиях на логическом уровне - РСУБД форева. Но ведь это не конструктивный подход. Для одних задач реляционная модель подходит наилучшим образом, а для других оптимальна другая модель. Именно объектные базы дают не просто другую модель, а даже больше - возможность эту модель создать.

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

Поддерживаю. Хороший пост.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33251313
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Alexey Rovdo

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

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

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

авторДля одних задач реляционная модель подходит наилучшим образом, а для других оптимальна другая модель. Повторю, что какое либо противопоставление OO и РМД ИМХО неверно. Зная Ваше понимание ООСУБД, я бы конец Вашей фразы трактовал как "...для других целей могут быть оптимальны системы хранения, в которых данные зависят от физической организации". С этим я не спорю. Но ОО здесь не при чем.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33251398
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторУв. shuklin.

shuklin Естессно независимы. А как иначе оно б работало? БД объектов остается логически целостной не зависимо от колличества перезапусков ядра системы и циклов сборки мусора.
Это Вы так независимость данных понимаете? Тогда мое пожелание почитать в саду книжку Мартина к Вам относится абсолютно и однозначно. :)

авторВ последней версии Cerebrum аналогично. Кстати, это основное концептуальное изменение, по сравнению с VNPI2 (1999)...тогда зачем Вам сборка мусора? Или появляется что-то, что есть в системе, но Вы не имеет к этому доступа?... а система доступ имеет, т.е. "знает" про это?

авторИМХО та степень зависимости от уровня хранения, которой обладает РМД и есть ее подавляющий недостаток. Она слишком большая! Да-да, РМД "совсем беремная". А ваш "мозг" - немножко. :)

авторНеужели никто не видит, что уровнем физического хранения для РМД являются таблицы?КонеЧно! если рассматаривать диск в микроскоп, то их можно увидеть воочию. :) Ну Вы подсталяться горазды. Про "таблицы" в "РМД" да еще "на физическом уровне".... это Вам как кандидату наук прямо таки уже непростительно....
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33251421
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey RovdoВот тут постоянно муссируется тема "вот есть реляционная модель данных, а где объектная...". А может и нет ее - объектной модели? А может правильнее смотреть на объектные системы как на конструктор для создания моделей? Т.е. используя ООСУБД мы создаем модель данных для конкретного приложения?И вот опять мы не заслушали начальника транспортного цеха....

Вопрос ведь в том что с чем сравнивать. Нам предлагают сравнивать РМД, которая суть теория - с чем? С моделями предметной области? За-ши-бись!
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33251482
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shuklinИМХО та степень зависимости от уровня хранения, которой обладает РМД и есть ее подавляющий недостаток. Она слишком большая! Гораздо больше чем у ОО и сетевых моделей! Неужели никто не видит, что уровнем физического хранения для РМД являются таблицы? Это же примитив. Даже дерево гораздо интереснее с математической точки зрения. И даже в дереве (XML к примеру) данные гораздо менее зависимы от физического уровня, так как дерево, как физический уровень обладает большей представительной силой. О сети объектов можно уже и не говорить.Опять же - ЗА-ШИ-БИСЬ! Ну нельзя же быть настолько безграмотным, в самом деле! Ну нету в РМД никаких уровней физического хранения! Их там просто НЕТУ ! Всё, чего требует РМД - это представление данных в виде отношений и только в виде отношений. shuklin авторЗначит есть отношение между индексируемым атрибутом и ссылкойА кто здесь против отношений? Отношения вовсе не есть эксклюзивная собственность РМД. И нечего эту математическую абстракцию запихивать в примитивные таблички а потом объявлять, что таблицы - единственный способ представления отношений.Мда... Это ж надо так... Неужто Вы даже отличить не можете в каком значении слово "отношение" когда употребляется?
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33251716
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Павел Воронцов Alexey RovdoВот тут постоянно муссируется тема "вот есть реляционная модель данных, а где объектная...". А может и нет ее - объектной модели? А может правильнее смотреть на объектные системы как на конструктор для создания моделей? Т.е. используя ООСУБД мы создаем модель данных для конкретного приложения?И вот опять мы не заслушали начальника транспортного цеха....

Вопрос ведь в том что с чем сравнивать. Нам предлагают сравнивать РМД, которая суть теория - с чем? С моделями предметной области? За-ши-бись!

Я ума не приложу, где во фразе, состоящей из трех вопросительных предложений вы увидели "Нам предлагают сравнивать ...".

ЗА-ШИ-БИСЬ! Ну нельзя же быть настолько безграмотным, в самом деле!

PS: Предметные области конечно бывают разными. Но, уверяю вас, за ними тоже иногда стоят вполне стройные теории и масса споров о достоверности этих теорий. Просто эти теории несколько, как бы это сказать, "предметнее", чем реляционная теория.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33251998
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey Rovdo Павел Воронцов Alexey RovdoВот тут постоянно муссируется тема "вот есть реляционная модель данных, а где объектная...". А может и нет ее - объектной модели? А может правильнее смотреть на объектные системы как на конструктор для создания моделей? Т.е. используя ООСУБД мы создаем модель данных для конкретного приложения?И вот опять мы не заслушали начальника транспортного цеха....

Вопрос ведь в том что с чем сравнивать. Нам предлагают сравнивать РМД, которая суть теория - с чем? С моделями предметной области? За-ши-бись!

Я ума не приложу, где во фразе, состоящей из трех вопросительных предложений вы увидели "Нам предлагают сравнивать ...". Ну, скажем, я прочитал эту фразу из трех вопросительных предложений и тоже, как и Павел Воронцов, понял ее как и он. Так что претензии к автору фразы, если он не то хотел сказать.
Alexey RovdoPS: Предметные области конечно бывают разными. Но, уверяю вас, за ними тоже иногда стоят вполне стройные теории и масса споров о достоверности этих теорий. Просто эти теории несколько, как бы это сказать, "предметнее", чем реляционная теория.Ну, Алексей. Нельзя же сравнивать две произвольные теории только потому, что и там, и там слово «теория». Что-то вы не то говорите. Можно ли сравнивать теорию множеств, квантовую теорию и теорию Дарвена? Это ведь все «теории», слово-то одно и то же, вот так по вашему выходит. Вам говорят, что сравнивать можно сопоставимые вещи. ИМодель данных с моделью данных, СУБД с СУБД, модель одной предметной области с моделью другой предметной области и т.п. Но никак нельзя сравнивать СУБД с моделью данных или же модель данных с моделью конкретной предметной области. Давайте-ка, подсоберитесь.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33252255
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mir
... Можно ли сравнивать теорию множеств, квантовую теорию и теорию Дарвена? Это ведь все «теории», слово-то одно и то же, вот так по вашему выходит. Вам говорят, что сравнивать можно сопоставимые вещи. ИМодель данных с моделью данных, СУБД с СУБД, модель одной предметной области с моделью другой предметной области и т.п. Но никак нельзя сравнивать СУБД с моделью данных или же модель данных с моделью конкретной предметной области. Давайте-ка, подсоберитесь.

Вы то меня как раз адекватно поняли. Нельзя сравнивать реляционную теорию (модель) данных с де-факто отсутствующей объектной или объектно-ориентированной теорией (моделью) . Равно как нельзя сравнивать теорию данных с какой-то теорией предметной области - они действительно не сопоставимы.

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

Проблемы возникают тогда, когда мы хотим обобщить разработанные решения и накопленный опыт на другие области. Вот здесь нам уже становится нужна более общая теория данных. К сожалению, сегодня такая общая теория есть только для реляционной модели.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33252349
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По-моему, объектной модели данных, аналогичной РМД, не может существовать как не существует модели языка программирования, кроме машины Тьюринга:). Реляционная модель начинается с определения отношения. А каково определение объекта? В разных языках объекты и конструируются по-разному.
По сути ОО технологии любое действие с объектом влечет вызов неких его методов, т.е. простое сохранение приводит к выполнению части программного кода сохраняемого объекта и этот код фактически входит в дизайн OO БД. Что тут можно моделировать в общем случае?

По поводу своего изначального вопроса я понял, что ООСУБД навигационный подход также до лампочки как и реляционный.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33252539
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторПо-моему, объектной модели данных, аналогичной РМД, не может существовать... ИМХО -золотые слова. ОО-парадигма - это удобная парадигма РЕАЛИЗАЦИИ по сути любых типов. А модель данных - это СПЕЦИФИКАЦИЯ конкретного множества конкретных типов данных.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33252671
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelRПо-моему, объектной модели данных, аналогичной РМД, не может существовать как не существует модели языка программирования, кроме машины Тьюринга:). Реляционная модель начинается с определения отношения. А каково определение объекта? В разных языках объекты и конструируются по-разному.

Если "что то" не известно или еще не придумано, это не значит что это "что то" не может существовать.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33253269
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey RovdoЯ ума не приложу, где во фразе, состоящей из трех вопросительных предложений вы увидели "Нам предлагают сравнивать ...". Вероятно я Вас не так понял, извините если задел. Видите ли, я не против сравнения равнозначных вещей (теорий, технологий etc.). Просто почему-то любое сравнение или даже анонс, описание нечта, претендующего на базу данных с приставкой ОО начинается с громких заявлений о крахе РМД, ущербности реляционного подхода и скором всеобщем ОО счастье. И это мягко говоря раздражает. С тем и боремся. И только с этим - с безграмотностью и неверным употреблением устоявшихся терминов.

Если мне надо будет делать встраиваемую систему - я посмотрю в сторону Версанта, Вы меня своими стараниями убедили.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33255017
GlebZ2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Alexey Rovdo
Вы то меня как раз адекватно поняли. Нельзя сравнивать реляционную теорию (модель) данных с де-факто отсутствующей объектной или объектно-ориентированной теорией (моделью) . Равно как нельзя сравнивать теорию данных с какой-то теорией предметной области - они действительно не сопоставимы.

Отчего-же. Мистер Кодд с вами бы не согласился. Мистер Дейт именно по этому и наезжает SQL. Реляционная модель замысливалась как отражение предметной модели. Объектно-ориентированная также. Просто способы разные.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33256177
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GlebZ2 Alexey Rovdo
Вы то меня как раз адекватно поняли. Нельзя сравнивать реляционную теорию (модель) данных с де-факто отсутствующей объектной или объектно-ориентированной теорией (моделью) . Равно как нельзя сравнивать теорию данных с какой-то теорией предметной области - они действительно не сопоставимы.

Отчего-же. Мистер Кодд с вами бы не согласился. Мистер Дейт именно по этому и наезжает SQL. Реляционная модель замысливалась как отражение предметной модели. Объектно-ориентированная также. Просто способы разные.Тут опять некоторая путаницав терминах. Реляционная модель данных и модель (схема) реляционной базы данных -- разные вещи. Модель (схема) реляционной базы данных, конечно в каком-то смысле вполне отражает соответствующую модель предметной области. Но реляционная модель данных не может отражает никакую модель предметной области, ибо это разные понятия: средство (инструмент) моделирования и результат моделирования. Вот здесь довольно хорошая статься Когаловского по этому вопросу.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33257188
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
serg99Если "что то" не известно или еще не придумано, это не значит что это "что то" не может существовать.Есть предложения по определению объекта?
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33257423
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelR serg99Если "что то" не известно или еще не придумано, это не значит что это "что то" не может существовать.Есть предложения по определению объекта?
Мне просто показалось странным, что про ОМД, которая "не может существовать", Вы тем не менее знаете, что она как то связана с языками программирования и что главным определением ОМД должно быть определение объекта. Лично я не согласен ни с тем ни с другим.

У меня конечно есть соображения по этому вопросу, однако с одной стороны определение объекта не дашь в двух словах, а с другой стороны это определение должно даваться в контексте модели данных. Поэтому предлагаю подождать до появления соответствующего манифеста.
...
Рейтинг: 0 / 0
Объекты и навигация.
    #33260971
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2serg99 авторМне просто показалось странным, что про ОМД, которая "не может существовать", Вы тем не менее знаете, что она как то связана с языками программирования и что главным определением ОМД должно быть определение объекта. Ну определение в стиле "ОМД - это модель данных, представленных в форме программных объектов" я конечно могу написать, но прок?
авторЛично я не согласен ни с тем ни с другим.

У меня конечно есть соображения по этому вопросу, однако с одной стороны определение объекта не дашь в двух словах, а с другой стороны это определение должно даваться в контексте модели данных.Так начинать все-таки с определения объекта? автор
Поэтому предлагаю подождать до появления соответствующего манифеста.OK
...
Рейтинг: 0 / 0
77 сообщений из 77, показаны все 4 страниц
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Объекты и навигация.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]