Как-то давно обсуждали иерархические базы данных.
А мне пришлось по случаю попользовать 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

фиг его знает, где в инете старую доку искать.
"N-way sharing based on the new Coupling Facility hardware is much easier
than the old software-based block-level sharing."
Это вот отсюда http://documents.bmc.com/products/documents/36/96/103696/103696.pdf
Глава 17

vadiminfo
Говорили, что это иерахическая СУБД. Вроде ее к таковым относили в литературе. А далее говорил характерное для иерархических вообще: для структурирования типы записей, их коллекции, связи по указателям, ссылкам. Язык БД навигационный.

Применительно к IMS - не совсем навигационный, пример я дал.
vadiminfo
Ну а зачем ананалог, када есть СУБД с самим SQL?
Аналоги ведь могут праздно себя являть: SQL все же ориентирован на множесвенную (не упорядоченное множество) модель. А навигация на упорядоченное множество: коллекцию.
Отказываемся от коллекции? Отказываемся от иерархической МД в IMS? Ну тада что Вы хотите сказать, что IMS типа реляционная теперь стала? Или почти реляционная? Или и реляционная и иерархическая? Или сосбно что?
С одной стороны, ну, больше на одну РСУБД стало: у IBM уже две РСУБД есть, ну буит третья до кучи.
Но с другой стороны, нужно подтверждение, потому что IMS все же традиционный пример Иерархической СУБД дожившей до наших дней. Он типа их флагман был. А теперь он перебежал получается?
Нет, IMS не как бы реляционная.
И DL/I не SQL.
Просто анектод про "селект слон фром африка" - не про IMS.
в DL/I не указывается порядок извлечения данных.
Как бы это странно не казалось.
А SQL и оптимизатор IMS не нужен.
При всём при том, что всё-таки декларируется - какие данные надо вернуть.
В прямом смысле слова - указывается Segment Search Argument, который и есть аналог WHERE
Так понятнее?

Yo.!ппмда, в примере абонент -> счёт при запрашивании счёта по номеру, счёт конечно получим.
Но чуда не произойдёт, и для его получения IMS просмотрит все сегменты, пока не наткнётся на нужный.
Эдакий tablescan.
То есть ещё раз внимательно принцип - структура строится под запросы.

ну да, значит ничего принципиально не изменилось с лохматых годов. т.е. вы зашиваете в ПО как нужно доставать данные, а я зашиваю какие мне нужны данные. собственно поэтому каши и иерархические вымерли.
мое имхо единственная рулизная вещь у такой фигулины (и потому она гораздо интересней каши) это географически распределенный sysplex. вот вместе с sysplex действительно можно делать то, что нельзя на других субд/платформах с той же эффективностью. а так это такой асемблер для субд, где руками нужно прописывать методы доступа к данным, что может быть иногда оправдано, но в очень специфических случаях.
про дата шаринг почитаю на досуге, доложусь.
Понято с точностью до наоборот.
Интересно, на основе каких рассуждений сделан вывод о "зашиваете в ПО как нужно доставать данные" если я утверждал абсолютно обратное?
Ещё раз - в данном примере произойдёт аналог табличного скана, вполне самостоятельно, БЕЗ участия клиентского приложения, на стороне IMS, клиент получит свой сегмент.
Но чуда не бдет - будет перебор.
Как и в реляционке.
Нужен индексный доступ?
О чудо!
Надо строить индекс.
Как и в реляционке.
Да, как за много-много лет ДО IMS делалось на VSAM - KSDS.
Индексный доступ обеспечивается индексом.
Если нет индекса - РСУБД вернёт данные, приложение не знает об индексе, если не берём хинты.
Если нет индекса в данном примере - IMS вернёт данные, приложение не знает об индексе.
Так понятнее?
действительно, ничего не изменилось с лохматых годов - это основа IMS, так было всегда.
Не надо руками прописыватьт методы доступа - я с первого поста пытаюсь это пояснить .
Я понимаю, в это поверить невозможно, это противоречит мировозрению.
Но это так.
Документация доступна - читайте.
И это оказалось оправдано в 80% крупнейших финансовых институтов мира.
Но это как раз к "навигации" отношения не имеет.
Кстати, я ведь в примере про Fetch и пример навигации приводил - вызов GNP это как раз и есть навигация.
Сперва чисто декларативно затребовали клиента по фамилии Иванов, получили. Далее чито навигационно требуем его первый дочерний сегмент - и в этом нет криминала, потому что он первый, и потому что он дочерний, и IMS точно знает, где он лежит - у IMS в этот момент есть его точный адрес.
напукруа тут что-то другое?
Вы бы не начинали сразу оценивать, вы бы для начала попробовали понять, что ли :)
Вас никто не призывает мигрировать, более того, я могу утверждать, что вам и не повезёт попробовать IMS, на этом недо-рынке, где один не самый крупный шцейцарский банк кроет всё Россию со всеми финансовыми институтами как бык овцу - в таких условиях IMS вам никто не даст.
Так вы хоть спрашивайте, пока есть возможность и доступ к системе, вед можно и тестики прогнать, и примерчики.
То, что это устарело - я знаю, мне один "архитектор" страницу в инете показал, гдле по русски написано - представляет чисто академический интерес :) Ага, для России - в точку!
Так вот вы с академического интереса и подходите.
Можно вот КЛАДР структурку глянуть, запросики к ней создать.
Кстати, в IMS есть аналог SPUFI, так что программировать не надо, чтобы запрос выполнить.
Правда, он зело чудной, и вы матюкаться долго будете - параметры позиционные :)
Сказано в доке - операнд в десятой колонке, и никаких одинадцатых :)
Что есть - то есть :)
Но не в этом суть продукта.
Но в принципе, если вам ужо так всё понятно - то я таки настаивать не буду :)
Только сами подумайте с чего бы это китаёзы не оракл для национальной платёжной системы выбрали?
И даже не DB2.
Дураки потому что.

вы уж простите мне мою безграмотность - но что такое RDF, потому что гугл отсылает к http://www.w3.org/RDF/
А кэш я не затрагиваю по ряду причин.
Основная - IMS используется для OLTP, которому характерен случайный метод доступа к данным, к малым порциям данных. В этом случае кэш мало помагает, а вот сильный ввод-вывод - сильно помогает.
Есть фича, когда запрос, зная, какой будет следующий сегмент, запрашивает сразу два сегмента, родитель-потомок, есть фича OSAM, вместо VSAM, который не только организация данных, но и другая канальная программа, которая "распознаёт" тип доступа - случайный или последовательный, и в случае последовательного применяет упреждающее чтение.
Так что кэш - не самое.
Самое - много путей доступа к устройствам ввода-вывода.
в z9 их было 1024, если мне склероз не изменяет, или это уже в z10 - канала - это как 1024 шины применительно к другой платформе, хотя канал это не только путь доступа, но для простоты пусть будет так.

без сильного ввода-вывода организовать доступ параллельно к хотя бы 30000 разных сегментов одновременно в одну секунду будет затруднительно, а отдельно стоящая IMS выдала 44000 транзакций в секунду, транзакциями называется процедура IMS TM, то есть аналог хранимки.
Ясный пень, что процедура процедуре рознь, но пусть каждая из них затрагивала всего один сегмент.

iv_an_ruппмвы уж простите мне мою безграмотность - но что такое RDF, потому что гугл отсылает к http://www.w3.org/RDF/
Правильно отсылает.
ну на досуге посмотрю.
хотя, судя по некоторым признакам....
ему ещё долго щёки надувать, чтобы IMS уделать.

iv_an_ru
То есть у вас активное подмножество намного больше доступной ОЗУхи, я правильно понимаю? В таком случае интересно было бы узнать цену железок и какие-то циферки по размерам базы. А то вдруг выяснится, что кластер из 100 машинок по $5000 каждая и по цене сравним, и 100*10=1000 независимых винтов позволяют делать вполне недурственные цифры в т.ч. и на OLTP?

э, хоть один референс кластера OLTP на 100 машинках банковской платёжной системы?
Но вы не поверите - IMS может обойтись дешевле той же DB2 на сравнимой задаче - ресурсов меньше жрёт значительно, а в Z плата идёт за ресурс.
Кстати, почему-то практически в 100% там, где стоит IMS, стоит и DB2.
Неожиданно, правда?
Дураки какие-то, разные инструменты для разных задач используют...
То ли дело мы, одной кувалдой везде...
Там есть ещё занятные цифры по сравнению совместно используемого софта, но уже не в базах данных.

Yo.!
нет, я чуть усложню пример и вам будет не выкрутиться. сейчас лень придумывать какую-то прикладную область но суть такая: две таблицы, одна была больше, другая меньше. пока такая пропорция выгодно идти по второй, обратывая первую. если со временем первая стала, меньше чем вторая то IMS уже не перестроит схему доступа. завтра придумаю привязку к какой-нибудь предметной области
Вот-вот - типичные слова человека от сохи, то есть от реляционной базы!
Это оптимизатору выгодно!
Я дополню вашу задачу - надо вернуть ОДНУ запись из первой таблицы, и затем ОДНУ запись из второй, которая соответсвует первой, затем ОДНУ следующую из второй, соответсвующую первой.
И как бы оптимизатор ни пыжился, как бы не менял порядок таблиц, какой бы алгоритм не выбирал - я ведь вам писал про nested loop join - один хер в структуре IMS, где первая запись из первой таблицы содержит АДРЕС! связанной записи из второй, а та содержит адрес на следующую... Не получится, короче, у оптимизатора.
А порядок возврата сегментов определяет не количество записей, а бизнес-потребности, требования.

Yo.!
а вот это интересно. если IMS на z/OS было бы прикольно налабать какой-нить пример и прогнать сравнить z9 с писюком.
ну практически это и происходит.
только вот какая штука....
Чтобы Z получился выгоднее, или задача должна быть очень здоровая.
Или задач должно быть очень много.
А лучше всё вместе.
Тут даже не по деньгам сравнение.
по аппаратно-программному устройству писюка и Z.
z9 совсем не числогрыз, это последний z196 имеет 5 с лихуем гигагерц.

iv_an_ru
Сразу усугубим. Три таблицы, ROUTE (базовые сборочные последовательности), SP_OUT (отгрузки запчастей на другие заводы), SP_IN (приход запчастей с других заводов).

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

SELECT * from ROUTE r, SP_OUT o, SP_IN i
WHERE
o.R_ID = r.BEGIN_ID and i.ORIG_ID = o.DEST_ID and r.END_ID = i.R_ID

Таблицы связаны в треугольник тремя "равноправными" равенствами, возможны шесть способов перебора.
то есть историю возникновения IMS вы не глянули.
Она была создана под проект Союз-Апполон, и как раз под учёт сборочных узлов, деталей, и прочих механических припамбасов. К тому же рекурсии решаются просто.
Если хотите примерчик сделать - вы уж опишите, что за сущности имеем, как они взаимосвязаны, а то я не понял, что за базовая сборочная последовательность. Можно в терминах create table.
Только возвращатся при каждом вызове будет ОДНА сущность, для возврата всех придётся в цикле повторять - про аналог Fetch я уже писал, лень повторятся.
Вот из вашего запроса база тоже курсор сделает, из которого программа Fetch записи.

vadiminfo
Про то что я спросил не понятнее. Вы просто более детально подтвердили то, что я утверждал, т.е и так знал.
Ясно дело, что все производители наровят вставить деклпаративный язык. Но он может себя праздно являть. Вот Вы подверили, что порядолк не нужен. Т.е. не нужно иерархическое, а реляционого нет. Вот теперь возникает вопрос что за МД она поддерживает.
Так понятнее про вопрос?
то есть вы уже знаете, что такое IMS, и я только подтверждаю ваши знания?
Ну ладно.
Вы не поверите, но нигде в доке я ни разу не встречал упоминание о том, что за модель данных поддерживает IMS. такое впечатление, что им положить на чаяния наших базовиков.
Данные располагаются в сегментах, минимально обрабатываемой порции. Сегмент имеет служебную часть - префикс, недоступную программно. В префиксе находятся разные типы указателей. Указатели указвают на другой сегмент.
Указатель может быть не сегмент из другой иерархии - logical reference.
Сегменты расположены в иерархическом порядке, где один всегда root сегмент.
Но используя logical reference и secondary indexes рутовым сегментом можно сделать любой. Только он уже будет не физический родитель, а логический родитель.
Так, кстати, структура КЛАДР получилась, два сегмента, один рут, второй его потомок, но у потомка указатель на рут, и потомок выступает логическим родителем сегмента рут. Рекурсия то есть.
Это какая модель данных?
Мне лично - по барабану.
Вы себе как-то её обзовите.
Всё равно исходить надо из возможностей инструмента, а не подгонять его в ярлыковые рамки.
Вот к примеру программа запустилась, надо обращатся к базе за данными.
GU COURSE (COURBO = A1114)
STUDENT (LNAME= ИВАНОВ)
По выполнении этого в памяти программы будет сегмент типа STUDENT у котрого поле LNAME равно ИВАНОВ, при чём этот сегмент является дочерним сегментом сегмента COURSE, у которого поле COURNO равно A1114.
Вот это что? Навигация? Декларация?
По большому счёту по барабану, как это называется, это берёт абсолютно осознанное количество операций ввода-вывода, абсолютно осознанное количество процессорного времени, то есть абсолютно предсказуемо, за какой промежуток времени программа получит в память исходное.
При чём этот промежуток времени не зависит от количества записей.
Почему не зависит - гляньте описание HDAM и PHDAM. Только читать много, и материал не простой - они, гады, до байта всё разложили, что где лежит.

iv_an_ru
Да я поверю --- если старая система ещё жива, значит у неё есть какое-то толстое уникальное преимущество. Просто хотелось бы простую цифирь: цена железки, размер базы в гигах и строках, число транзакций. Чтоб поконкретнее поверить.
Старая???
Последняя версия вышла в этом году, следующая на подходе - чаще, однако, чем DB2, как мне кажется. Не старая - зрелая :)
Ну референсов вы на сайте IBM и сами надыбаете, как мне кажется, там и по размерам, и прочим делам,только по поводу цены не обольщайтесь. Такого понятия как прайс лист в мире Z можно сказать нету - цена считается под конкретный аппарат конкретного заказчика. Поэтому цен вы точно не узнаете.
Но главный принцип - платится за выполненную работу. Может быть организованно в прямом смысле слова - по сети отсылаются отчёты сколько времени потрачено каким софтом, и на основании этого выставляется платёж. То есть выключили на ночь сервер - нифига не платите.
Да, если захотите, и проявите намерения, то вас могут свозить, к примеру, в Credit Susse, на посмотреть.
Только как я уже говорил, россиян это практически не касается - н зачем в России такой софт?
Какие задачи решть?
Ни одна финансово-учётная система из разработанных под IMS не может провести проводку задним числом с пересчётом остатков. Более того, они считаю, что это криминал. Ну тупые...

iv_an_ru,

хорошо, попробую, но быстро не обещаю, и наводящие вопросы могут быть.
Только вот про ссылки-указатели вы так и не вчитались.
IMS не работает с множествами, в принципе, и даже не перемножает их.
Но если запись об объекте ROUTE имеет связаную запись объекта SP_OUT - то в первом будет прямой указатель на адрес последнего.
То есть на выходе в IMS будет процедурка, которая позволяет перебрать сегменты, у которых в поле DWG значение 1234
Но давайте тогда попробуем этот пример, чем разбирать - что такое есть за модель данных в IMS. Если нет возражений у остальных читателей.
всё больше интересно. Я просто сейчас убегаю, ближе к ночи займусь.

iv_an_ruДык одно другому не противоречит. Винда --- новая операционка? Нет, старая. Последняя версия свежая? Да. Значит винда "старая"+"живая" = "зрелая" а не "старая" и "дохлая", как какая-нибудь CP/M :)[/quot]
Э, пардон, но винда новая операционка :)
Не дохлая :)
Но и не зрелая - Балмер сказал, что-то типа, есть ещё что улучшать :)
В MVS по-моему, уже нечего :)
Хотя, нет, чего-то там изменили в z/OS V11, кстати, глянуть бы чего...
Но "старость" к делу не относится, согласен.

MasterZiv,
пардоньте, но именно это я и писал выше.
Сами посмотрите, или носом ткнуть?
Да, структура делается под запросы.
Точка.
Если это не то, что надо - IMS использоватся не будет.
То есть огромная область BI, и прочей аналитики - просто не для IMS.
Я так мисал - в 100% случаев с IMS стоит DB2.
ну дуракие, нет?
Ну тупые они, тупые.
Так что всё нормально - IMS отстой, RDBMS - кувалда.
всё, пример уже не надо делать?
то есть, уже не интересно?
Или может понос закончим, научимся читать, а не только писать?
И попробуем выполнить пример, эту псевдо-задачу разными средствами.