Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 [19] 20 21 22 23 .. 34   вперед  Ctrl
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

... и понятно - вы говорите, что оно круче, но никак не показываете. Остается вопрос: не показываете, потому что на самом деле не круче?


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

Ведь именно в этом контексте следует рассматривать и мой подход к выбору платформы реализации. Я для обоих случаев выбрал приложение на ОО-языке Java. Но многие настаивают на том, что это некорректно и надо сравнивать с исходным решением SergSuper. Но в таком случае это не будет сравнением РСУБД и ООСУБД - это будет сравнением ОО и ERD/IDEF подходов к проектированию систем.
18 фев 05, 12:07    [1330579]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Нууууу.... Даже не знаю, что ответить.

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

-- Tygra's --
18 фев 05, 12:56    [1330847]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ЛП
Guest
- армяне лучше чем грузины!
- ну чем, чем армяне лучше?
- чем грузины!
18 фев 05, 13:10    [1330920]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
vadiminfo
Member

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

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

А разве собственно ООП не есть ОО парадигма программирования? Включая и проектирование. Однако что касается БД, то там все еще кажется что чего-то не хвает ООМД. Одного механического переноса ОО-парадигмы (т.е. принципов ОО) на БД вроде маловато. Наверное нужно еще что-то.
18 фев 05, 20:45    [1332633]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 PArth

>>"Во-вторых посты чингиза к делу как раз относятся. Это описание системы аналогичной приведенной Alexey Rovd"

>Каким боком относятся-то?

Повторяю еще раз:

Во-вторых посты чингиза к делу как раз относятся. Это описание системы аналогичной приведенной Alexey Rovd:

Bosch Security Systems встроила ООСУБД FastObjects t7 в систему управления и мониторинга сетей безопасности RUBIN NT. RUBIN NT — это приложение для контроля состояния, визуализации структуры и событий и управления системами безопасности, с помощью которого один человек способен контролировать все системы, имеющиеся в здании (подробнее).


Был приведен пример задачи как аргумент в пользу ООБД. Чингиз привел контрпример, демонстрирующий, что предыдущий аргумент на самом дел не аргумент, поскольку в РСУБД это сделать может даже легче.

2 Alexey Rovdo

Но привести реальный пример существующей системы мне показалось более веским аргументом. Проще ли и эффективнее ли использование FastObjects именнно в этой предметной области по сравнению с Sybase, Oracle или MS SQL? Не знаю (вернее не могу сказать что-то однозначное). Но разработчики Bosch решили, что проще (а может им FastObjects просто понравился) и сделали на его базе вполне нормальную систему.

Э нет. Разработчики Bosch как раз заявии, что средствами РСУБД эту задачу решить невозможно, поскольку РСУБД не позволяют автоматизировать бекапы. Вот что там сказано: "Because RUBIN NT provides 24 hour monitoring and is commonly deployed at facilities with no IT staff available, Bosch could not use a typical database that would require maintenance technicians to shut down the RUBIN server on a regular basis to run special tools for backing up the database and performance tuning. ... Bosch chose to store their data using FastObjects because the FastObjects administrative API allowed them to automate all database maintenance, such as backups, and build a system....". (http://www.versant.com/solutions/industrial/customers_story/bosch)
19 фев 05, 03:43    [1332808]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
tchingiz
Member

Откуда:
Сообщений: 39055
2Path

во вторых,
относится тем, боком, что от ООП особо много не надо, а надо, скорее, мало.
это если просто выполняешь требования заказчиков и экономишь свой труд.
а если доставляет наслаждение игра в кубики, ой в обьекты, тогда да.
тогда надо много.
19 фев 05, 03:55    [1332811]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
tchingiz
Member

Откуда:
Сообщений: 39055
для тех, кто уже чтото освоил, переход на продукты Версант - сомнителен,
пока не видно пользы, оправдывающей новые трудозатраты.
для тех, кто ничего не освоил, сомнителен, в связи с замечанием Выбегалло
19 фев 05, 03:58    [1332812]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

>Поддерживаются View и даже хранимые процедуры на C++ (компилируются в DLL). Но вся обработка идет, разумеется, на том компе, где эти DLL и FO Connect установлены, а обратиться к ним удаленно так просто нельзя.

Тогда это не хранимые процедуры. Хранимые процедуры это (неформально) то, что хранится файлах БД и выполняется на сервере.

c127> Вот я и говорю: по Вашему же решению Вашей же многострадальной задачи этого не скажешь. Приведите ОО решение или покажите на другом пимере как это делается. За то время, которое потрачено Вами на набивание этих килобайтов текста Вы могли уже 10 решить эту задачу. Если не используете cut-paste, конечно.

>Да, вероятно мог бы. Но все-таки для чего?


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

> В нашем споре мы постоянно неявно отождествляем сам ОО-подход с использованием ООСУБД и это НЕПРАВИЛЬНО, поскольку такое отождествление постоянно приводит нас к тупиковому спору о полезности ООП.

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

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

Если Вы например пропагандируете СКЛ, то должны быть готовы к спору о преимуществах декларативных языков по сравнению с императивными. Ибо именно там эти преимущества, которые есть Вашими аргументами, и проявляются. То же самое и об ООБД и ООП, нужно быть готовым к разговору об ООП. Поэтому я с Вами не согласен, обсуждение ООП (только в применении к хранению данных, хоть я и не знаю как это) не есть уход в сторону, это как раз в тему.

>Я кстати так и не убедился пока насчет константго времени поиска, но предложенный вами способ действий просто требует определенного времени для реализации (а этот форум далеко не единственное место, которое занимает мое время).

Не помню чтоб я что-то предложил по поводу константного времени поиска.
19 фев 05, 04:20    [1332821]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
PArth
Member

Откуда: теткина деревня
Сообщений: 48
2 с127:

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

Легче? А он что сделал 2 варианта и сравнил? Для кого легче? В чем легче? Сомнительный "контрпример"...

А каким образом "backups, and build a system...." стало относиться к реляционным либо объектным технологиям?
Во фразе: "typical database that would require maintenance technicians to shut down the RUBIN server on a regular basis to run special tools for backing up the database and performance tuning" я что-то не заметил упоминания о РСУБД. Вы не допускаете мысли, что под "typical database" бошевцы могли иметь в виду что-то другое? В любом случае считаю, что огульная критика этой фразы некорректна - Вы просто трактуете ее, как Вам Выгоднее...

"Я> Кто-то говорил, что этого нельзя сделать "классическими средствами"? Или это принципиально нельзя реализовать ОО инструментарием? Поясните пожалуйста..." 18 фев 05, 10:25

Вы так и не ответили...

"tchingiz> в работе использовалось 5 абстракций (обьектов) от с127 (я юзал его код)" 17 фев 05, 04:03

Так значит, балуетесь "втихаря" ООП? :-))))

2 tchingiz:

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


Это Вам не надо... Почему Вы с таким презрением относитесь к тем, кому это надо? Может Вы просто его (ООП) не поняли? В таком случае, у нас разровор глухого со слепым...
19 фев 05, 09:11    [1332915]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 PArth

с127> Был приведен пример задачи как аргумент в пользу ООБД. Чингиз привел контрпример, демонстрирующий, что предыдущий аргумент на самом дел не аргумент, поскольку в РСУБД это сделать может даже легче"

Легче? А он что сделал 2 варианта и сравнил? Для кого легче? В чем легче? Сомнительный "контрпример"...


Прочитайте-ка мое высказываение повнимательнее.

>А каким образом "backups, and build a system...." стало относиться к реляционным либо объектным технологиям?
Во фразе: "typical database that would require maintenance technicians to shut down the RUBIN server on a regular basis to run special tools for backing up the database and performance tuning" я что-то не заметил упоминания о РСУБД. Вы не допускаете мысли, что под "typical database" бошевцы могли иметь в виду что-то другое?


Разумеется они говорили о таких распространенных (типичных) БД как сетевые и иерарахические. Они же занимают подавляющую долю рынка, поэтому именно к ним относится понятие typical, это всем известно.

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

Имеете право.

"Я> Кто-то говорил, что этого нельзя сделать "классическими средствами"? Или это принципиально нельзя реализовать ОО инструментарием? Поясните пожалуйста..." 18 фев 05, 10:25

Вы так и не ответили...


А я тут при чем? Вроде ничего такого не говорил. Ссылку приведите.
19 фев 05, 09:59    [1332933]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
PArth
Member

Откуда: теткина деревня
Сообщений: 48
2 c127:

"Разумеется они говорили о таких распространенных (типичных) БД как сетевые и иерарахические. Они же занимают подавляющую долю рынка, поэтому именно к ним относится понятие typical, это всем известно."

А сны вы не толкуете случайно?
19 фев 05, 14:07    [1333110]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
PArth
Member

Откуда: теткина деревня
Сообщений: 48
2 c127 again:

" я тут при чем? Вроде ничего такого не говорил. Ссылку приведите"

Приношу свои извинения персонально Вам. Вы действительно этого не говорили. Просто Вы очень настойчиво просите от Alexey Rovdo доказательств, что ООБД лучше. А с тем, что они не хуже, никак не можете примириться... (Это меня и "завело", подтолкнув к некорректным высказываниям в Ваш адрес. Sorry еще раз...)
IMHO обсуждать достоинства и недостатки технологий ООБД в целом пока рановато, пока что можно лишь говорить о конкретных реализациях - с их достоинствами и недостатками соответственно...
19 фев 05, 14:27    [1333125]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 PArth

>А сны вы не толкуете случайно?

Как Вы догадались? Случается иногда, но только в свободное от составления гороскопов время.

>Приношу свои извинения персонально Вам. Вы действительно этого не говорили.

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

>Просто Вы очень настойчиво просите от Alexey Rovdo доказательств, что ООБД лучше. А с тем, что они не хуже, никак не можете примириться... (Это меня и "завело", подтолкнув к некорректным высказываниям в Ваш адрес. Sorry еще раз...)

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

Во-вторых, как я уже говорил, чтоб отвоевать рынок у зарекомендовавшей себя технологии быть "не хуже" недостаточно. От добра добра не ищут, как известно. Нужно быть лучше, причем существенно, поскольку люди консервативны. Поэтому чтоб я, например, переключился на ООБД, мне нужно доказать, что ООБД существенно упростят мою жизнь, т.е. что они именно лучше и не в мелочах, а в целом.
19 фев 05, 23:59    [1333508]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
tchingiz
Member

Откуда:
Сообщений: 39055
PArth


"tchingiz> в работе использовалось 5 абстракций (обьектов) от с127 (я юзал его код)" 17 фев 05, 04:03

Так значит, балуетесь "втихаря" ООП? :-))))

2 tchingiz:

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


Это Вам не надо... Почему Вы с таким презрением относитесь к тем, кому это надо? Может Вы просто его (ООП) не поняли? В таком случае, у нас разровор глухого со слепым...


может и не понял, хотя полиморфизм, наследование и инкапсуляцию втихаря использую. до тех пор, пока работать не мешает.
20 фев 05, 05:49    [1333594]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

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

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

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


А мне кажется, что "некоторые очень частные свойства" в некоторых частных (читай практических) ситуациях и могут дать то самое "причем существенно". А вот "в целом" - это уже понятие достаточно абстрактное.
Та же быстрая разадресация позволяет в некоторых случаях увеличивать производительность на порядок (и даже более), что, согласитесь, достаточно существенно. Именно поэтому я с вами так долго спорю именно о быстродействии разадресации - как только вы со мной согласитесь именно в части быстродействия, привести примеры таких практических ситуаций уже будет не сложно.
20 фев 05, 11:48    [1333677]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
PArth
Member

Откуда: теткина деревня
Сообщений: 48
2 c127:

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

Лучше, хуже... См. :-)
IMHO можно говорить только в чем лучше/хуже... А вот насчет насколько (существенно/несущественно) лучше... - ??? В чем измерять-то будем?

"Поэтому чтоб я, например, переключился на ООБД, мне нужно доказать, что ООБД существенно упростят мою жизнь, т.е. что они именно лучше и не в мелочах, а в целом"

Могу Вас заверить, что при наличии у Вас любой (даже небольшой) уже существующей системы переход на новые технологии не упростит Вам жизнь, а даже наооборот... Переделывать придется ВСЕ. Надеюсь Вы это понимаете... И осваивать новые для себя технологии есть смысл только на новых проектах.
Но агитировать за переход на ООСУБД лично я никого не собираюсь. Просто пытался объяснить, почему я решил попробовать ООБД "вживую"...
20 фев 05, 21:06    [1333894]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Alexey Rovdo
Та же быстрая разадресация позволяет в некоторых случаях увеличивать производительность на порядок (и даже более), что, согласитесь, достаточно существенно. Именно поэтому я с вами так долго спорю именно о быстродействии разадресации - как только вы со мной согласитесь именно в части быстродействия, привести примеры таких практических ситуаций уже будет не сложно.


Я так понял основной аргумент остался - быстрая разадресация . Т.е. когда поиск идёт не по индексу, а по прямому адресу. Давайте подумаем как это будет реализовано.
Очевидно что постоянный физический адрес у объекта(наподобие его смещения в файле БД) быть не может - один объект может увеличиваться в размере и "залезать" на другой, может быть сильная фрагментация и следоватено для ускорения работы необходима будет делать дефрагментацию со сменой адресов, наверняка можно еще чего-то вспомнить. Я думаю врядли кто с этим будет спорить.
Теперь если у нас меняется адрес объекта, то мы должны либо поменять и во всех объектах, которые на него ссылаются, в том числе и на клиентах - что невозможно сделать изнутри базы, либо остаётся ввести дополнительную абстракцию для адреса объекта, не связанную с физическим адресом(а если еще учесть что база может находиться в нескольких файлах).
Дык вот я не вижу принципиальной разницы между поиском физического адреса по его абстракции и поиском первичного ключа по индексу.
Но даже если такая разница и есть - откуда Вы решили что на порядок? Почему не на два порядка? Давайте хоть как-то обосновывать свои заявления
20 фев 05, 22:54    [1333932]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
vadiminfo
Member

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

Я так понял основной аргумент остался - быстрая разадресация

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

SergSuper

Т.е. когда поиск идёт не по индексу, а по прямому адресу.

С одной стороны нет ничего, что отменяло бы это и в РСУБД. Например, у Оракло есть rowid - псевдоколонка где прописан адрес. И действительно, что мешает запомнить прямой адрес в момент создания записей? Но для БД главная задержка при чтении с диска. А индекс помогает сократить именно эти чтения. Поэтому врядли jy проиграет в тех случаях где он уместен.
Но, возможно, Alexey Rovdo имел в виду что-то другое под разадресацией?
А с другой стороны о каком поиске идет речь? Если там сканирование по диапазону или еще что, то все равно имеет значение какое-то упорядочение по значениям атрибутов или что-то в этом роде. Т.е. одних адресов не достаточно.
21 фев 05, 01:02    [1333966]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 PArth

>В чем измерять-то будем?

Интуитивно, по совокупности. В какой-то момент преимущество, если оно есть, станет очевидным.

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

Об этом и речь.

2 Alexey Rovdo

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


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

Тут только что были приведены очень убедительные по-моему аргументы в пользу того, что поиск в ООБД будет работать с той же скоростью или даже медленнне, но никак ни быстрее. Поиск объекта в ООБД по идентификатору в принципе ничем не отличается от поиска записи в РСУБД по ключу. Если в ООБД используются какие-то алгоритмы, то в РСУБД, оптимизированных до невозможности, они используются наверняка. Скорее всего в ООБД используется тот же хеш алгоритм, ничего более подходящего к данной ситуации человечество вроде не придумало.
21 фев 05, 06:10    [1334030]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Не вижу смысла (а скорее - не имею времени и возможности) рассматривать множество аргументов, если и с одним то разобраться никак не получается. А вопрос сводится к тому, что было описано мною здесь.

В принципе мне пока не удалось убедить c127 в своем утверждении:

c127

К тому же мы еше не убедились, что поиск (этот термин лучше чем разадресация) в ООБД работает быстрее.


Я бы все-таки говорил о сравнении быстродействия JOIN-запросов в РСУБД(предполагающих некий поиск при их выполнении) с быстродействием непосредственной навигации в ООСУБД (в принципе тоже предполагающей некий поиск).

Пока остановились на том, что необходимо продолжить эксперименты на оракловой базе с большим объемом данных. Обязательно продолжим, а пока времени нет.
21 фев 05, 10:30    [1334389]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
vadiminfo
Например, у Оракло есть rowid - псевдоколонка где прописан адрес. И действительно, что мешает запомнить прямой адрес в момент создания записей?


ROWID не хранится для каждой записи. Это просто физический адрес данных, аналог номера записи в DBF.
21 фев 05, 10:50    [1334440]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
vadiminfo
Member

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

Я бы все-таки говорил о сравнении быстродействия JOIN-запросов в РСУБД(предполагающих некий поиск при их выполнении) с быстродействием непосредственной навигации в ООСУБД (в принципе тоже предполагающей некий поиск).

Пока остановились на том, что необходимо продолжить эксперименты на оракловой базе с большим объемом данных. Обязательно продолжим, а пока времени нет.



Давайте найдем такой запрос. А как же мы прверим? Ить компы то у нас разные. У меня есть Орклы, но нет Версанта. У Вас есть Оракл и какой версии?

Gluk (Kazan)

ROWID не хранится для каждой записи. Это просто физический адрес данных, аналог номера записи в DBF.

Я был не прав. Но пока еще не понял, что скрывается под разадресацией.
21 фев 05, 12:56    [1335011]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Насколько я понял в Versant имеется нечто весьма аналогичное ROWID, но естественно на этом свет клином не сошелся, так как нет многого другого.
21 фев 05, 13:16    [1335097]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Действительно, ROWID в Oracle во многом и есть то, что я называю "адресом объекта", когда говорю о Versant FastObjects (пока говорим только об этой системе, но для VDS все примерно также).
Давайте теперь посмотрим в чем собственно состоит проблема (и о чем наш спор с c127). Итак, можем ли мы использовать этот ROWID каким-либо образом при наличии связи one-to-many между двумя таблицами? При обычном раскладе в одной таблице есть уникальный атрибут, а в другой - ссылка на него (FOREGN KEY). Если принять сам ROWID за такой уникальный атрибут, то его вроде бы можно засунуть и в FOREGN KEY. Вот только так никто не делает при проектировании реляционных схем данных, да и не совсем понятно как поведет себя Oracle при обработке запросов вида:

SELECT table1.*, table2.* FROM table1, table2
WHERE table2.rowid = table1.child_rowid and
table1.attrib1 = 'value';

Во-первых, допускает ли Oracle такие запросы в принципе? И будет ли он использовать прямой доступ к соотвествующей записи в table2 именно по уже найденному значению из записи child_rowid в table1 (а именно так поступает ООСУБД при обработке прямой навигации типа object1.child_object2.attrib1)? Если ответ "Да будет", то это во многом сближает Oracle с объектными системами (но не за счет его преимуществ как реляционной СУБД, а за счет реализации в нем собственно объектных функций, присущих ООСУБД с рождения).

Впрочем, c127 утверждает, что в таком примере даже замена rowid на логический идентификатор (некий table2_id) не приведет к падению быстродействия запроса и позволит получать доступ к данным столь же быстро, как и в ООСУБД при использовании физических идентификаторов (аналогов ROWID).
21 фев 05, 16:26    [1336061]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
ROWID не рекомендуется использовать в приложениях (технически это ВОЗМОЖНО) по вполне понятным причинам. ОНИ МОГУТ ИЗМЕНИТЬСЯ. Например после экспорта/импорта. ЭТО ФИЗИЧЕСКИЙ АДРЕС. Приложение не должно использовать его, в противном случае, она будет очень сильно привязана к физике. Думаю, что эти рассуждения справедливы и для ООСУБД.
21 фев 05, 16:35    [1336096]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 [19] 20 21 22 23 .. 34   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить