IMS

[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.