Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: Объекты и навигация.  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
автор
Если рассмотреть мою СООБЗ то объекты в ней хранятся вовсе не в виде таблиц, а в виде группы деревьев.
А что - данные в этих деревья независимы от физ. уровня?

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

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

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

По поводу трех таблиц. :) Конечно я не знаю, как оно там в ООСУБД все устроено. Но ведь есть "объекты в памяти" и "объекты на диске"? Значит существует отношение между множеством адресов в памяти и набором позиций в файле. Мягкие ссылки как то реализуются? значит есть отношение между множеством физических адресов и мягких ссылок. Индексы есть (или будут?) Значит есть отношение между индексируемым атрибутом и ссылкой. То есть конечно таблиц как таковых может и не быть, но перечисленные отношения то есть... хотя бы формально? А если мы попросим систему найти объект по какому нибуть непроиндекированному атрибуту, она (опять таки формально!) должна такое отношение создать? Ну так не проще формально на каком то уровне эти данные так и организовать? Ведь на самом то деле она никак никому не мешает... Речь идет о трансляции команд языка высокого уровня в набор опреаций манипулирующих данными на физическом уровне, и эти промежуточные представления нужны только для того, что бы понять, как транслирвать команды, при условии, что ланные реально независимы от физического уровня.
4 сен 05, 01:43    [1844059]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
shuklin
Так вот, зачем организовывать данные в таблицы, если реальную независимость от аппаратного хранения и реальную скорость тех же JOIN дают именно деревья и сети, родные для ОБД?


Затем, что они НЕ ВСЕГДА обеспечивают реальную независимость от аппаратного хранения и реальную скорость тех же JOIN Кстати, когда хранение в виде деревьев ВЫГОДНЕЕ (а не всегда, заметьте), можно использовать IOT. Oracle об этом подумал.
4 сен 05, 09:01    [1844099]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Gluk (Kazan)


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


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

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

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

А если это не реальзовано, то никому не нужно.
4 сен 05, 09:29    [1844110]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
автор
Если да, то пусть ИОТ будет чем-то более крутым - например возможностью указать 5 таблиц и хранить их рядом.


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

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


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

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


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

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

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

P.P.S. Те бизнессмены, которые поступают наоборот вымирают в результате естественного отбора
4 сен 05, 09:39    [1844116]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Gluk (Kazan)

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


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

Gluk (Kazan)

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


Знаю

Gluk (Kazan)


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


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

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


На работе мне деньги платят
4 сен 05, 11:56    [1844227]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
автор
На работе мне деньги платят


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



Дальнейшую дискуссию с Вами, Шуклиным и коллегой ЧАЛом считаю бесполезной
4 сен 05, 12:43    [1844272]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
дураг с инецеативой
Guest
shuklin

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


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

И вообще все беды с производительностью SQL DBMS - от хранения на физ. уровне значений отношений именно в табличном виде почти шутка
4 сен 05, 12:56    [1844282]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Gluk (Kazan)

Дальнейшую дискуссию с Вами, Шуклиным и коллегой ЧАЛом считаю бесполезной


Аллах велик и всем найдется место
4 сен 05, 13:12    [1844301]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Alexey Rovdo
Member

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

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


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

U-gene

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


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

U-gene

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


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

U-gene

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


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

Вот тут постоянно муссируется тема "вот есть реляционная модель данных, а где объектная...". А может и нет ее - объектной модели? А может правильнее смотреть на объектные системы как на конструктор для создания моделей? Т.е. используя ООСУБД мы создаем модель данных для конкретного приложения?
5 сен 05, 10:31    [1845351]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
U-gene
автор
Если рассмотреть мою СООБЗ то объекты в ней хранятся вовсе не в виде таблиц, а в виде группы деревьев.
А что - данные в этих деревья независимы от физ. уровня?

Естессно независимы. А как иначе оно б работало? БД объектов остается логически целостной не зависимо от колличества перезапусков ядра системы и циклов сборки мусора.

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

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


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


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


U-gene
Значит есть отношение между индексируемым атрибутом и ссылкой.

А кто здесь против отношений? Отношения вовсе не есть эксклюзивная собственность РМД. И нечего эту математическую абстракцию запихивать в примитивные таблички а потом объявлять, что таблицы - единственный способ представления отношений. В Cerebrum отношения очень даже исспользуются. Причем сопостовление идет именно по значениям заданным пользователем. Разумеется я за использование отношений. Я против применения таблиц как физичекого уровня хранения данных и отношений между ними. Это слишком примитивно. И опять же я только против применения таблиц как физического уровня хранения а не против самих таблиц. В Cerebrum сеть для удобства редактирования представляется пользователю в виде тех же пресловутых табличек. Как средство юзер интерфейса таблицы очень даже удобны.
5 сен 05, 11:54    [1845830]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
shuklin
Member

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

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


Поддерживаю. Хороший пост.
5 сен 05, 11:59    [1845860]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
U-gene
Member

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

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

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

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

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

автор
Для одних задач реляционная модель подходит наилучшим образом, а для других оптимальна другая модель.
Повторю, что какое либо противопоставление OO и РМД ИМХО неверно. Зная Ваше понимание ООСУБД, я бы конец Вашей фразы трактовал как "...для других целей могут быть оптимальны системы хранения, в которых данные зависят от физической организации". С этим я не спорю. Но ОО здесь не при чем.
5 сен 05, 12:16    [1845993]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
автор
Ув. shuklin.


shuklin
Естессно независимы. А как иначе оно б работало? БД объектов остается логически целостной не зависимо от колличества перезапусков ядра системы и циклов сборки мусора.

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

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

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

автор
Неужели никто не видит, что уровнем физического хранения для РМД являются таблицы?
КонеЧно! если рассматаривать диск в микроскоп, то их можно увидеть воочию. :) Ну Вы подсталяться горазды. Про "таблицы" в "РМД" да еще "на физическом уровне".... это Вам как кандидату наук прямо таки уже непростительно....
5 сен 05, 12:35    [1846127]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Павел Воронцов
Member

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

Вопрос ведь в том что с чем сравнивать. Нам предлагают сравнивать РМД, которая суть теория - с чем? С моделями предметной области? За-ши-бись!
5 сен 05, 12:39    [1846169]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
shuklin
ИМХО та степень зависимости от уровня хранения, которой обладает РМД и есть ее подавляющий недостаток. Она слишком большая! Гораздо больше чем у ОО и сетевых моделей! Неужели никто не видит, что уровнем физического хранения для РМД являются таблицы? Это же примитив. Даже дерево гораздо интереснее с математической точки зрения. И даже в дереве (XML к примеру) данные гораздо менее зависимы от физического уровня, так как дерево, как физический уровень обладает большей представительной силой. О сети объектов можно уже и не говорить.
Опять же - ЗА-ШИ-БИСЬ! Ну нельзя же быть настолько безграмотным, в самом деле! Ну нету в РМД никаких уровней физического хранения! Их там просто НЕТУ! Всё, чего требует РМД - это представление данных в виде отношений и только в виде отношений.
shuklin
автор
Значит есть отношение между индексируемым атрибутом и ссылкой
А кто здесь против отношений? Отношения вовсе не есть эксклюзивная собственность РМД. И нечего эту математическую абстракцию запихивать в примитивные таблички а потом объявлять, что таблицы - единственный способ представления отношений.
Мда... Это ж надо так... Неужто Вы даже отличить не можете в каком значении слово "отношение" когда употребляется?
5 сен 05, 12:55    [1846270]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Alexey Rovdo
Member

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

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


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

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

PS: Предметные области конечно бывают разными. Но, уверяю вас, за ними тоже иногда стоят вполне стройные теории и масса споров о достоверности этих теорий. Просто эти теории несколько, как бы это сказать, "предметнее", чем реляционная теория.
5 сен 05, 13:55    [1846624]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
mir
Member

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

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


Я ума не приложу, где во фразе, состоящей из трех вопросительных предложений вы увидели "Нам предлагают сравнивать ...".
Ну, скажем, я прочитал эту фразу из трех вопросительных предложений и тоже, как и Павел Воронцов, понял ее как и он. Так что претензии к автору фразы, если он не то хотел сказать.
Alexey Rovdo
PS: Предметные области конечно бывают разными. Но, уверяю вас, за ними тоже иногда стоят вполне стройные теории и масса споров о достоверности этих теорий. Просто эти теории несколько, как бы это сказать, "предметнее", чем реляционная теория.
Ну, Алексей. Нельзя же сравнивать две произвольные теории только потому, что и там, и там слово «теория». Что-то вы не то говорите. Можно ли сравнивать теорию множеств, квантовую теорию и теорию Дарвена? Это ведь все «теории», слово-то одно и то же, вот так по вашему выходит. Вам говорят, что сравнивать можно сопоставимые вещи. ИМодель данных с моделью данных, СУБД с СУБД, модель одной предметной области с моделью другой предметной области и т.п. Но никак нельзя сравнивать СУБД с моделью данных или же модель данных с моделью конкретной предметной области. Давайте-ка, подсоберитесь.
5 сен 05, 15:11    [1847068]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Alexey Rovdo
Member

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

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


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

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

Проблемы возникают тогда, когда мы хотим обобщить разработанные решения и накопленный опыт на другие области. Вот здесь нам уже становится нужна более общая теория данных. К сожалению, сегодня такая общая теория есть только для реляционной модели.
5 сен 05, 16:29    [1847526]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
ModelR
Member

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

По поводу своего изначального вопроса я понял, что ООСУБД навигационный подход также до лампочки как и реляционный.
5 сен 05, 16:56    [1847714]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
автор
По-моему, объектной модели данных, аналогичной РМД, не может существовать
... ИМХО -золотые слова. ОО-парадигма - это удобная парадигма РЕАЛИЗАЦИИ по сути любых типов. А модель данных - это СПЕЦИФИКАЦИЯ конкретного множества конкретных типов данных.
5 сен 05, 18:14    [1848116]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
serg99
Member

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

Если "что то" не известно или еще не придумано, это не значит что это "что то" не может существовать.
5 сен 05, 19:57    [1848352]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Павел Воронцов
Member

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

Если мне надо будет делать встраиваемую систему - я посмотрю в сторону Версанта, Вы меня своими стараниями убедили.
6 сен 05, 11:12    [1849265]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
GlebZ2
Member

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

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

Отчего-же. Мистер Кодд с вами бы не согласился. Мистер Дейт именно по этому и наезжает SQL. Реляционная модель замысливалась как отражение предметной модели. Объектно-ориентированная также. Просто способы разные.
6 сен 05, 21:31    [1852573]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
GlebZ2
Alexey Rovdo

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

Отчего-же. Мистер Кодд с вами бы не согласился. Мистер Дейт именно по этому и наезжает SQL. Реляционная модель замысливалась как отражение предметной модели. Объектно-ориентированная также. Просто способы разные.
Тут опять некоторая путаницав терминах. Реляционная модель данных и модель (схема) реляционной базы данных -- разные вещи. Модель (схема) реляционной базы данных, конечно в каком-то смысле вполне отражает соответствующую модель предметной области. Но реляционная модель данных не может отражает никакую модель предметной области, ибо это разные понятия: средство (инструмент) моделирования и результат моделирования. Вот здесь довольно хорошая статься Когаловского по этому вопросу.
7 сен 05, 13:05    [1854375]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
serg99
Если "что то" не известно или еще не придумано, это не значит что это "что то" не может существовать.
Есть предложения по определению объекта?
7 сен 05, 17:40    [1856202]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить