Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
 Re: IMS  [new]
ппм
Guest
iv_an_ru
Дык одно другому не противоречит. Винда --- новая операционка? Нет, старая. Последняя версия свежая? Да. Значит винда "старая"+"живая" = "зрелая" а не "старая" и "дохлая", как какая-нибудь CP/M :)[/quot]
Э, пардон, но винда новая операционка :)
Не дохлая :)
Но и не зрелая - Балмер сказал, что-то типа, есть ещё что улучшать :)
В MVS по-моему, уже нечего :)
Хотя, нет, чего-то там изменили в z/OS V11, кстати, глянуть бы чего...
Но "старость" к делу не относится, согласен.
13 окт 10, 09:29    [9597606]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 12.10.2010 15:24, ппм wrote:

> Как-то давно обсуждали иерархические базы данных.
> А мне пришлось по случаю попользовать IBM IMS.
> Что там говорили? Типа, необходимость программировать обход деревьев вручную,
> необходимость синхронизации деревьев между собой вручную, негибкость в смысле
> трудностей изменения структуры.
> Вот эти три утверждения - это из разряда мифов, если применительно к IMS.

"Однако, за время пути
Собачка могла подрасти ..."

Не думал, что IBM-еры могли уже "подтянуть" функционал своей СУБД к реляционным,
ослабив требования сетевой строгости и добавив возможности выполнения
декларативных запросов ?

К тому же главная проблема сетевых/иерархических СУБД не в том, что ты
перечислил, а в том, что все возможные запросы вшиваются в структуру
данных. Запрос, для которого нет пути в сети данных, просто не сможет
выполниться.
На реляционных СУБД, напротив, можно выполнять абсолютно любой
запрос.

А что у сетевых есть свои вкусности -- это и понятно, и известно.

Posted via ActualForum NNTP Server 1.4

13 окт 10, 09:41    [9597717]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
ппм
Guest
MasterZiv,
пардоньте, но именно это я и писал выше.
Сами посмотрите, или носом ткнуть?
Да, структура делается под запросы.
Точка.
Если это не то, что надо - IMS использоватся не будет.
То есть огромная область BI, и прочей аналитики - просто не для IMS.
Я так мисал - в 100% случаев с IMS стоит DB2.
ну дуракие, нет?
Ну тупые они, тупые.
Так что всё нормально - IMS отстой, RDBMS - кувалда.
всё, пример уже не надо делать?
то есть, уже не интересно?
Или может понос закончим, научимся читать, а не только писать?
И попробуем выполнить пример, эту псевдо-задачу разными средствами.
13 окт 10, 09:49    [9597795]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6637
ппм,

Даешь пример на задачу ив_ан_, я же пример давно просил=)
One picture worth thousand of words.
У меня ссылочка на доку ИМС в закладочках полгода висит, да все мрачно начать много читать из праздного интереса.

Непонятно, что значит сегмент по отношению к данным - одна запись структуры данных, 100 или как?
13 окт 10, 10:09    [9597920]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
sdvsamara
Member

Откуда: Самара
Сообщений: 201
ппм

Вот к примеру программа запустилась, надо обращатся к базе за данными.
GU COURSE (COURBO = A1114)
STUDENT (LNAME= ИВАНОВ)
По выполнении этого в памяти программы будет сегмент типа STUDENT у котрого поле LNAME равно ИВАНОВ, при чём этот сегмент является дочерним сегментом сегмента COURSE, у которого поле COURNO равно A1114.
Вот это что? Навигация? Декларация?


Навигация чистейшей воды.
13 окт 10, 10:13    [9597949]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6637
MasterZiv
К тому же главная проблема сетевых/иерархических СУБД не в том, что ты
перечислил, а в том, что все возможные запросы вшиваются в структуру
данных. Запрос, для которого нет пути в сети данных, просто не сможет
выполниться.
На реляционных СУБД, напротив, можно выполнять абсолютно любой
запрос.

Это не грандиозная проблема. Данные вполне однозначно определяют взаимоотношения между сущностями, которые при реляционном разложении тупо теряются.

Да на РДБМС оптимизатор усилием телепатической мысли пытается воссоздать выброшенные взаимоотношения из запроса (еще и оптимальным образом переразложить), но:
-телепатия хорошо работает не всегда
-то, что можно строить абсолютно любые,в т.ч.бессмысленные запросы, для приложений дает мало
-все равно приходится вместо прямых взаимосвязей писать подсказки - индексы, форин-кеи, хинты


ТС, можно прямую ссылочку на доку по DL/I?
13 окт 10, 10:16    [9597982]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6637
sdvsamara
ппм

Вот к примеру программа запустилась, надо обращатся к базе за данными.
GU COURSE (COURBO = A1114)
STUDENT (LNAME= ИВАНОВ)
По выполнении этого в памяти программы будет сегмент типа STUDENT у котрого поле LNAME равно ИВАНОВ, при чём этот сегмент является дочерним сегментом сегмента COURSE, у которого поле COURNO равно A1114.
Вот это что? Навигация? Декларация?


Навигация чистейшей воды.

Непонятно, слишком простой пример, хотя похоже.
Уточним - а если на курсе А1114 будет пять разных ИВАНОВых - как их пролучить в программе ?
13 окт 10, 10:19    [9598002]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ппм
то есть вы уже знаете, что такое IMS, и я только подтверждаю ваши знания?
Ну ладно.

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

ппм

Вы не поверите, но нигде в доке я ни разу не встречал упоминание о том, что за модель данных
поддерживает IMS. такое впечатление, что им положить на чаяния наших базовиков.

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

ппм

Данные располагаются в сегментах, минимально обрабатываемой порции. Сегмент имеет служебную часть - префикс, недоступную программно. В префиксе находятся разные типы указателей. Указатели указвают на другой сегмент.
Указатель может быть не сегмент из другой иерархии - logical reference.
Сегменты расположены в иерархическом порядке, где один всегда root сегмент.
Но используя logical reference и secondary indexes рутовым сегментом можно сделать любой. Только он уже будет не физический родитель, а логический родитель.
Так, кстати, структура КЛАДР получилась, два сегмента, один рут, второй его потомок, но у потомка указатель на рут, и потомок выступает логическим родителем сегмента рут. Рекурсия то есть.
Это какая модель данных?

Ну скорее всего иерархическая. Тада все декларативное без дополнительных сведений выглядит как дополнительное что-то. Ну в ООМД тпам тоже типа есть декларативный ODL, но это типа не основное. Главное, возможно, императивное и навигационное.

ппм

Мне лично - по барабану.
Вы себе как-то её обзовите.

Это Вы возможно погорячились. Вы, поймите, что програмирование драйверов и разработка ИС - разные весчи. Если бы речь шла о драйверах это бы прокатило. Но Вы защищаете СУБД. И можете такими высказваниями сделать ей тока хуже.

ппм

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

И здесь самое время уточнить какую(ие) МД поддерживает инструмент и как поодерживает.
Это избавит сразу от многих вопросов.

ппм

Вот к примеру программа запустилась, надо обращатся к базе за данными.
GU COURSE (COURBO = A1114)
STUDENT (LNAME= ИВАНОВ)
По выполнении этого в памяти программы будет сегмент типа STUDENT у котрого поле LNAME равно ИВАНОВ, при чём этот сегмент является дочерним сегментом сегмента COURSE, у которого поле COURNO равно A1114.
Вот это что? Навигация? Декларация?

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


ппм

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

Вы тока какда СУБД толкаете, не может расчитывать, что то на что Вам по барабану, то действительно не имеет значения. Если, конечно, речь не идет о том, чтобы запутать всех с целью сокрытия недостатков поддержания МД или отсутсвия таковых.
13 окт 10, 10:33    [9598120]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
ппм
Guest
ещё раз
1. Я не защищаю IMS. Она в моей убогой защите не нуждается. Я написал то, что написал. Иногда банан это просто банан, дочка.
2. Хотелось бы узнать, в каком месте и каким боком приведённый пример является навигацией.
3. Приведённый пример с вызовом GU никак не является чем-то дополнительным, это является основным вызовом DL/I и существует с 1968 года. Других вызовов, кроме тех, которые я уже описал - просто нет.
4. Зачем это надо? Взял РСУБД и не надо парится? Парится этим начинают когда нефункциональные требования к системе не позволяют её сделать на РСУБД, в том числе и потому, что на IMS это будет дешевле, вернее, на связке IMS+DB2. То, что такие области человеческой деятельности существуют - это факт. То, что вы в них не работаете - тоже факт. Вообще-то, архитектуру решения определяют именно нефункциональные требования.
5. Я не могу сделать IMS хуже :) Где я - и где IMS :) И как - хуже? ваша компания её не купит? Я вас уверяю - она её никогда не купит, вне зависимости от того, что я здесь напишу :) Или не напишу.
Повторю. Я не защищаю. Я не продаю. У меня есть доступ к системе. Есть кого спросить. Кому-то это может быть интересно. Чего остальные напряглись-то? Вам разве что угрожает?
6. IMS не является заменой РСУБД, и IBM её не доводит до уровня РСУБД, это было бы большой глупостью, она нужна именно такая, как есть. Кстати, уровень устойчивости у неё выше чем у DB2/Z, отказов меньше и время восстановления меньше, но производитель заявляет что всё на Z одинаково полезное :)
7. Я не толкаю СУБД и не "сокрытия недостатков поддержания МД или отсутсвия таковых" - мне по барабану, МД, не МД, сеть, не сеть. Есть структура, есть запросы к ней. Я называть это не буду. Я могу показать, какая может быть структура под такие вот запросы, и запросы. Есть недостатков? Рассмотрим. Есть достоинств? Рассмотрим.
Так понятнее?
8. Назвать IMS иерархическая - не сказать ничего. Ровным счётом. Именно поэтому я тут первый пост и запостил. Не надо было? Не интересно?
9. Если на курсе А1114 более одного сегмента с полем фамилии ИВАНОВ то вызов повторится, только уже не GU а GN, после этого вызова в памяти программы будет следующий сегмент с полем фамилии равно ИВАНОВ. И так в цикле, пока не получим статус выхода из вызова, означающий - больше сегментов нету.
10. Дока по IMS доступна в Инфоцентре онлайн, но уже с восьмой версии и старее нету. Там есть про всё, в том числе и про DL/I.

Фух, никого не обидел?
iv_an_ru - я так понял, что здесь занятся примером не получится, будут прерывать возгласами "ничего нового" и "я так и знал".
То, что ничего нового - факт, система создана в 1968 году. То, что "я так и знал" - сильно сомневаюсь, куча высказываний говорит от том, что большинство как раз ни ухом, ни рылом, а по принципу "а, иерархическая, знаем, как же", при том, что выясняется не знают. Даже как запрос выглядит не знают. И вообще ничего.
Я к чему - у меня в ходе рассуждения появляются дополнительные вопросы, потомы как инфы недостаточно, может, мы перейдём на почту, пишите, если хотите, на kindly точка ghost собачка gmail точка ком, переключимся на другой адрес, и по-работаем вечерами над примером, а результат и ход рассуждения потом сюда выложим.
Не будем мешать обществу развлекать себя, они ведь уже всё знают, у них в руках кувалда, с помощью её и какой-то матери они любую задачу враз решат. Я на несколько часов опять выпаду. Если хотите - пишите, нет - будем здесь продолжать, но я на время работы над примером буду игнорировать остальное - извините, я, в отличие от Z - не многозадачный :( Да мне больше и сказать то нечего. Все ведь всё знают :)
13 окт 10, 12:15    [9599011]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
ппм,
Если пример вызывает проблемы, то не надо в него капитально зарываться, так как он и должен вызывать проблемы. Все ориентированные на OLTP системы плохо приспособлены к циклическим зависимостям на переменных, а если усугублять неравномерностями статистик внутри таблиц, то и многие реляционные СУБД пролетают мимо правильного плана.
В IMS вполне могут быть функции для быстрого получения статистик из хранимок, тогда в хранимке можно написать кучку if-ов, чтобы на основании этих статистик выполнить одну из веток. Просто интересно, делают так на приктике или нет.
Ну и по-прежнему интересны цифирки.
13 окт 10, 13:10    [9599599]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ппм
ещё раз
1. Я не защищаю IMS. Она в моей убогой защите не нуждается. Я написал то, что написал. Иногда банан это просто банан, дочка.

Вы на нее наезжаете? А вроде выглядело расхваливаеие, развенчание неких мифов.
Про бананы, скорее всего, луче в какщм-то биологическом форуме.

ппм

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

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

ппм

3. Приведённый пример с вызовом GU никак не является чем-то дополнительным, это является основным вызовом DL/I и существует с 1968 года. Других вызовов, кроме тех, которые я уже описал - просто нет.

Т.е. никада по ссылкам в циклах ходить не надо? И упорядоченность не нужда? Значет МД множественная? Без этого языка DL/I там ниче нельзя получить?

ппм

4. Зачем это надо? Взял РСУБД и не надо парится? Парится этим начинают когда нефункциональные требования к системе не позволяют её сделать на РСУБД, в том числе и потому, что на IMS это будет дешевле, вернее, на связке IMS+DB2. То, что такие области человеческой деятельности существуют - это факт. То, что вы в них не работаете - тоже факт.

Т.е. можно было решить все функциональное с DB2, но тока из-за нефункциональны понадобился
IMS? Ну что же? Вы, действительно, его не защитщаете. Наоборот. Однако, даже я все же вынужден признать, что он все же занимает более достойное место среди СУБД.

ппм

Вообще-то, архитектуру решения определяют именно нефункциональные требования.

архитектуру решения? Однако, все же функциональные требования нуждаются в решении полюбасу. И в этом все дело. На этапе логического проектирования имеет значение типа СУБД: иерахическая, реляционная объекто-ориентированная и т.д.
Т.е. какую она поддерживает МД имеет значение.


ппм

5. Я не могу сделать IMS хуже :) Где я - и где IMS :) И как - хуже? ваша компания её не купит? Я вас уверяю - она её никогда не купит, вне зависимости от того, что я здесь напишу :) Или не напишу.

Это правда. Но классификация имеет значение. Вы сделали утверждения меняющие привычные представления для меня. Это и привлекло мое внимание.

ппм

Повторю. Я не защищаю. Я не продаю. У меня есть доступ к системе. Есть кого спросить. Кому-то это может быть интересно. Чего остальные напряглись-то? Вам разве что угрожает?

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

ппм

6. IMS не является заменой РСУБД, и IBM её не доводит до уровня РСУБД, это было бы большой глупостью, она нужна именно такая, как есть. Кстати, уровень устойчивости у неё выше чем у DB2/Z, отказов меньше и время восстановления меньше, но производитель заявляет что всё на Z одинаково полезное :)

Ну вот тут то и непонятки. Возможно, она нужна как иерархическая? Раз ее в больших книжках к таковым относят. Но не знау. Вот и пытаюсь понять.


ппм

7. Я не толкаю СУБД и не "сокрытия недостатков поддержания МД или отсутсвия таковых" - мне по барабану, МД, не МД, сеть, не сеть. Есть структура, есть запросы к ней. Я называть это не буду. Я могу показать, какая может быть структура под такие вот запросы, и запросы. Есть недостатков? Рассмотрим. Есть достоинств? Рассмотрим.
Так понятнее?

Нет конечно. Откуда понятнее то? Если про обычную прогу для драйверов, то да. А для СУБД не понятно в чем идея отказа от фундаментального в БД - МД.
Мы же не дикари.


ппм

8. Назвать IMS иерархическая - не сказать ничего. Ровным счётом. Именно поэтому я тут первый пост и запостил. Не надо было? Не интересно?

Назвать IMS иерархическая - это сказать главнейшее про нее. Это значительно больше, чем мы тут понаговорили. Все остальное вторично, тем более нефункциональные требования.
Возможно, интересным оказалось не то, на что Вы расчитывали.
Если бы не громкое название, после того, что Вы про нее сказали, на нее можно было бы забить раз и на всегда. Потому сомнения.
13 окт 10, 13:20    [9599715]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
MX-9
Member

Откуда: LIBAVA
Сообщений: 531
ппм
kdv
та же фигня, что и Cache (MUMPS, ДИАМС).

Вот на что это точно не похоже никаким боком - так это на Cashe - просто ничего общего :)


очень похоже на CACHE

принцип работы CACHE расписан здесь
http://www.mgateway.com/docs/universalNoSQL.pdf

почти бесплатный аналог CACHE здесь
http://www.minimdb.com
13 окт 10, 13:25    [9599753]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 13.10.2010 10:49, ппм wrote:

> Ну тупые они, тупые.
> Так что всё нормально - IMS отстой, RDBMS - кувалда.

Я такого не говорил, кажется.

Posted via ActualForum NNTP Server 1.4

13 окт 10, 13:29    [9599788]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
IgorK
Member

Откуда: Краснодар
Сообщений: 452
Судя по описанию ТС программирование (получение данных) очень похоже как работа со старым добрым Btrieve - получаешь значение по ключу, далее цикл (или несколько вложенных) пока не "кончится" значение ключа.
Только структуру данных видимо проще менять, чем в IMS.
Кстати да - скорость была просто дурная на весьма слабеньких машинах.
13 окт 10, 13:57    [9600046]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
ппм
Guest
iv_an_ru
ппм,
Если пример вызывает проблемы, то не надо в него капитально зарываться, так как он и должен вызывать проблемы. Все ориентированные на OLTP системы плохо приспособлены к циклическим зависимостям на переменных, а если усугублять неравномерностями статистик внутри таблиц, то и многие реляционные СУБД пролетают мимо правильного плана.
В IMS вполне могут быть функции для быстрого получения статистик из хранимок, тогда в хранимке можно написать кучку if-ов, чтобы на основании этих статистик выполнить одну из веток. Просто интересно, делают так на приктике или нет.
Ну и по-прежнему интересны цифирки.

Немного не так. У вас в примере не сущности, а процессы, вот это и вызывает проблемы.
Но я конечно могу обозвать их сущностями, сущность ROUTE, сущность SPIN, и так далее, но что-то подсказывает мне что надо не один в один отображать таблицы реляционки.... Потому как так не делают, не отображают один в один.
Нет в IMS никаких функций для получения статистики, и самой статистики нет, просто в одном объекте естть указатель на связанный с ним.
К примеру.
Есть сущность (в рсубд хранящаяся в таблице, в IMS в сегменте) A.
Есть вторая, B. Никаких связей.
Нужно выбратть все А с соответствующими им В.
Вот здесь важна статистика, и в зависимости от неё будут планы запросов разные.
А теперь то же самое, но в каждом сегменте А есть указатель на первый сегмент В, который от него зависит, в том В естть указатель на следующий В, который зависит от этого же А.
В этом случае нет статистики, и не нужны планы запросов - он всегда один.
То есть - выбрали нужный сегмент А (по условию, или нет), и в этот момент уже известен адрес сегмента В, который зависит от А. При вызове программы - дай мне следующий, Fetch, IMS вернёт этот В и уже будет иметь адрес следующего В. Зачем здесь статистика и планы?
Циклические зависимости - без проблем, я же писал про КЛАДР, сделали именно циклической зависимостью.
В нашем примере найденный сегмент В имеет адрес зависимого от него сегмента А, нро уже другого, не того, с которого мы начали.
Нет множеств - нет статистики распределения данных по этим множетсвам - нет операций над множествами.
Кстати, случай полного обхода дерева будет запрограммирован как вызов
GN
в цикле без параметров до получения статуса возврата - сегментов больше нет.
Эдакий аналог select * from table.
Так мы пример будем делать?

vadiminfo - я рад, что есть кому радеть за концепцию баз данных, и я выражаю уверенность, что вы разберётесь как следует и накажете кого попало.
Что касается моих заявлений - если непонятно, могу пояснить, надо - сделаем примером.
Что касается домыслов - увольте.
Я не буду решать, что такое IMS и какая у неё модель данных.
Вам надо - вы решайте.
Хотите - я вам в ней примерчик слабаю, а вы решайте.
А про функциональные требования - я же сразу ограничил область применимости IMS. Вернее не я :) Производитель :)
Если это не вписывается в ваши задачи - это не для вас ещё до того, как дойдём до нефункциональных требований.
Я бы сильно хотел уйти от теоретических мудрствований, с вашего позволения, я осознаю, что вы в этом лучше разберётесь.
Если вот iv_an_ru не захочет примерчик делать - для интересующихся я могу реализацию КЛАДР выложить, почему её - потому как тоже циклическая зависимость.
А ярлыки вешать - без меня, пожалуйста, если вам при виде слова "иерархия" сразу всё понятно - то я вам не доктор.
Мне было непонятно, я решил разобратся.
13 окт 10, 14:59    [9600626]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
Yo.!
Guest
ну вот, а я так рассчитывал поглядеть как вы будите выкручиваться с этим примером. может все таки "не сущности, а процессы" назовем горшком, а пример оставим ?
13 окт 10, 15:13    [9600744]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
ппм
Guest
в смысле - выкручиваться?
Вам пример охота посмотреть, или что?
Назвать можем как угодно - A B C
A имеет зависимого от него B
B имеет зависимого от него С
С имеет зависимого от него А
так пойдёт?
Задача - по данному А вернуть связанный с ним В
по полученному В вернуть связанный с ним С
по полученному С пернуть связанный с ним А - но уже не тот, с которого начали.
Это то?
Вы разобраться хотите, или похихикать?
Давайте по-хихикаем, я даже первый начну - хи-хи-хи, какое это иерахическое убожество!
Всё, закончили?
Если есть кто другой, кому интересно - продолжим.
13 окт 10, 15:25    [9600852]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6637
Yo.! +1

пример!
13 окт 10, 15:29    [9600887]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
Yo.!
Guest
ппм

Вы разобраться хотите, или похихикать?

я хочу продемонстрировать то что вам для решения придется зашить один из методов обхода иерархии, который будет оптимален только при одном соотношении кол-ва записей в A-B-C, а при все других будет не оптимален.
13 окт 10, 15:31    [9600903]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
ппм
Guest
ну так автор примера на контак пока не идёт.
Или берём на основе абстрактных сущностей?
Я тоже за пример - растекаться мыслью по древу дело благородное, но не охота.
Я вообще-то DB2-шник.
Но вот довелось - я и делюсь.
13 окт 10, 15:33    [9600919]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
ппм
Guest
Yo.!

я хочу продемонстрировать то что вам для решения придется зашить один из методов обхода иерархии, который будет оптимален только при одном соотношении кол-ва записей в A-B-C, а при все других будет не оптимален.

Не делают при работе с IMS обход иерархий!
Это совсем не типичная задача при работе с IMS.
Сделать то можно, последовательным перебором, но надо иметь в виду, что иерархия будет - одна!
из нескольких физических иерархий собирается одна логическая, посредством logical references и secondary indexes, и вот по ней уже выполняются запросы.
Типичные запросы OLTP при работе с IMS - это возврат части записи (запись - иерархическая структура сегментов), то есть за запрос - один сегмент, за другой запрос - ещё один сегмент.
При такой работе все соотношения количества записей не играют рояля, ещё раз медленно для специалистов по РСУБД.
Нашли сегмент А по ключу, допустим.
Всё, возврат из запроса, дальше IMS работает совсем без нас.
Решили - надо получить сегмент В, который зависит от нашего текущего А.
Выполняем вызов - получаем сегмент В, IMS берёт его по адресу, который находится в префиксе уже полученного сегмента А, в этот момент IMS до лампочки статистика, потому, как если в префиксе сегмента А есть адрес сегмента В - то она его и возвращает, если адреса там нет - она отвечает - звыняйте, хлопцi, бананiв нэма.
Всё, получили сегмент В, IMS занята другой работой.
Решили - нужен сегмент С, связанный с текущим сегментом В - не вопрос, если такой сегмент в природе существует, то его адрес есть в префиксе сегмента В - вот, получите.
Решили - нужен сегмент А`, связанный с текущим сегментом С - если такой сегмент есть, то его адрес есть, то мы его получаем.
Вопрос - напуркуа здесь ещё что-то, типа зависимойстей, распределений, статистики?
13 окт 10, 15:42    [9601028]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
ппм
Guest
Yo.!

я хочу продемонстрировать то что вам для решения придется зашить один из методов обхода иерархии, который будет оптимален только при одном соотношении кол-ва записей в A-B-C, а при все других будет не оптимален.

Кстати, а какой может быть метод у обхода иерархии?
Кроме того, который я уже изложил.
13 окт 10, 15:44    [9601064]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
Yo.!
Guest
ппм
Вопрос - напуркуа здесь ещё что-то, типа зависимойстей, распределений, статистики?

странный вопрос для db2 спеца. это же так просто: для того чтобы не перелапачивать А в которой миллиард записей и от нее выходить на B и С в которых 100 записей, а наоборот прочисать 100 записей в С и выйти по адресу на B и С
13 окт 10, 15:57    [9601204]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
Yo.!
Guest
Yo.!
ппм
Вопрос - напуркуа здесь ещё что-то, типа зависимойстей, распределений, статистики?

странный вопрос для db2 спеца. это же так просто: для того чтобы не перелапачивать А в которой миллиард записей и от нее выходить на B и С в которых 100 записей, а наоборот прочисать 100 записей в С и выйти по адресу на B и С

"и выйти по адресу на B и С" следует читать как "и выйти по адресу на B и А"
13 окт 10, 15:58    [9601218]     Ответить | Цитировать Сообщить модератору
 Re: IMS  [new]
ппм
Guest
Yo.!
ппм
Вопрос - напуркуа здесь ещё что-то, типа зависимойстей, распределений, статистики?

странный вопрос для db2 спеца. это же так просто: для того чтобы не перелапачивать А в которой миллиард записей и от нее выходить на B и С в которых 100 записей, а наоборот прочисать 100 записей в С и выйти по адресу на B и С

Йо, а вы в принципе, читаете, то что вам пишут?
Вот в примере выше я писал - где там перелопачивание А?
Там выбор сегмента А, по ключу, или нет.
ОДНОГО сегмента!
Зачем все перелопачивать?
Если у этого одного сегмента А есть связанный с ним сегмент В - то его адрес находится в префиксе ОДНОГО конкретного сегмента А который мы только получили.
Мда....
13 окт 10, 16:00    [9601238]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить