Есть справочник "Справочник". У элементов справочника есть реквизит "Элемент",
который хранит ссылку на другой элемент этого же справочника. Большая часть
элементов связаны по схеме:
Э1 - Э2 - Э3 - ... - ЭN.
Теперь вопрос. Реально ли запросом 1С определить по отдельно выбранному элементу
ЭК все его связи. Другими словами цепочку
ЭК - ЭК+1 - ЭК+2 - ... ЭМ
необходимо представить как таблицу
ЭК ЭК+1
ЭК ЭК+2
...
ЭК ЭМ
который хранит ссылку на другой элемент этого же справочника. Большая часть
элементов связаны по схеме:
Э1 - Э2 - Э3 - ... - ЭN.
Теперь вопрос. Реально ли запросом 1С определить по отдельно выбранному элементу
ЭК все его связи. Другими словами цепочку
ЭК - ЭК+1 - ЭК+2 - ... ЭМ
необходимо представить как таблицу
ЭК ЭК+1
ЭК ЭК+2
...
ЭК ЭМ
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(66)
Игорь.
Я, пол года назад, дал Вам ссылку на некую систему АСУ-чивания предприятий. Она базируется на SQL сервере. Поддерживает по сути и по идеологии иерархическую модель. Имеет средства выборки данных в стиле "запросов". И, если мне не изменяет память, вся схема базы данных обеспечивается десятком таблиц. На сайте есть доступная хорошая документация.
Эту ссылку я Вам дал не для призыва к переходу с продуктов 1С, а для получения (изучения) практических приемов на пути "к построению некой иерархической базе данных"(с). Но Вы как тогда, так и сейчас считаете, что "Проку, правда, от этого никакого ,"(с). И упрямо продолжаете придумывать "алгоритмы запросами" для элементарных задач. И делаете это, как мне показалось, с изрядной долей самолюбования, снобизма, пренебрежения ко всему, что не укладывается в "запросное мышление".
Обратите внимание на то, что исходную задачу этой темы форума Вы повернули из плоскости построения дерева "ссылками" на построение дерева "значениям". Зачем? Почем? Вы сами себе на это можете ответить? Приравняли разные задачи: "процедура раскручивания дерева (читай - "разузлованиаее" номенклатуры),"(с).
С самого начала цикла "Мы пишем запросы" мне казалось, что Вы пытаетесь "прорвать" границы, навязываемой нам 1С-ной, идеологии "удовлетворить заказчика красивой выходной формой", а не решением реальных задач АСУ-чивания.
Теперь мне этого не кажется. :-( Извините, ошибся...
Игорь.
Я, пол года назад, дал Вам ссылку на некую систему АСУ-чивания предприятий. Она базируется на SQL сервере. Поддерживает по сути и по идеологии иерархическую модель. Имеет средства выборки данных в стиле "запросов". И, если мне не изменяет память, вся схема базы данных обеспечивается десятком таблиц. На сайте есть доступная хорошая документация.
Эту ссылку я Вам дал не для призыва к переходу с продуктов 1С, а для получения (изучения) практических приемов на пути "к построению некой иерархической базе данных"(с). Но Вы как тогда, так и сейчас считаете, что "Проку, правда, от этого никакого ,"(с). И упрямо продолжаете придумывать "алгоритмы запросами" для элементарных задач. И делаете это, как мне показалось, с изрядной долей самолюбования, снобизма, пренебрежения ко всему, что не укладывается в "запросное мышление".
Обратите внимание на то, что исходную задачу этой темы форума Вы повернули из плоскости построения дерева "ссылками" на построение дерева "значениям". Зачем? Почем? Вы сами себе на это можете ответить? Приравняли разные задачи: "процедура раскручивания дерева (читай - "разузлованиаее" номенклатуры),"(с).
С самого начала цикла "Мы пишем запросы" мне казалось, что Вы пытаетесь "прорвать" границы, навязываемой нам 1С-ной, идеологии "удовлетворить заказчика красивой выходной формой", а не решением реальных задач АСУ-чивания.
Теперь мне этого не кажется. :-( Извините, ошибся...
(66)
Игорь.
1) Вам удалось создать отладочную базу с деревом 17-20 уровней и 50000-100000 "различных материалов"(с)? Вроде, странное дерево получается. Черенок...
2) Думал-думал я, как, и чего Вам сказать про иерархические СУБД. Трудно к данной теме "прикрутить" принципы из этого класса СУБД. Надо иметь и способы организации хранения данных и способы получения данных из БД. Ну, переход от узла к узлу дерева одной командой и одной операции самой СУБД. И что? Качественные оценки - время обхода дерева не зависит от количества уровней и степеней узлов. Т.е. есть время выполнения одного перехода от узла к узлу умноженное на общее количество узлов в дереве - вот и всё время выполнения алгоритма обхода дерева. Я проверил на своей "домашней" машине обход дерева из 72000000 узлов и десяти уровней - уходит на обход 6000-10000 узлов одна секунда. Медленно. При обходе дерева, посещается каждый узел один раз, т.е. - банальная рекурсия...
Игорь.
1) Вам удалось создать отладочную базу с деревом 17-20 уровней и 50000-100000 "различных материалов"(с)? Вроде, странное дерево получается. Черенок...
2) Думал-думал я, как, и чего Вам сказать про иерархические СУБД. Трудно к данной теме "прикрутить" принципы из этого класса СУБД. Надо иметь и способы организации хранения данных и способы получения данных из БД. Ну, переход от узла к узлу дерева одной командой и одной операции самой СУБД. И что? Качественные оценки - время обхода дерева не зависит от количества уровней и степеней узлов. Т.е. есть время выполнения одного перехода от узла к узлу умноженное на общее количество узлов в дереве - вот и всё время выполнения алгоритма обхода дерева. Я проверил на своей "домашней" машине обход дерева из 72000000 узлов и десяти уровней - уходит на обход 6000-10000 узлов одна секунда. Медленно. При обходе дерева, посещается каждый узел один раз, т.е. - банальная рекурсия...
(76) Если начну анализировать Ваш пост (76) - мы увязнем надолго.
Давайте так - "узко-конкретно", то есть протестируем Ваш алгоритм.
Дана таблица :
Владелец,Номенклатура, Количество.
В этой таблице опишем "дерево".(7 уровней вложенности)
В справочнике Номенклатура создается ПЕРВЫЙ элемент НАЧАЛО и 7 десятков номенклатур. Каждый десяток отличается префиксом кода : А,Б,В,Г,Д,Е,Ж.
Десяток А , например, состоит из Номенклатур с кодами :
А001
А002
..........
А010
Реализуем подчиненность НАЧАЛО - А-Б-В-Г-Д-Е-Ж. Это значит , что НАЧАЛО состоит из десятка А , каждый элемент справочника А состоит из десятка Б, каждый элемент справчоника Б состоит из десятка В , и т.д
Далее понятно каким образом заполнена исходная таблица.
Начминаем раскручивать таблицу для элемента НАЧАЛО и получим в конце раскрутки миллион элементов только с префиксами Ж . Группируем и на выходе должны иметь только 10 элементов
Ж001,Ж002...Ж010 со своими количествами.
Контроль зациклинности обязателен. Т.е. каждая ветка мысленно полученного дерева должна быть проверена на повторение элементов в этой ветке.
Реализовать алгоритм можно каким угодно образом.
Сколько длится Ваш алгоритм для такой исходной таблицы ?
Варианты ответов :
1. 4 мин. - Не о чем говорить
2. 3 мин. - Очень плохо
3. 2 мин - плохо
4. 1.5 мин - посредственно
Пока так. Дальше сложнее.
Давайте так - "узко-конкретно", то есть протестируем Ваш алгоритм.
Дана таблица :
Владелец,Номенклатура, Количество.
В этой таблице опишем "дерево".(7 уровней вложенности)
В справочнике Номенклатура создается ПЕРВЫЙ элемент НАЧАЛО и 7 десятков номенклатур. Каждый десяток отличается префиксом кода : А,Б,В,Г,Д,Е,Ж.
Десяток А , например, состоит из Номенклатур с кодами :
А001
А002
..........
А010
Реализуем подчиненность НАЧАЛО - А-Б-В-Г-Д-Е-Ж. Это значит , что НАЧАЛО состоит из десятка А , каждый элемент справочника А состоит из десятка Б, каждый элемент справчоника Б состоит из десятка В , и т.д
Вид таблицы :
Владелец Номенклатура Количество
Начало А001 2
Начало А002 2
................................................................
Начало А010 2
А0..1 В001 2
А0..1 В002 2
................................................................
А0..1 В010 2 ПоказатьДалее понятно каким образом заполнена исходная таблица.
Начминаем раскручивать таблицу для элемента НАЧАЛО и получим в конце раскрутки миллион элементов только с префиксами Ж . Группируем и на выходе должны иметь только 10 элементов
Ж001,Ж002...Ж010 со своими количествами.
Контроль зациклинности обязателен. Т.е. каждая ветка мысленно полученного дерева должна быть проверена на повторение элементов в этой ветке.
Реализовать алгоритм можно каким угодно образом.
Сколько длится Ваш алгоритм для такой исходной таблицы ?
Варианты ответов :
1. 4 мин. - Не о чем говорить
2. 3 мин. - Очень плохо
3. 2 мин - плохо
4. 1.5 мин - посредственно
Пока так. Дальше сложнее.
(79)
Игорь.
Сейчас напишу и засеку время. Но, только Вы бы меня спросили - какая у меня "домашняя" машина? Какая СУБД? Или Ваш подход "узко-конкретно"(с) на такие мелочи не обращает внимание? Т.е. сравнивать килограммы с метрами - это так сейчас принято? Или обходиться характеристиками - большая/маленькая база? Или абсолютными величинами - время "Х" это хорошо, плохо, мало, много... Балдею, слов у меня нетУ...
Игорь.
Сейчас напишу и засеку время. Но, только Вы бы меня спросили - какая у меня "домашняя" машина? Какая СУБД? Или Ваш подход "узко-конкретно"(с) на такие мелочи не обращает внимание? Т.е. сравнивать килограммы с метрами - это так сейчас принято? Или обходиться характеристиками - большая/маленькая база? Или абсолютными величинами - время "Х" это хорошо, плохо, мало, много... Балдею, слов у меня нетУ...
(81)
Игорь.
Мля. :-)
Ты (!!!) меня разозлил окончательно своим убогим представление о других людях и их задачах.
Клиент-серверная СУБД "Advantage 9.1".
Все исходные данные лежат/читаются/записываются только в/из БД.
Intel X58
QuadCore Intel Xeon E5520, 2400 MHz (восемь потоков).
12 гигабайт на шести планках DDR3-1066, 3-х канальный режим.
RAM диск для рабочих файлов - 2 гигабайта.
Системный диск - WD1002FBYS, 1 терабайт, 7500 об., буфер 32 мегабайта.
Диск под БД - программный RAID 0 на двух дисках WD1002FBYS.
Система - Windows XP x64 SP2.
Игорь.
Мля. :-)
Ты (!!!) меня разозлил окончательно своим убогим представление о других людях и их задачах.
Клиент-серверная СУБД "Advantage 9.1".
Все исходные данные лежат/читаются/записываются только в/из БД.
Intel X58
QuadCore Intel Xeon E5520, 2400 MHz (восемь потоков).
12 гигабайт на шести планках DDR3-1066, 3-х канальный режим.
RAM диск для рабочих файлов - 2 гигабайта.
Системный диск - WD1002FBYS, 1 терабайт, 7500 об., буфер 32 мегабайта.
Диск под БД - программный RAID 0 на двух дисках WD1002FBYS.
Система - Windows XP x64 SP2.
(82) Просто превосходно !
К чему ссориться ?
Невежливые предположения - быстрее приближают нас к истине ( "узко-конкретный подход " ).
(83) Ага ! Ошибся. Семь уровней , включая первый элемент(корень) это число 10 в 6 степени, т.е. миллион. Последний десяток - с кодом "Е".
(84) В любом случае спасибо за проведенный эксперимент !
Очень важно и полезно решать одну и ту же задачу в разных СУБД .
Благодаря Вам подтвердились мои предположения !
Теперь о главном. Я решаю такую задачу в 1с8 (клиент - сервер) MSSQL.
Техника средне - хорошая.(я в ней не очень разбираюсь).
Запускается и выполняется код обработки на клиенте.
Код процедуры - это цикл , внутри цикла один очень небольшой запрос.
Время выполнения , т.е. получения выходной таблицы с десятью элементами "Е" (миллион) существенно меньше , чем 188 сек.
Подготовлю публикацию и подробно уже всё объясню и приведу текст запроса.
Тогда Вы с легкостью проверите меня - такой цикл с запросом легко реализуем в Вашей СУБД.
Если настаиваете приведу и время выполнения для 10 000 000 записей.
Еще раз спасибо ! Вы почти освободили меня от тяжелых сомнений.
До публикации !
К чему ссориться ?
Невежливые предположения - быстрее приближают нас к истине ( "узко-конкретный подход " ).
(83) Ага ! Ошибся. Семь уровней , включая первый элемент(корень) это число 10 в 6 степени, т.е. миллион. Последний десяток - с кодом "Е".
(84) В любом случае спасибо за проведенный эксперимент !
Очень важно и полезно решать одну и ту же задачу в разных СУБД .
Благодаря Вам подтвердились мои предположения !
Теперь о главном. Я решаю такую задачу в 1с8 (клиент - сервер) MSSQL.
Техника средне - хорошая.(я в ней не очень разбираюсь).
Запускается и выполняется код обработки на клиенте.
Код процедуры - это цикл , внутри цикла один очень небольшой запрос.
Время выполнения , т.е. получения выходной таблицы с десятью элементами "Е" (миллион) существенно меньше , чем 188 сек.
Подготовлю публикацию и подробно уже всё объясню и приведу текст запроса.
Тогда Вы с легкостью проверите меня - такой цикл с запросом легко реализуем в Вашей СУБД.
Если настаиваете приведу и время выполнения для 10 000 000 записей.
Еще раз спасибо ! Вы почти освободили меня от тяжелых сомнений.
До публикации !
(85)
Игорь.
Принято - ждем статью.
Однако, прошу обратить внимание на нюансы "нашей" постановки задачи.
Если мы ничего НЕ храним в БД кроме указанной таблички, то при любом алгоритме требуется обойти ВСЕ узлы дерева. Т.к. количество изделий на N-ом уровне вычисляется как произведение количеств в узлах родителей. А, например, изделие "болт" может находиться как на 6-ом уровне, так и на втором (как терминальная вершина).
В реальных задачах, типа разузлования, дополнительная информация хранится в дополнительных полях и, часто, в других таблицах для эффективного решения именно задач разузлования. Типа: промежуточные "итоги"; "выкидывание" из основного дерева повторяющихся узлов изделий (поддеревья) в разных ветвях дерева; контроль зацикливания на этапе ввода/изменения информации и т.д.
И в любом алгоритме имеет смысл минимизировать количество "троганий" каждого узла в/из БД и исключение порождения рабочих таблиц БД (т.е. использовать только чтение). Естественно, учитывая конечность (предсказуемость размеров) и реальность обработки рабочих массивов в оперативной памяти (т.е. не загонять всю таблицу БД в таблицу значений). Например в "нашей" задаче (моим алгоритмом), для подсчета общего количества изделий и контроля зацикливания использовалось три "массива" (списка) с известными размерностями 7,7,10 элементов. ;-) Т.е."мой" алгоритм предсказуем (одно "трогание" каждого узла) и не возникает странных фраз как из #17 сообщения, типа: "...дерево НЕБИНАРНОЕ допускает коварные штуки."(с) Ну и про рекурсии высказывания - это... ;-) ... "запросное" видение ВСЕХ, окружающих нас, задач. :-(
P.S. При замерах времени выполнения теста, не забывайте перезагружать ВСЮ системы, включая ОСы и сервера БД. Иначе Ваш алгоритм сведётся к обработке "таблиц значений". Системы, то, умные - кеширование данных используют. ;-)
Игорь.
Принято - ждем статью.
Однако, прошу обратить внимание на нюансы "нашей" постановки задачи.
Если мы ничего НЕ храним в БД кроме указанной таблички, то при любом алгоритме требуется обойти ВСЕ узлы дерева. Т.к. количество изделий на N-ом уровне вычисляется как произведение количеств в узлах родителей. А, например, изделие "болт" может находиться как на 6-ом уровне, так и на втором (как терминальная вершина).
В реальных задачах, типа разузлования, дополнительная информация хранится в дополнительных полях и, часто, в других таблицах для эффективного решения именно задач разузлования. Типа: промежуточные "итоги"; "выкидывание" из основного дерева повторяющихся узлов изделий (поддеревья) в разных ветвях дерева; контроль зацикливания на этапе ввода/изменения информации и т.д.
И в любом алгоритме имеет смысл минимизировать количество "троганий" каждого узла в/из БД и исключение порождения рабочих таблиц БД (т.е. использовать только чтение). Естественно, учитывая конечность (предсказуемость размеров) и реальность обработки рабочих массивов в оперативной памяти (т.е. не загонять всю таблицу БД в таблицу значений). Например в "нашей" задаче (моим алгоритмом), для подсчета общего количества изделий и контроля зацикливания использовалось три "массива" (списка) с известными размерностями 7,7,10 элементов. ;-) Т.е."мой" алгоритм предсказуем (одно "трогание" каждого узла) и не возникает странных фраз как из #17 сообщения, типа: "...дерево НЕБИНАРНОЕ допускает коварные штуки."(с) Ну и про рекурсии высказывания - это... ;-) ... "запросное" видение ВСЕХ, окружающих нас, задач. :-(
P.S. При замерах времени выполнения теста, не забывайте перезагружать ВСЮ системы, включая ОСы и сервера БД. Иначе Ваш алгоритм сведётся к обработке "таблиц значений". Системы, то, умные - кеширование данных используют. ;-)
(86) Принимается почти без возражений.
Если "По-честному" то алгоритм не должен обладать никакой априрной информацией.
Знание 7 уровней и 10 элементов ( и предварительное создание соответствующих массивов) существенно облегчает (ускоряет) задачу.
Алгоритм должен работать "вслепую" и одинаково с любым деревом.
На данный момент задача ставится именно так.
Если "По-честному" то алгоритм не должен обладать никакой априрной информацией.
Знание 7 уровней и 10 элементов ( и предварительное создание соответствующих массивов) существенно облегчает (ускоряет) задачу.
Алгоритм должен работать "вслепую" и одинаково с любым деревом.
На данный момент задача ставится именно так.
(88)
1) "Принимается почти без возражений"(с)
Почти - что?
2) "Если "По-честному" то..."(с)
В "моём" алгоритме никаких "констант" не использовалось. Кроме фазы заполнения дерева - в массиве прописал характеристики дерева. Т.к. алгоритм заполнения - универсальный в части количества уровней и степеней узлов по уровням.
1) "Принимается почти без возражений"(с)
Почти - что?
2) "Если "По-честному" то..."(с)
В "моём" алгоритме никаких "констант" не использовалось. Кроме фазы заполнения дерева - в массиве прописал характеристики дерева. Т.к. алгоритм заполнения - универсальный в части количества уровней и степеней узлов по уровням.
(85)
Игорь.
Кстати. Старая хохма. ;-) Я об этом эффекте забыл.
У меня обход дерева написан на "1С 7.7".
Для работы с каждым узлом дерева выполняется Спр=СоздатьОбъект().
Т.е. сколько узлов столько раз он создаётся и уничтожается.
Дык, это занимает 54 секунды от общего времени в 185 сек.
Чисто - время работы процессора на стороне клиента.
Переписывать на другой способ создания объекта - мне лениво.
Но "моё" время можно смело уменьшить, процентов на 25-30.
Надо будет - перепишу...
Игорь.
Кстати. Старая хохма. ;-) Я об этом эффекте забыл.
У меня обход дерева написан на "1С 7.7".
Для работы с каждым узлом дерева выполняется Спр=СоздатьОбъект().
Т.е. сколько узлов столько раз он создаётся и уничтожается.
Дык, это занимает 54 секунды от общего времени в 185 сек.
Чисто - время работы процессора на стороне клиента.
Переписывать на другой способ создания объекта - мне лениво.
Но "моё" время можно смело уменьшить, процентов на 25-30.
Надо будет - перепишу...
(90)
1. Я полагал , что 77 вообще не использовлась. А использовались "чисто-конкретный" язык Вашей ядрёной Субд. Но спорить не будем.
2. Использование Спр=СоздатьОбъект() в процедуре разузлования - это за гранью моего понимания. Но спорить не буду.
3.Скинем 30% получим 120 сек = 2 мин (см. п 3). Это мелочи.
1. Я полагал , что 77 вообще не использовлась. А использовались "чисто-конкретный" язык Вашей ядрёной Субд. Но спорить не будем.
2. Использование Спр=СоздатьОбъект() в процедуре разузлования - это за гранью моего понимания. Но спорить не буду.
3.Скинем 30% получим 120 сек = 2 мин (см. п 3). Это мелочи.
(93)
Игорь.
Как всегда, Вас удивляет мой текст, а меня удивляет Ваш.
1) "Я полагал , что 77 вообще не использовлась."(с)
Есть СУБД. Есть API этой СУБД для разных языков программирования и разных методов обработки информации (запросный, навигационный). Есть ODBC, ADO и т.д., если использовать только запросный метод доступа к данным, и преследуется цель условной совместимости приложения к различным СУБД. Мной написан интерфейс подменяющий DBF-ный движок на навигационный способ доступа этой СУБД. Добавлено в 1С несколько функций прямого обращения с этой СУБД для расширения родных 1С-овых методов обработки данных.
Т.к. рекурсивный обход дерева делается навигационным методом доступа к данным, то какая разница из какой системы выполняется обращение к этой СУБД. Мне, на данном этапе было удобнее написать проблемную составляющую задачи на "1С 7.7".
2) "Использование Спр=СоздатьОбъект() в процедуре разузлования - это за гранью моего понимания."(с)
Думаю, "за гранью", т.к. до сих пор в нашей беседе происходит путаница задач. В рекурсивном обходе дерева каждый узел "рассматривается" как корень дерева. И, естественно в каждом узле надо обеспечить "рукоятку" для работы с таблицей данных (в нашем случае - справочником). Текст, то рекурсивного функции элементарный:
P.S. Метод "ВыбратьЭлементыПоРеквизиту()" это не запрос. ;-)
Игорь.
Как всегда, Вас удивляет мой текст, а меня удивляет Ваш.
1) "Я полагал , что 77 вообще не использовлась."(с)
Есть СУБД. Есть API этой СУБД для разных языков программирования и разных методов обработки информации (запросный, навигационный). Есть ODBC, ADO и т.д., если использовать только запросный метод доступа к данным, и преследуется цель условной совместимости приложения к различным СУБД. Мной написан интерфейс подменяющий DBF-ный движок на навигационный способ доступа этой СУБД. Добавлено в 1С несколько функций прямого обращения с этой СУБД для расширения родных 1С-овых методов обработки данных.
Т.к. рекурсивный обход дерева делается навигационным методом доступа к данным, то какая разница из какой системы выполняется обращение к этой СУБД. Мне, на данном этапе было удобнее написать проблемную составляющую задачи на "1С 7.7".
2) "Использование Спр=СоздатьОбъект() в процедуре разузлования - это за гранью моего понимания."(с)
Думаю, "за гранью", т.к. до сих пор в нашей беседе происходит путаница задач. В рекурсивном обходе дерева каждый узел "рассматривается" как корень дерева. И, естественно в каждом узле надо обеспечить "рукоятку" для работы с таблицей данных (в нашем случае - справочником). Текст, то рекурсивного функции элементарный:
//--------------------------------------
Процедура Читать(Знач Вершина)
Если Маршрут(+1,Вершина)=0 Тогда Возврат; КонецЕсли;
Спр=СоздатьОбъект("Справочник.Дерево");
Спр.ВыбратьЭлементыПоРеквизиту("Связь",Вершина,0,0);
Пока Спр.ПолучитьЭлемент()=1 Цикл
Читать(Спр.ТекущийЭлемент());
КонецЦикла;
Маршрут(-1,Вершина);
КонецПроцедуры
//-------------------------------------- ПоказатьP.S. Метод "ВыбратьЭлементыПоРеквизиту()" это не запрос. ;-)
(99)
Игорь.
1) Мы уже выясняли, что является хамством в наших "пониманиях". В моём понимании сообщение #99 - хамство.
2) Я не компьютерщик, я - пенсионер.
3) Это не художественный текст. Это ВЕСЬ текст алгоритма. Остальное - выражения типа "Кол=Кол+..." и вывод (размещение) результата в форме печати.
Расстаёмся!
Желаю успехов в написании запросов...
Игорь.
1) Мы уже выясняли, что является хамством в наших "пониманиях". В моём понимании сообщение #99 - хамство.
2) Я не компьютерщик, я - пенсионер.
3) Это не художественный текст. Это ВЕСЬ текст алгоритма. Остальное - выражения типа "Кол=Кол+..." и вывод (размещение) результата в форме печати.
Расстаёмся!
Желаю успехов в написании запросов...
(90) Передумал. Владимир, а не создать ли Вам полноценную обработку для работы с таблицей Владелец,Номенклатура, Количество. Только помните , если таблица содержит зацикливание (повторение элемента в текущей ветке) , то Ваша обработка должна выдавать пользователю всю ошибочную ветку.
Действительно ! А то получается , что Вы у меня работаете подносчиком снарядов.
Идет ?
Скажем , после моей публикации Вы накроете её своей с эпиграфом :
"Эх, вы запросники тёмные..".
Тактически неплохо и упредить мою публикацию :
"Я тут слышал, что "запросники" хотят учудить..."
А если серьезно.. то Вам стоит подумать над своей публикацией.
Действительно ! А то получается , что Вы у меня работаете подносчиком снарядов.
Идет ?
Скажем , после моей публикации Вы накроете её своей с эпиграфом :
"Эх, вы запросники тёмные..".
Тактически неплохо и упредить мою публикацию :
"Я тут слышал, что "запросники" хотят учудить..."
А если серьезно.. то Вам стоит подумать над своей публикацией.
(94)
Игорь.
"а не создать ли Вам полноценную обработку"(с)
А у меня чего сделано? Или Вы об совместном разглядывании моих исходных текстов? На самом деле у меня все обработки "полноценные". Автомобили... Там задачки "разузлования" ооо-чень интересные. До этого была органическая химия. Помните бензольные кольца? Сети, циклы, графы, поиски "подобных" хим. соединений...
А без шуток, нам надо не скорости процессоров сравнивать, а проводить полноценный анализ алгоритмов и методов их "развертывания" в среду программирования и СУБД. Самый простой (первый) - это анализировать "масштабируемость" алгоритма. Т.е. как изменяется время обработки от количества уровней дерева (иерархии), степеней узлов, количества узлов.
А вставить/вынуть проверку цикличности (три оператора) или подсчет общего количества "десяти" различных номенклатур на нижнем уровне (пять операторов) - это дело техники. И ничего не проясняет....
Давайте займемся делом. А?
Игорь.
"а не создать ли Вам полноценную обработку"(с)
А у меня чего сделано? Или Вы об совместном разглядывании моих исходных текстов? На самом деле у меня все обработки "полноценные". Автомобили... Там задачки "разузлования" ооо-чень интересные. До этого была органическая химия. Помните бензольные кольца? Сети, циклы, графы, поиски "подобных" хим. соединений...
А без шуток, нам надо не скорости процессоров сравнивать, а проводить полноценный анализ алгоритмов и методов их "развертывания" в среду программирования и СУБД. Самый простой (первый) - это анализировать "масштабируемость" алгоритма. Т.е. как изменяется время обработки от количества уровней дерева (иерархии), степеней узлов, количества узлов.
А вставить/вынуть проверку цикличности (три оператора) или подсчет общего количества "десяти" различных номенклатур на нижнем уровне (пять операторов) - это дело техники. И ничего не проясняет....
Давайте займемся делом. А?
(96)
Вам не ждать надо, а писать её. ;-)
Я подчищаю свой текст программы.
Могу его, потом, плюхнуть тут на форуме.
Могу отправить Вам в личку и обсудить.
Лучше, думаю, уже по Skype.
Естественно, если Вы хотите разобраться в "СУБД", а не в "СКД"...
P.S. Очень часто вспоминаю Вашу фразу про "нашего отца" и ремесло. :-(
Вам не ждать надо, а писать её. ;-)
Я подчищаю свой текст программы.
Могу его, потом, плюхнуть тут на форуме.
Могу отправить Вам в личку и обсудить.
Лучше, думаю, уже по Skype.
Естественно, если Вы хотите разобраться в "СУБД", а не в "СКД"...
P.S. Очень часто вспоминаю Вашу фразу про "нашего отца" и ремесло. :-(
(79)
"получим в конце раскрутки миллион элементов"(с)
Допускаю, что у меня уже плохо и с арифметикой.
Но на выходе получается больше 10 миллионов записей.
Игорь.
Пока у меня идет заполнение тестовой базы, скажу.
Я, выше по теме, написал, что просмотр любого дерева на моей системе проходит за: КоличествоУзлов/6000 секунд. Алгоритм использовался - рекурсия. Тестирование проводилось на реальной базе с деревом 72000000 узлов. Если обойти всё это дерево, то это будет 72000000/6000 секунд. Вы же, опять, пытаетесь подсунуть свою задачу - и не задачу темы форума, и не разузлование, а - НЕЧТО. Это НЕЧТО решается и без обхода дерева, и очень быстро любыми средствами программирования. Т.е. наблюдается, то, что я уже написал Вам выше по теме - решается не поставленная задача, а решается задача удобная для выбранных Вами инструментами. Ну, решайте... :-(
"получим в конце раскрутки миллион элементов"(с)
Допускаю, что у меня уже плохо и с арифметикой.
Но на выходе получается больше 10 миллионов записей.
Игорь.
Пока у меня идет заполнение тестовой базы, скажу.
Я, выше по теме, написал, что просмотр любого дерева на моей системе проходит за: КоличествоУзлов/6000 секунд. Алгоритм использовался - рекурсия. Тестирование проводилось на реальной базе с деревом 72000000 узлов. Если обойти всё это дерево, то это будет 72000000/6000 секунд. Вы же, опять, пытаетесь подсунуть свою задачу - и не задачу темы форума, и не разузлование, а - НЕЧТО. Это НЕЧТО решается и без обхода дерева, и очень быстро любыми средствами программирования. Т.е. наблюдается, то, что я уже написал Вам выше по теме - решается не поставленная задача, а решается задача удобная для выбранных Вами инструментами. Ну, решайте... :-(
(79)
Игорь.
Когда на нижнем уровне 10000000 вершин, то время выполнения 1870 сек.
Когда на нижнем уровне 1000000 вершин, время выполнения 188 сек.
Т.е. около 5300 вершин в секунду, если с дополнительными условиями.
Ваше задание выполнено. ;-)
Вы, выше, написали "Пока так. Дальше сложнее."(с).
Так, вот, теперь я Вам предлагаю.
Сделайте просто обход дерева запросами, там где 10 миллионов на нижнем уровне.
В цикле, рекурсией - как хотите.
Но без "В оперативной памяти создается Таблица значений"(с).
Не надо проверять цикличность, не надо ничего подсчитывать.
Просто "побывайте" в каждом узле дерева...
Игорь.
Когда на нижнем уровне 10000000 вершин, то время выполнения 1870 сек.
Когда на нижнем уровне 1000000 вершин, время выполнения 188 сек.
Т.е. около 5300 вершин в секунду, если с дополнительными условиями.
Ваше задание выполнено. ;-)
Вы, выше, написали "Пока так. Дальше сложнее."(с).
Так, вот, теперь я Вам предлагаю.
Сделайте просто обход дерева запросами, там где 10 миллионов на нижнем уровне.
В цикле, рекурсией - как хотите.
Но без "В оперативной памяти создается Таблица значений"(с).
Не надо проверять цикличность, не надо ничего подсчитывать.
Просто "побывайте" в каждом узле дерева...
фигня в том, что есть разница между реляционными БД и типа файловой структуры. извращаться на уровне 1с здесь нет маржи
**
"предлагаете хранить в конфигураторе некие постоянные вспомогательные(избыточные) справочники - таблицы , которые ускорят построение дерева для СпецификацииНоменклатуры ?"
- ну, да, если без прямых
**
"предлагаете хранить в конфигураторе некие постоянные вспомогательные(избыточные) справочники - таблицы , которые ускорят построение дерева для СпецификацииНоменклатуры ?"
- ну, да, если без прямых
(64) Ты приводил пример с разузлованием электровоза . Ты говорил о 17 уровнях.
А не помнишь сколько там было на выходе различных материалов ?
10 000 ? 30 000 или 50 000 ?.
Кто написал процедуру на SQL с использованием рекурсии , ту, которая за 60 сек ?
Она реально использовалась ? или просто прикола ради.
А не помнишь сколько там было на выходе различных материалов ?
10 000 ? 30 000 или 50 000 ?.
Кто написал процедуру на SQL с использованием рекурсии , ту, которая за 60 сек ?
Она реально использовалась ? или просто прикола ради.
Ish_2 пишет:
Ты приводил пример с разузлованием электровоза . Ты говорил о 17 уровнях.
А не помнишь сколько там было на выходе различных материалов ?
10 000 ? 30 000 или 50 000 ?.
Кто написал процедуру на SQL с использованием рекурсии , ту, которая за 60 сек ?
Она реально использовалась ? или просто прикола ради.
Ты приводил пример с разузлованием электровоза . Ты говорил о 17 уровнях.
А не помнишь сколько там было на выходе различных материалов ?
10 000 ? 30 000 или 50 000 ?.
Кто написал процедуру на SQL с использованием рекурсии , ту, которая за 60 сек ?
Она реально использовалась ? или просто прикола ради.
это фрагмент реальной переписки, АСУП в контексте - реальная асуп
(69)
Михаил.
У меня не получается вставить Ваше сообщение #69 в "контекст реальной АСУП" в свете цикла "Мы пишем запросы" и основного назначения языка запросов, как средства, направленного на быструю разработку выходных форм.
Или сообщение #69 адресовано Игорю?
Михаил.
У меня не получается вставить Ваше сообщение #69 в "контекст реальной АСУП" в свете цикла "Мы пишем запросы" и основного назначения языка запросов, как средства, направленного на быструю разработку выходных форм.
Или сообщение #69 адресовано Игорю?
(69)
Михаил.
Еще раз про реальное АСУп.
Я привел в сообщении #54 реальные характеристики техники прошлого века.
И вопрос "сколько там было на выходе различных материалов ?"© особо не вставал. Сколько надо было - столько и было. Естественно не за 60 секунд. Не те, тогда были мегагерцы. Но, поверьте мне, не было тогда бурных обсуждений алгоритма и схемы базы данных для обхода "дерева". И основная причина, думаю, в том что схема базы данных разрабатывалась под предметную задачу, а не под удобства вытаскивания информации запросами. И чего, же тогда за такие продвинутые средства (запросы), которые требуют таких усилий для написания алгоритмов уровня первого курса института. Вас это не удивляет? Нам 1С сказала - предметную область будете описывать документами и регистрами. Брать и обрабатывать эту информацию будете запросами. Будет медленно работать - покупайте новую технику. И мы как стадо ... пошли ... :-( Да, еще, хлопаем в ладоши как дети - игрушку нам дали.
Иногда, имеет смысл представить, что за эту игрушку придется платить из своего кармана. И за сервер БД, и за железный сервер, и за обслуживание всего этого. Сразу, ладошки перестают хлопать...
Михаил.
Еще раз про реальное АСУп.
Я привел в сообщении #54 реальные характеристики техники прошлого века.
И вопрос "сколько там было на выходе различных материалов ?"© особо не вставал. Сколько надо было - столько и было. Естественно не за 60 секунд. Не те, тогда были мегагерцы. Но, поверьте мне, не было тогда бурных обсуждений алгоритма и схемы базы данных для обхода "дерева". И основная причина, думаю, в том что схема базы данных разрабатывалась под предметную задачу, а не под удобства вытаскивания информации запросами. И чего, же тогда за такие продвинутые средства (запросы), которые требуют таких усилий для написания алгоритмов уровня первого курса института. Вас это не удивляет? Нам 1С сказала - предметную область будете описывать документами и регистрами. Брать и обрабатывать эту информацию будете запросами. Будет медленно работать - покупайте новую технику. И мы как стадо ... пошли ... :-( Да, еще, хлопаем в ладоши как дети - игрушку нам дали.
Иногда, имеет смысл представить, что за эту игрушку придется платить из своего кармана. И за сервер БД, и за железный сервер, и за обслуживание всего этого. Сразу, ладошки перестают хлопать...
(136) Странно.
Находясь в любом узле произвольного графа, пусть даже не имеющем исходящих веток, мы :
1. Ничего не можем сказать об уровне графа (соседняя оставшаяся ветка может иметь уровень больше).
2. Ничего не знаем об количестве оставшихся непройденными узлов
Уровень графа и количество узлов могут быть определены одним образом :
обойти все узлы графа. И никак иначе.
Вопрос : а если мы обошли все узлы графа, то зачем нам еще какие-то построения и числовые характеристики ? - Мы уже решили задачу.
Поэтому числовые значения "61" и "510" для меня не имеют никакого смысла.
Находясь в любом узле произвольного графа, пусть даже не имеющем исходящих веток, мы :
1. Ничего не можем сказать об уровне графа (соседняя оставшаяся ветка может иметь уровень больше).
2. Ничего не знаем об количестве оставшихся непройденными узлов
Уровень графа и количество узлов могут быть определены одним образом :
обойти все узлы графа. И никак иначе.
Вопрос : а если мы обошли все узлы графа, то зачем нам еще какие-то построения и числовые характеристики ? - Мы уже решили задачу.
Поэтому числовые значения "61" и "510" для меня не имеют никакого смысла.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот