Как-то давно обсуждали иерархические базы данных.
А мне пришлось по случаю попользовать IBM IMS.
Что там говорили? Типа, необходимость программировать обход деревьев вручную, необходимость синхронизации деревьев между собой вручную, негибкость в смысле трудностей изменения структуры.
Вот эти три утверждения - это из разряда мифов, если применительно к IMS.
Да и вообще, она иерархическая только в том смысле, что в каждый момент времени клиентское приложение выполняет вызов по логической иерархии. Но сама модель сетевая - физические иерархии связываются между собой логическими ссылками-связями. Просто приложение не заморачивается физическими структурами и ссылками-связями, они для него недоступны
А так, по языку DL/I, наблюдается аналогия с SQL:
- есть аналог предложения SELECT, в котором указываются необходимые к возврату сегменты (коллекции полей, в принципе, поля, потому как IMS не трактует содержимое сегмента, за исключением ключей)
- есть аналог предложения FROM, в котором указывается, откуда извлекать данные, это всегда логическая иерархия, которая может быть результатом соединения по ссылкам-связям кучи физических иерархий, формирующими сеть
- есть аналог предложения WHERE, в котором указывается, по каким критериям отбирать данные для возврата, ну и наборы операций сравнения больше-меньше-равно и прочие.
Ну про экономность расходования ресурсов я говорить не буду, про производительность тоже.
Интересно решён вопрос с индексами - в IMS они называются secondary indexes - опционально при построении индекса по какому-то полю можно потребовать хранить адрес не того сегмента, в котором находится индексируемое поле, а любого сегмента, расположенного выше по иерархии. Ну и они могут быть разреженными.
Вообще очень гибкая система в плане построения разных структур, и в плане извлечения из них данных. Одних типов ссылок-связей между системами достаточно, для удовлетворения эротических потребностей - иерархические (1. сверху-вниз, 2. спереди-назад, 3. справа-налево), физический родитель, логический родитель, логический потомок, первый физический потомок, последний физический потомок, близнец, ну и плюс их разновидности forward-backward.
Замороченная до паранойи на производительности и качестве кода.
Построить систему можно не только после ответа на вопрос - "что храним?", то есть объекты и их взаимосвязи между собой, но и "как работаем?", то есть способ запрашивания объектов, последовательно, случайно, случайно-последовательно, сперва только эту порцию, потом все те, эти чаще, эти реже.
Но ответив на все эти вопросы - то есть представляя себе логику работы приложений - построить структуру особых проблем не возникает, если не считать проблемами необходимость соблюдения позиций параметров задачи структуры :)
А уж программировать прикладникам так вообще проще простого - нет никих вариантов в извлечении данных, только одним способом, который же и самый эффективный. Чем-то напоминает при программировании для ldap. но гибче. И вызовов совсем немного - вернуть, заменить, вставить, удалить, для вернуть есть вариация с блокированием.
Вот как-то так вот.

ну тогда про ресурсы и вопросы производительности потом.
Сейчас эспешиалли для Йо! про индексу и кто же таки будет переписывать запросы.
Так вот тут выбор большой.
Можно переписывать.
Можно не переписывать.
Можно процесить индекс как самостоятельную иерархию. Указав в предложении FROM тот факт, что работаем с индексом. То есть select from index.
Можно вообще построить совсем новую логическую иерархию, которая будет иметь сегмент с проиндексированным полем родительским, все остальные соответсвенно под ним, в том числе и бывший root сегмент. Но делает это системный программист, и не в запросах, а в PCB - Program Communication Block, аналог SQL VIEW.
Вообще вопрос не совсем коректный, роль прикладного программиста при работе с IMS резко понижается, никаких знаний SQL с его многовариантностью решений не требуется, снижается роль DBA - не надо изучать Explain и тюнить запросы, переписывать их, и прочая, и прочая. Но появляется новая очень важная роль - системного программиста. Эта роль вообще ключевая в мире Z. Вопросы построения физических структур (иерархий и индексов) и логических структур (логических иерархий, в том числе и результат объединения множества физических, в том числе и индексов) лежит на нём. Прикладной программист должен знать имя необходимого ему PCB, то есть таблицы/вью в рсубд.

Да, кстати, с интересом обнаружил, что ещё в далёкие 80е был реализован Data Sharing на принципах, на которых сейчас построен oracle rac. То есть на каждой ноде существует программная сущноность, которая взаимодействует с такими же сущностями на других нодах по принципу каждый к каждому, и решает вопросы блокировок и когерентности кэшей. И ещё тогда была уяснена принципиальная бесперспективность такого подхода, и этот функционал вывели с каждой ноды в отдельную. сущность - CF, Coupling Facility. Так IBM пришёл, видимо, к Sysplex. Эта фича IMS до сих пор доступна, но не рекомендуется к использованию - никаких преимуществ по сравнению с Sysplex она не даёт. Правда, сначала CF была чисто аппаратным решением, отдельно стоящим ящиком. Теперь это ICF - Integrated CF, отдельный LPAR в Z. Хотя, насчёт всегда так или нет, я не уверен.

Да, ещё партиционирование баз там есть.
И Хранимые Процедуры на Стероидах, IMS TM, составная часть IMS. Каждый вызов - каждая процедура - выполняется в своём отдельном адресном пространстве z/OS, то есть, по сути, в аналоге отдельной VMWare машины. Особо это финансовые всякие организации уважают и пользуют - из-за уровня изоляции процедур между собой и производительности.

только прошу учесть, что такая ситуация, как с рсубд - промониторили -> медленно -> изучили Explain -> построили индекс, этакая цикличность разработки - в IMS отсутсвует как класс.
Там структуры строятся под запросы
да это и назвать написанием запросов нельзя, четыре штуки операции, чего там писать.
То есть в РСУБД принцип - запрос оптимизируем оптимизатором под существующую структуру, и по-любому данные вернём, медленнее или быстрее.
В IMS другой принцип - структуру оптимизируем под запросы, и запрос просто не сможет выполнится если нет соответсвующей ему структуры.
То есть, если надо вернуть список людей сортированный по именам, а не по фамилиям, а физическая иерархия имеет ключ по фамилии - то один выход у прикладного программиста вытягивать все данные и сортировать самому.
Само собой, нету кучи SQLьных ништяков, группировок, агрегатных функций, да по сути дела - нифига нет.
По принципу - не дело базы данных фигнёй заниматься, её дело платежи проводить, но быстро и надёжно.
Но учитывая под что её используют - OLTP и в основном в учёте финансов, хоть и не только - этот принцип, как ни странно, оказывается востребованным. Если всё одно весь функционал SQL в его богатстве использоваться не будет, а тот функционал, что есть в IMS будет использоваться на 100% и с офигительной скоростью - пишут, что 44000 транзакции в секунду на отдельно стоящей установке (в смысле не в IMSPlex) - то зачем?
Кстати, JDBC драйвер к ней есть.
Как и XQuery/Xpath - ну это и не удивительно, прикрутить это к иерархии было проще, чем к DB2, как мне кажется.

Dimitry Sibiryakov
То есть это FVMas, только от IBM.

При чём тут FVMas я не знаю, но только DB2 на z/OS тоже без системного программиста не живёт, как и всё остальное в z/OS.
Не, ну может быть ситуация, когда всё поставили, сконфигурили, и не трогают, только пользователи свои АРМ гоняют.
Тогда системный программист не нужен.
До поры до времени.

как пример такой фигни - воплотили КЛАДР в IMS.
Очень интересно получилось.
Два сегмента, один пустой, в нём только указатели-ссылки, служит для указания подчинённости, то есть root, второй - собственно запись КЛАДР со всеми его полями, и указателем на первый сегмент.
То есть первый является физическим родителем второго, а второй - логическим родителем первого.
Логическая структура при этом разворачивается в четырёхуровневую структуру КЛАДР (уровень домов/квартир мы не брали, но ничто не мешает и их подгрузить).
Очень компактненько, легко извлекать данные, никаких рекурсивных запросов - рекурсия уже в структуре данных ссылками-указателями выполнена, кто кому принадлежит.

kdvта же фигня, что и Cache (MUMPS, ДИАМС).
Вот на что это точно не похоже никаким боком - так это на Cashe - просто ничего общего :)

Yo.!
честно говоря я тоже ничего принципиально нового не услышал. только не значительные нюансы относительно каши. основное преимущество RDBMS именно в оптимизаторе, т.е. у меня данные могут расти, но мне не нужен системный программист изменяющий структуру изменяя ее с ростом данных и перелопачивающий все ПО под изменяющуюся структуру. у меня есть оптимизатор, который с ростом данных сам изменит планы запросов в зависимости от накопленной статистики. второе преимущество оторванность ПО от структуры данных. если у меня выросли объемы, я как дба имею сотни вариантов от вбюшек и партитионинга до кластера переколбасить внутреннюю структуру не трогая ПО.
Вот-вот, ещё одно заблуждение.
Не надо перелопачивать структуру с "ростом данных".
И оптимизатор не нужен.
Ведь не надо проводить операцию JOIN и выбирать алгоритм соединения таблиц - nested loop, merge, hash join.
Каждый сегмент имеет прямой указатель на связанный с ним.
И доступ только по сегментам. А не по множествам.
То есть, получили нужный сегмент. Уже в префиксе сегмента, недоступному прикладной программе, есть указатели на все связанные с ним сегменты. Ничего оптимизировать не надо - следующим вызовом вернётся следующий запрошенный сегмент.
Так что - оптимизатор не нужен, и "переколбасивать" внутреннюю структуру тоже не нужно - другого способа перейти от сегмента к сегменту всё равно не появится :)
Кстати, я уже заметил, именно этот момент очень трудно доходит :)
Один коллега никак не мог понять - так ведь программист не знает статистику по распределению данных, это же только оптимизатор знает!
Большая трудность пояснить ему - нету статистики распределения, и не надо её знать, дабы получить данные по человеку - ФИО к примеру, и его все почтовые адреса. Потому как сегмент ФИО содержит, к примеру, указатель на первый почтовый адрес, тот на второй, второй на трет Еий- пока не закончатся адреса.
Вопрос - нафейхоа тут оптимизатор?
Вся программа прикладная состоит из одних аналогов SQL FETCH.
Получить первый сегмент ФИО удовлетворяющий условиям поиска (Фамилия начинается на букву, к примеру)
Получить первый дочерний.
Полчить следующий дочерний.
Получить следующий дочерний - уупс, закончились
Получить следующий сегмент ФИО удовлетворяющий условиям.

немного отличается от табличной формы - дубликаты ФИО на клиента не отправляются, операция JOIN, к примеру по nested loop не выполняется.

кстати, про кластера - IMSPlex и никакого переписывания приложений.
А сколько компаний предлагают недешёвый консалтинг по выяснению, насколько приложение RAC ready?
Дофига.
А потом, за отдельные деньги совсем другого масштаба, доведение приложений до работоспособности в RAC

Siemargl,

какой процедурки? реализацию КЛАДР?
Так это DBDGEN и PCBGEN

а так - да, между IMS и Cashe ничего общего, кроме нелепого слова "иерархия", которая ровным счётом ничего не поясняет.

пока не сплю и есть время.
IMS это первая система реализовавшая парадигму отделения языка доступа к данным от языка кодирования логики.
То есть DL/I - язык доступа к данным IMS - является предтечей SQL, и играет ту же роль.
Не важно, на каком языке кодят кодеры - доступ к данным по DL/I
Вызовы DL/I по смыслу похожы на вызовы ldap - ldapsearch, ldapadd, ldapmodify, etc.
И логика работы немного похоже.
И на с SQL похоже, на как-бы расширенный Fetch из курсора. А курсор создавать не надо - он создан при создании логической структуры данных, она данных и есть курсор, оптимизатор просто не нужен.
Не, я понимаю, что без малого 100% нынешних читателей с IMS никогда не столкнутся, но ведь есть простой человеческий интерес - а как оно у вас там устроено?
Тем более, что не самая хреновая платформа, и построены на ней не самые хреновые системы.

Yo.!не, все равно до меня не дошло. давай возьмем более живой пример, а то с абстрактным мышлением у меня туго.
у нас есть абонент и долг, сначала мы думали, что у абонентов будет много долгов, поэтому выстроили иерархию абонент->долг и сделали отчет который идет по номеру абонента и вычисляет сумму долга. кризис прошел и теперь такой подход не оптимален, т.к. подавляющее большинство абонентов без долгов. теперь оптимальней идти по долгам, но структура то у нас уже определена и как я понимаю без серьезной переработки ПО и может структуры иерархии уже не обойтись.
Вот, вот здесь у меня трудности восприятия начинаются :)
Во-первых, IMS и отчёты - не то, что невозможно, есть даже специальный метод доступа , более подходящий для отчётов, но это не совсем отчётная система в том смысле, что ad-hoc запросы невозможны - только предопределённые.
Теперь к примеру.
Что такое абонент - более/менее понятно. Что такое долг - уже непонятно. У абонента может быть счёт. У счёта могут быть транзакции - проводки. Проводки могут быть по дебиту и по кредиту. Я ничего не попутал?
У счёта есть баланс.
И?
Если есть необходимость идти от абонентов в большинстве случаев - root сегмент будет абонент.
Если в части случаев надо заходить в иерархию по номеру счёта - нифига менять не надо, при вызове GU указывает тип сегмента - счёт (номер=123456) и после завершения вызова в памяти программы первый искомый сегмент, удовлетворяющий условиям, в данном случае он же единственный.
Если надо выяснить баланс - читается из сегмента счёта.
Если надо получить транзакции по счёту - проводки - выполняется вызов GNP в цикле пока не закончатся транзакции этого счёта.
Если, к примеру, надо получать список транзакций за определённую дату по всем счетам, то надо строить индекс по полю даты в сегменте транзакций, тогда варианты те, которые я уже указывал ранее.
Так что не всё, так хреново, как оно кажется, на основе мифов и преданий форума sql.ru
Но и с RDBMS сравнивать нельзя. Это в RDBMS любой пользователь, наделённый правами, может сгондобить любой запрос к любой структуре, и оптимизатор покряхтит, удивится, но данные вернёт, если запрос валидный.
Может не быстро - но вернёт.
Другой вопрос, что если вы коммерческая компания, типа Федуча в германии, поставляющая сервис платёжных систем 650 коммерческим банкам.... То за попытку послать в базу "левый" запрос.... И кастрировать могут.
Где это видано - на живой платёжной системе не разрешёные безопасностью и прочими запросы посылать?
Здесь можно такую аналогию - в RDBMS можно быстренько сгавнякать прототип, даже сдать его в опытно-промышленную эксплуатацию, с последующим "переколбасиванием" базы администратором в виду хреновой производительности, и так в цикле.
В IMS быстренько сгавнякать вряд ли получится. Но то, что получится, хреначить будет так, что аж шуба будет заворачиваться. В пределах поставленных условий.
Кстати, по поводу изменения структуры.
Вы в принципе в курсе, что стоит заменить структуру данных РСУБД в банковской системе?
И что время на собственно изменение структуры будет исчезающе мало на фоне согласований с безопастниками, тестированием, и сдачей в эксплуатацию, это даже если без изменения приложений.
То есть вы чего-то там замените на своей разработчицкой системе, передадите в тестовую, куда у вас нифига доступа нет, там наж вашим гениальным поделием будут форменно издеваться в извращённых формах, и только потом перенесут в промышленную систему.
А у вас что - не так?

Yo.!есть какой-то документ серьезный по IMS data sharing, все на что я натыкаюсь речь идет о шаринге между LPAR, а между машинами поверх Syplex. т.е. не увидел как он может заменить железный syplex.
это не он меняет Sysplex - это Sysplex его :)

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS3663

да, в примере абонент -> счёт при запрашивании счёта по номеру, счёт конечно получим.
Но чуда не произойдёт, и для его получения IMS просмотрит все сегменты, пока не наткнётся на нужный.
Эдакий tablescan.
То есть ещё раз внимательно принцип - структура строится под запросы.
Если есть требование выполнят доступ к счёту по номеру - то это учитывается.
К примеру, в реальной системе иерархия в вашем примере абонента (там другое название просто) отдельно от иерархии счетов. У абонента в иерархии есть сегменты Организация и Физлицо (присутсвует только один из них, само собой), адрес, и куча прочих сегментов, описывающих владельца счёта.
Иерархия счетов самостоятельная, root сегмент счёт, дочерний баланс, год, под годами платёжки в порядке последний ближе к началу. Сегмент счёт ключевой по номеру счёта.
Между сегментом абонент и сегментом счёт существует bidirectional logical reference
Доступ к счёту возможен через сегмент абонента, потом к счёту, или наоборот - к счёту по номеру, затем к абоненту.
Но все эти типы доступа к данным заданы до того, как.
Эта структура и тип связей построены на основе техзадания.
И вариант - мля, я забыл! Ща добавлю, пустите - не канает.
Насколько я в курсе, в мире, кроме РФ, тоже кризис был.
Что-то я не думаю, что City или Credit Susse меняли структуру данных из-за этого, будь то IMS, или RDBMS.

PDF-ку я кстати не читал - "рав Google" нашёл, так что если что интересное будет - расскажите, прочитаю

нет, PDF-ка про IMSplex.
Надо или ключевое слово VTAM добавлять, или мне бумажную копию отсканировать

о, один страниц архитектуры Data sharing без сисплекса

о как, по размеру не проходит.
а в png?
Если войдёт - то там нет CF