IMS

[crazy-mike]

Одна из самых первых СУБД от IBM. SQL тогда "ещё не родился"...;)
http://www-306.ibm.com/software/data/ims/
http://www-306.ibm.com/software/data/ims/images/ims10-141x120.jpg
Но её идеи живут в интерфейсах dbm,ndbm и в Berkeley DB (которую съела Oracle)!!!!!!!!!!!!!!!!!!!!
Вот этим кончила sleepycat software:
http://www.oracle.com/database/berkeley-db/index.html

[смешно]

базы данных....моя слабость...:bis:

Майки, а Клиппер помнишь?

[crazy-mike]

базы данных....моя слабость...:bis:
Даже dBase2 и MUMPS помню. :grum: Но мы здесь будем говорить о настоящих мужских DBMS - а не о Female Search Query Language.

[Alex_3112]

Даже dBase2 и MUMPS помню. :grum: Но мы здесь будем говорить о настоящих мужских DBMS - а не о Female Search Query Language.
Ладно тебе, все бородатые ныне программисты начинали с FoxPro и dBase :)

[crazy-mike]

Ладно тебе, все бородатые ныне программисты начинали с FoxPro и dBase :)
Ну нет у меня бороды. Усы - есть. На System/360 никакого dBase не было. Да и наборы данных там больше похожи на dbspace чем на современные файлы. И каждый из access methods представлял собой DBMS.

[crazy-mike]

Кстати у рассматриваемых здесь СУБД есть одно интересное преимущество по сравнению с "родственниками с поддержкой SQL".
;)
Допустим - нам нужно держать очень много числовых данных в двоичной форме. Т.е. я хочу - чтобы целое число занимало четыре байта (или восемь байт) без всяких заморочек с числом значащих цифр и нужно всё это вытаскивать из "хранилища" по каким либо "двоичным критериям" (если функция - аргументом которой являются данные из БД - вернёт нужное значение то ...).
SQL запрос выполняет "преобразование данных из формы хранения в форму вывода" - если "преобразование" вообще не нужно - (когда просто выбирается начальное приближение для запуска какого-нибудь метода численного интегрирования к примеру или "поиск на графе") - то от SQL целесообразно отказаться и воспользоваться "помощью его предков" (с их родными интерфейсами)...;)

[смешно]

Что ни говори, а СУБД далеко не продвинулись за последние много лет, в сравнении с другими системами, да и вообще. Производительность говяная, слишком всё усложнили, администрация, требования к железу постоянно растут. Чего так?
Почему DB вообще до сих пор нужна OS?? И опять же эти 32 бита/64 бита. Чё за куйня? Сделайте 128 бит да подешевле, и железо и DBMS.
Такой ящичек, типо PlayStation, называться будет "128 bit DB", подключаешь куда хочешь. Так нет, бабки здесь огромные завязаны и политика гигантов...

[crazy-mike]

Что ни говори, а СУБД далеко не продвинулись за последние много лет, в сравнении с другими системами ...
;) Не совсем так. Довольно много интересных методов хеширования придумали и реализовали. С B-деревьями научились сравнительно эффективно работать...
В ранних системах 70-х годов в самом деле не было чёткого разделения на файловые системы и DMS /DBMS . "Файловые системы общего назначения" - это уже где-то в Multics,Unix и т.д. Конечно была и RT-11 и RSX-11. Но в RT-11 так называемый "файл" занимал смежные блоки на диске...Появление PC с MS-DOS в какой-то мере было "шагом назад". Хотя подфункции int 21h поддерживали очень усечённый вариант DMS. Том БД - больше было характерно для систем IBM. Тем не менее вариант "DBMS вместо файловой системы" существовал практически во всех LISP-системах и MUMPS-системах.
;) MUMPS очень интересно "эволюционировал" от работы с B-деревьями к комбинированным методам с использованием хеш-функций...

[Alex_3112]

Почему DB вообще до сих пор нужна OS??
А кто будет разруливать хардверные конфликты с 100,000 устройств от 1001 производителя?

[crazy-mike]

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

[смешно]

А кто будет разруливать хардверные конфликты с 100,000 устройств от 1001 производителя?

Какие конфликты? Пусть сделают грамотно, да и чего там надо? хард драйв, мемори, CPU. Таже Sony playstation. Если Оракл обьединится усилиями с Интел, то они могут такой аппарат сделать. Ведь посмотри сколько бабок выбрасывают на железо для баз данных, которые с выходом новых версий становятся не совместимы. Мрак. А обслуживание и поддержка? Надо держать спеца по железу, OS и ДБА, да ещё секьюрити....

[смешно]

;) Не совсем так. Довольно много интересных методов хеширования придумали и реализовали. С B-деревьями научились сравнительно эффективно работать...
В ранних системах 70-х годов в самом деле не было чёткого разделения на файловые системы и DMS /DBMS . "Файловые системы общего назначения" - это уже где-то в Multics,Unix и т.д. Конечно была и RT-11 и RSX-11. Но в RT-11 так называемый "файл" занимал смежные блоки на диске...Появление PC с MS-DOS в какой-то мере было "шагом назад". Хотя подфункции int 21h поддерживали очень усечённый вариант DMS. Том БД - больше было характерно для систем IBM. Тем не менее вариант "DBMS вместо файловой системы" существовал практически во всех LISP-системах и MUMPS-системах.
;) MUMPS очень интересно "эволюционировал" от работы с B-деревьями к комбинированным методам с использованием хеш-функций...

Ну и чего? Какой толк-то? Все современные DBMS это те же файловые системы. С сомнительной производительностью и офигенными ценами per transaction. Опять же ограничения OS, сети, security, в итоге плачевные результаты.

[crazy-mike]

Ну и чего? Какой толк-то? Все современные DBMS это те же файловые системы.
Это неправильный ответ...;)
Точнее было бы сказать - что "файловая система" в какой-то мере является разновидностью DBMS...:evillaugh
Для сравнения - в "файловых системах" для POSIX-систем просто отказались от понятия "record" или "item" и ввели "логическую адресацию с точностью до байта относительно начала набора данных" . Когда-то "давно" на такое просто "не решались"...Для "родной DB2" вообще-то существует понятие Database Volume. (Да и не только для DB2). В IMS - тоже существовало понятие "том базы данных" с самого начала! В MySQL - существует возможность (которой практически никто из LAMP-халявщиков не пользуется) создавать "том БД" (вообще вне файловой системы)...В Oracle - тоже.
:cool: Самое прикольное то - что "файловая система" по отношению к DBMS является вторичной (у DBMS случился "выкидыш" в виде "файловой системы общего назначения") .

[смешно]

Майки, ты можешь это называть как угодно, но со стороны OS, всё это выглядит как обычные файлы, т.к. OS это главное на чём сидят вонючие DBMS. Помню вроде Оракл грозился сделать свою OS под свою платформу, но похоже всё стухло.

Вот неплохая статейка.

http://www.cnet.com/8301-13556_1-9815094-61.html

November 12, 2007 8:37 AM PST
Oracle: Just say no to operating systems
Posted by Gordon Haff 2 comments[Update: Corrected name of rPath CEO Billy Marshall.]

There's a nasty little war afoot over the future of the operating system.

In one corner you have the operating system vendors.

They're building in virtualization, for example. This increases the depth of their software stack. The OS vendors present virtualization as a natural addition to existing operating system functions and a means to integrate an increasingly-common software capability.

That's fair enough. But it's also about control, especially in a world where owning the hypervisor gives you an advantage when up-selling to management layers and other value-add software in which there's real money to be made (as opposed to the raw hypervisor, which is becoming increasingly commoditized).

As we saw last week in the case of Red Hat, OS vendors are on the lookout to circumvent attempts to make their operating systems (and their brands) irrelevant. In Red Hat's case, it was to quash the efforts of software appliance makers to effectively make the OS just a supporting feature of the application.

In another corner, you have the application vendors and their fellow travelers.

Software as a service (SaaS) is one aspect of this war. Taken to its logical extreme, it may change the role of systems companies as well as operating system vendors. However, we don't need to look that far into possible futures to see the application vendor front in this war.

Take the appliance makers that Red Hat was taking on last week. Rpath CEO Billy Marshall writes: "Fortunately for all of us, 'certification' will be a thing of the past when applications companies distribute their applications as virtual appliances." It's not hard to see why Red Hat doesn't exactly cotton to this way of thinking. After all, certification is a very large part of what Red Hat sells. And the number of applications certified to run on Red Hat comprises a huge barrier to any other Linux vendor delivering its own flavor of "Enterprise Linux."

Oracle's Unbreakable Linux is a different take from a different angle, but the end result is the same. Its concept is based on the idea that, when you buy an application from Oracle, you also get some bits that let the application sit on top of the hardware and perform necessary tasks like talking to disk. Oracle has been subsuming operating system functions like memory and storage management for years; subsuming the whole operating system was just the next logical step.

So is its latest move, coming out with its own hypervisor based on technology from the widely-used Xen Project. (Xen is also the basis for the hypervisor in Novell and Red Hat Linux--as well as OS-independent products from XenSource/Citrix and Virtual Iron.)

Just as Oracle wants to minimize the role of the OS, so too does it want to minimize the role of the hypervisor (which, as I noted, itself threatens to reduce the role of the OS--got all that?). From the vantage of Redwood Shores, VMware is getting altogether too much attention. The easiest way to minimize the impact of the virtualization players? Offer Oracle's own hypervisor.

The biggest challenge that I see facing Oracle here is similar to that facing Unbreakable Linux and software appliances in general. There's an implicit assumption that people will be willing to have one virtualization for their boxes that run Oracle and another virtualization for everything else--that the maker of the hypervisor bits doesn't matter.

So far, there's scant evidence that people are willing to be quite so blase about their server virtualization. Furthermore, brand preferences aside, it remains early days for standards that handle the control and movement of virtual machines across virtual infrastructures sourced from different vendors. It's perhaps more thinkable that Oracle database and application servers might be kept independent from a general virtual infrastructure than would be the case with other, often less business-critical, applications. But, at least today, its still counter the overall trend of IT shops looking at server virtualization in strategic rather than machine-by-machine tactical ways.

As a result, I don't see this announcement having a broad near-term impact (as, indeed, Unbreakable Linux did not either, once the original raft of press stories and industry discussion died down). Rather, I see this as Oracle determined to keep making its statement, time and time again, that, someday, the operating system won't matter. That's Larry's story, and he's sticking with it.

[Alex_3112]

Какие конфликты? Пусть сделают грамотно, да и чего там надо? хард драйв, мемори, CPU. Таже Sony playstation.
Еще network, дисплей, органы управления...
Sony Playstation - это конечный продукт, в своем виде удовлетворяющий миллионы пользователей. При этом они тоже глючат и ломаются. Потребителям баз данных понадобится большая гибкость конфигурации. Им может захотеться сделать upgrade. Придется каждый раз вызывать техников on-site, а самим - ни-ни!
И так как этих "машин баз данных" будет выпускаться гораздо меньше, чем Playstation, или даже PC-серверов, Research&Development costs окажутся высокими. Получится proprietory продукт, который будет для клиентов "черным ящиком" с ценой выше, чем сегодняшние PC-сервер + OS + RDBMS

[Alex_3112]

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

[смешно]

Еще network, дисплей, органы управления...
Sony Playstation - это конечный продукт, в своем виде удовлетворяющий миллионы пользователей. При этом они тоже глючат и ломаются. Потребителям баз данных понадобится большая гибкость конфигурации. Им может захотеться сделать upgrade. Придется каждый раз вызывать техников on-site, а самим - ни-ни!
И так как этих "машин баз данных" будет выпускаться гораздо меньше, чем Playstation, или даже PC-серверов, Research&Development costs окажутся высокими. Получится proprietory продукт, который будет для клиентов "черным ящиком" с ценой выше, чем сегодняшние PC-сервер + OS + RDBMS

Диплей для Базы Данных не надо, Network стандартный.
Никаких upgrade железа! Всё как в Playstation 1, 2, 3. хотя софт всегда можно upgrade типо как в DirectTV ресиверах, firmware.
Никаких головных болей.

[смешно]

Для DB можно выделять целые диски, и OS туда будет вход закрыт.

Понятное дело, это научились делать.

[Alex_3112]

Никаких головных болей.
Утопия.
Головные боли будут у сервиса и кастомер суппорта. У клиентов будут обычные простои.

P.S. Можно поставить ту же AS/400 - чем не вариант? :)

[crazy-mike]

А в основных ОС IBM даже на System /360 файл мог занимать несколько дисков. Да и в OS Novell - тоже. А VM/360 у IBM как раз и служит до сих пор источником вдохновения для разработчиков Xen...

[crazy-mike]

Утопия.
Головные боли будут у сервиса и кастомер суппорта. У клиентов будут обычные простои.
:)
http://www.upnp.org/
Для своеобразного "тренда" под названием Digital Home стало появляться очень много интересных стандартов - использование которых может сделать "традиционные серверные DBMS" принципиально излишними.
Очень интересен подход у Digital Living Network Alliance - http://www.dlna.org.
Формально - только для Digital Home. Но вообще-то похожие стандарты можно распространить на всё - что попало. Объекты в сети сами друг друга ищут и конфигурируются в зависимости от окружения. Ну и определяют источники и форматы требуемых данных через опрос по сети. И никаких "выделенных серверов" - кроме каких-нибудь "брокеров запросов"....;) Почему приложение вообще должно знать о каких-либо DBMS? Ему ведь только актуализированные данные в требуемом формате нужны...:evillaugh

[Alex_3112]

Объекты в сети сами друг друга ищут и конфигурируются в зависимости от окружения. Ну и определяют источники и форматы требуемых данных через опрос по сети. И никаких "выделенных серверов" - кроме каких-нибудь "брокеров запросов"....;) Почему приложение вообще должно знать о каких-либо DBMS? Ему ведь только актуализированные данные в требуемом формате нужны...:evillaugh
Это - дело очень отдаленного будущего, дизайн типа нейронных сетей. Сегодня все данные должны где-то храниться, архивироваться, и доступ к ним должен быть эффективным. Это лучше всего реализуется средствами традиционных DBMS. Максимум чего пока можно достичь - это спрятать эту DBMS за другим фасадом, и пусть все думают, что это такой же такой объект как они сами, только знает побольше :)

[crazy-mike]

Максимум чего пока можно достичь - это спрятать эту DBMS за другим фасадом, и пусть все думают, что это такой же такой объект как они сами, только знает побольше :)
В последнее время и в самом деле "в больших системах" так и делают. :grum:
Но удобнее рассматривать любую систему из устройств в сети (к примеру - коммутаторов) - именно как DBMS. И воспринимать её как "сетевую БД"...
И даже делать запросы "select работающие from подключённые" = И чтобы результат при этом был "из дерева SNMP" (только как вариант). Фактически даже SNMP - это тоже разновидность "DBMS" (да ещё и "распределённая" и "децентрализованная") ...:bis:

[Alex_3112]

И даже делать запросы "select работающие from подключённые" = И чтобы результат при этом был "из дерева SNMP" (только как вариант). Фактически даже SNMP - это тоже разновидность "DBMS" (да ещё и "распределённая" и "децентрализованная") ...:bis:
SNMP и DBMS преследуют разные цели.
SNMP работает по принципу - "Чем богаты, тем и рады". Бессмысленно пытаться добиться чего-то от устройства, которое выключено или вообще физически отсутствует.
В DBMS есть очень четкие ожидания того, что данные есть. Где именно они есть - уже не так важно, но если их нет или они недоступны, то это караул и ахтунг; DBMS не может функционировать частично, как локальная сеть например.

[crazy-mike]

DBMS не может функционировать частично, как локальная сеть например. Как раз это DBMS могут. Недоступные элементы системы могут считаться просто locked. Правда и дерево поиска для конкретного элемента может быть не одно. Да и ситуации ЭЛЕМЕНТ-НЕ-НАЙДЕН и ЭЛЕМЕНТ-ОТСУТСТВУЕТ будут неэквивалентными...;) Просто cursor -ов будет много.

[Alex_3112]

Как раз это DBMS могут. Недоступные элементы системы могут считаться просто locked.
Теоретически - да. Практически приложение должно уметь штатно отрабатывать подобные ситуации. Это легко делается, когда функционально разные элементы разнесены по разным базам данных, и ставит системы в тупик, когда один из недоступных элементов - критический для работы приложения.

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

Да и ситуации ЭЛЕМЕНТ-НЕ-НАЙДЕН и ЭЛЕМЕНТ-ОТСУТСТВУЕТ будут неэквивалентными...;) Просто cursor -ов будет много.
То есть придется усложнить приложение... можно, конечно. Но зачем?

[crazy-mike]

То есть придется усложнить приложение... можно, конечно. Но зачем?
На самом деле приложение фактически упрощается. Хотя бы потому - что вообще не нужен контроль за соединением с серверами БД. Все функции доступа к объектам сети фактически "инкапсулирулируются" в варианты запросов ioctl. При этом даже "контроль доступных устройств" может выполняться по GN (Get-Next - очень похоже как раз на IMS). И даже определённый выигрыш в смысле безопасности - если нет "сервера" , то и "уложить" просто нечего!!!!!!!

[Alex_3112]

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

[crazy-mike]

Если приложению для выполнения какой-то операции нужно 10 таблиц (или независимых объектов), то оно вывалится, если хотя бы одна из них будет недоступна.
Это только в "тупых реляционных БД"....И то даже там - можно предусмотреть реакцию на "недоступность данных" и даже на "использование доступных данных" (запасной копии "синхронизированной по дате").
Скажем - это мог быть "триггер On-Not-Allowed" какой-нибудь. И вообще обычное "пользовательское приложение" не должно ничего об этом знать.
"Детали реализации механизма доступа к данным" от такого приложения обычно "скрыты" (hidden). Просто в этом случае dbspace самоконфигурируется из автомномных "slices" (которые сами ищут - в какую структуру они на самом деле входят и выдают сигнал о своей собственной доступности).

[Alex_3112]

"Детали реализации механизма доступа к данным" от такого приложения обычно "скрыты" (hidden). Просто в этом случае dbspace самоконфигурируется из автомномных "slices" (которые сами ищут - в какую структуру они на самом деле входят и выдают сигнал о своей собственной доступности).
Ага, вот теперь становится понятнее.
Это вполне возможный вариант, но при сегодняшнем уровне развития технологий, серверы RDBMS существенно надежнее и эффективнее сетей связанных друг с другом объектов. Примерно как "Звезда Смерти" в "Звездных Войнах" намного сильнее целого флота постанцев (если не знать ее ахиллесову пяту, конечно :) )

[crazy-mike]

Это вполне возможный вариант, но при сегодняшнем уровне развития технологий, серверы RDBMS существенно надежнее ... Примерно как "Звезда Смерти" в "Звездных Войнах" намного сильнее целого флота постанцев (если не знать ее ахиллесову пяту, конечно :) ) 3везду смерти повстанцы ведь атаковали одновременно с разных направлений? Децентрализованную систему таким путём намного труднее атаковать.

[crazy-mike]

серверы RDBMS существенно надежнее и эффективнее сетей связанных друг с другом объектов. :) )
Ну а теперь представим довольно странную ситуацию когда dbspace сервера БД расположено в SAN (Storage Area Network). (Некоторые "энтузиасты" умудрялись создавать тома БД на дисках , монтируемых по NFS).
И какая разница после этого????
;)
А если учесть - что у жёстких дисков есть контроллеры (компьютеры) - которые (в принципе) тоже могут быть присоединены к сети как "самостоятельные сетевые устройства" - то "сервер БД" в какой-то мере начинает выполнять роль коммутатора (switch) . :cool:

[Alex_3112]

"сервер БД" в какой-то мере начинает выполнять роль коммутатора (switch) . :cool:
Разниуа между централизованной (RDBMS) и децентрализованной системами в том, что RDBMS контролирует все потоки данных и несет за них ответственность. В децентрализованной сети нет ни контроля сверху, ни ответственности нет.

[crazy-mike]

Разница между централизованной (RDBMS) и децентрализованной системами в том, что RDBMS контролирует все потоки данных и несет за них ответственность.
;) В последнее время RDBMS скорее контролируют Views....Я говорил как раз о том - что по мере изменения концепции периферийных устройств - RDBMS как раз и перестаёт всё "контролировать". Мало того - "контролирование" становится преградой для "эффективного распараллеливания" (в том числе операций поиска и обновления). В "децентрализованных системах" каждая "атомарная система" может выполнять поиск на своей части данных (как и обновление) и не обязательно дожидаться "полного завершения операции".

[peterburger]

Ну нет у меня бороды. Усы - есть. На System/360 никакого dBase не было. Да и наборы данных там больше похожи на dbspace чем на современные файлы. И каждый из access methods представлял собой DBMS.

О! Знакомое слово! :)
Хвастаюсь - на всех IBM Mainfraims можно найти мои инициалы
в SYS1.MACLIB, например.

[Alex_3112]

;) В последнее время RDBMS скорее контролируют Views....
Views к контролю никакого отношения не имеет. В России, например, есть и дума, и многопартийность, и гласность, и всеобщие выборы... но по большому счету это только видимость демократии :)

Я говорил как раз о том - что по мере изменения концепции периферийных устройств - RDBMS как раз и перестаёт всё "контролировать".
RDBMS контролирует, как может. Если диск смонтирован через NFS и находится где-то в другом здании, то у системы появляется физическая уязвимость. Чем больше мы разделяем систему, тем сильнее у нее уязвимость. Если RDBMS перестает контролировать данные, то за их целостность уже никто не может поручиться.

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

[crazy-mike]

Стоп, а вот поиск - это уже частная область, и RDBMS здесь уже не рулит. Ну не использует, например, Google, базы данных для поиска. RDBMS адекватны задачам, на них возлагаемым, главным образом, транзакциям - согласованным изменениям сразу нескольких объектов.
;) Это конечно же точка зрения вырабатывается практическим путём после опыта практической эксплуатации всех этих "RDBMS" на значительных объёмах данных у блоьшинства нормальных людей. :cool:
Правда всё - что связано с транзакциями - намного логичнее описывать через какой-нибудь вариант shared objects spaces (и такой вариант можно строить даже без "централизованного сервера" - когда каждый "объект" является сам себе "сервером" и контролирует особенности доступа)...И "иерархичность доступа" при этом описывается в терминах "наследования свойств".

[Alex_3112]

Правда всё - что связано с транзакциями - намного логичнее описывать через какой-нибудь вариант shared objects spaces
Есть обычные транзакции, и есть "распределенные". Вторые - гораздо геморройнее, и shared objects предлагает именно такой вариант. Должен быть софт-надстройка, отвечающий за целостность транзакции, и занимающийся "челночной дипломатией" со всеми объектами-участниками. В случае eдиной RDBMS всех этих ухищрений не нужно.

[crazy-mike]

Должен быть софт-надстройка, отвечающий за целостность транзакции, и занимающийся "челночной дипломатией" со всеми объектами-участниками. В случае eдиной RDBMS всех этих ухищрений не нужно.
"Почти нужен" ;) ...Объект класса transaction с конструктором у которого список участников является параметром. :grum:
Конструктор такого объекта "посылает сообщения" (вызывает соответствующие методы у каждого объекта-параметра). И всё становится таким "занудно-иерархическим" с exception-handler-ами и т.д. Это просто совсем другой подход для организации информационно-поисковых систем. А одно из его преимуществ - "адаптивность". Кстати - существует интересная разновидность баз данных - который очень условно можно было бы назвать как "read only databases". А теперь представим операцию "загрузка read-only-database" в объектно-ориентированной интерпретации. Просто вызываются конструкторы и выполняются промежуточные "побочные процедуры(методы)"....В таком варианте привлекает то - что принципиально можно "не ждать окончания выполнения запроса"...Это очень удобно - когда считываются показания внешних устройств (любые), работающих в сети. И при этом вообще никуда не надо "пересылать данные" (ни в какой сервер) - а просто координировать связи между "блоками управления".
;)
Очень давно (в конце 70-х начале 80-х годов) пробовали создавать "параллельные системы" с "синхронизацией процессов" по "готовности данных". И даже описывать такую архитектуру при помощи функциональных языков.

[crazy-mike]

Самое прикольное - что иерархические DBMS и в самом деле лучше соответствуют концепции "пространства объектов" - чем "реляционные".
Одно время существовал (в середине 80-х годов) даже термин "постреляционные базы данных". Это когда для размещения данных и доступу к единичным элементам данных использовалось "хеширование" или индексы (или и то и другое - вместе) , а для запросов какой-нибудь из языков , похожих на SQL.
http://www.rainingdata.com/products/index.html
D3 === (когда-то давно Pick DBMS. Просто Pick Systems вошла в состав Raining Data)
Родным языком запросов у "предка D3" было нечто с названием Acess!!!!!
И это всё можно было вызывать из программ на языке Pick Basic.