СКД против "ручного" кодинга
Разработка - Работа с интерфейсом
Бесплатные
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Узнавайте о новых бесплатных решениях в нашей телеграм-группе Инфостарт БЕСПЛАТНО
| Наименование | Скачано | Бесплатно |
|---|---|---|
|
ОборотыСчетаБП1_6.erf
.erf 21,78Kb
267
|
267 | Скачать бесплатно |
Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Сравним по быстродействию типовой отчет БП 1.6 "Обороты Счета" и его аналог, интерактивно созданный на СКД . Запуск рассматриваемых отчетов будет осуществляться в конфигурации БП 1.6.
Экспериментальный отчет ОборотыСчетаБП1_6.erf, оформленный в стиле БП 2.0 , прикреплен к статье для скачивания:
В отчет добавлен небольшой дополнительный функционал : колонки "Обороты Дт" и "Обороты Кт" должны разворачиваться не только по счетам (как в БП 1.6 и в БП 2.0) , но и произвольным настраиваемым образом . Например , по счетам и первому субконто этих счетов :
Описание
В СКД созданы три очевидных набора данных :
1. "Остатки " как запрос к виртуальной таблице "ОстаткиИОбороты" :
2. "ОборотыДт" как запрос к виртуальной таблице "ОборотыДтКт"
3. "ОборотыКт" как запрос к виртуальной таблице "ОборотыДтКт"
Набор "Остатки" левым соединением связан с наборами "ОборотыДт" и "ОборотыКт" . В "Настройках" используется объект "Таблица" :
С помощью минимального "оформительского" кодинга в модуле формы получим отчет в стиле БП 2.0. Представленная экспериментальная разработка может рассматриваться лишь как основа для создания полнофункционального отчета со всеми необходимыми пользовательскими настройками.
Сравнение с БП 1.6
Убрав отметки в настройках у отмеченных выше красным группировок, можно сравнить по быстродействию представленный отчет и аналогичный типовой "Обороты счета" в БП 1.6 . Возможно также сравнение и с отчетом автора от 2009г. //infostart.ru/public/18838/ . Тогда я не решился использовать СКД и "вручную" реализовал разворачивание колонок "Обороты Дт" и "Обороты Кт" по счетам и первому субконто. Огромный проигрыш "ручного" кодинга в быстродействии был очевиден уже тогда. Сегодня читатели могут в этом убедиться.
Экспериментальный отчет выигрывает у типового по быстродейтсвию от 2 до 5 раз.
Сравнение с БП 2.0
Типовой отчет "Обороты счета" БП 2.0 более сложен. В нём использовано больше дополнительных наборов данных и прямое сравнение по быстродействию затруднительно. Сравнить можно лишь способы разворачивания оборотов по корр.субконто :
Как видно из рисунка , корр.субконто в БП 2.0 располагаются в строках отчета причем "вперемешку" и дебетовые и кредитовые , что снижает, на мой взгляд, читаемость отчета. С другой стороны , отчет в БП 2.0 располагает более разнообразным богатым функционалом.
Публикация автора Tuning1c //infostart.ru/public/21923/ содержит отчет "Обороты счета" из БП 2.0 , адаптированный для запуска в БП 1.6.
Вступайте в нашу телеграмм-группу Инфостарт
См. также
Работа с интерфейсом Анализ учета Мониторинг 1С:Предприятие 8 1С 8.3 1C:Бухгалтерия 1С:Бухгалтерия 3.0 1С:ERP Управление предприятием 2 1С:Управление холдингом 1С:Зарплата и Управление Персоналом 3.x 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Управление торговлей 11 Платные (руб)
Создайте свой функциональный интерфейс в любой конфигурации 1С с помощью расширения Infostart Dashboard. Настраивайте панели виджетов с метриками, индикаторами и показателями на начальном экране. Узнайте возможность внедрения подсистемы у себя в конфигурации с помощью бесплатной обработки "Анализ внедрения подсистемы 1С Infostart Dashboard"!
31720 руб.
27.03.2025 92405 69 44
Консолидация данных Работа с интерфейсом Разработчик Пользователь 1С:Предприятие 8 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 1C:ERP Узбекистан Беларусь Кыргызстан Россия Казахстан Платные (руб)
Знакомая ситуация? Пользователи, особенно менеджеры, уверены: отборов много не бывает. Идут пожелания добавить в форму списка еще один быстрый фильтр, еще два, еще пять... В итоге интерфейс превращается в нагромождение полей отбора, а потребность в «самом главном» отборе, который «вот прямо сейчас нужен», все равно не закрыта. Универсальное расширение, которое решает эту проблему элегантно и технологично. С его помощью в любую форму списка можно легко добавить панель настраиваемых кнопок-закладок, каждая из которых применяет сложный фильтр-запрос, а так же показывает актуальное количество элементов в реальном времени.
6088 руб.
17.10.2025 3683 3 0
Разработка Инструментарий разработчика Работа с интерфейсом Адаптация типовых решений Нейросети 1C:Бухгалтерия 1C:ERP 1С:ЗУП 1С:КА 1С:УНФ 1С:УТ 1С:Розница 1С:ДО 1С:ERP Управление предприятием 2 Платные (руб)
Разработка "Дизайнер форм 1С" реализована в виде расширения 1С и является универсальным инструментом для разработки прототипа форм с целью демонстраций, технических заданий и т.д. Без участия разработчика с возможностью экспорта в файл внешней обработки и генерации формы используя искусственный интеллект.
36600 руб.
28.08.2025 10394 2 2
Работа с интерфейсом Разработчик Стажер 1С:Предприятие 8 Бесплатно (free)
Это инструкция по дизайну форм в среде 1С. Гайд охватывает рекомендации и стандарты для оптимизации пользовательского интерфейса. В гайде содержатся указания по использованию элементов интерфейса, включая как основные, так и продвинутые аспекты. Предоставляются также примеры и антипримеры для наглядного понимания принципов дизайна
20.08.2024 57488 mrXoxot 44
Работа с интерфейсом Разработчик 1С:Предприятие 8 Бесплатно (free)
Пример простого и симпатичного прогресс-бара в динамическом списке, без картинок, используя редактирование запроса.
27.05.2024 30028 smielka 39
Инструментарий разработчика Работа с интерфейсом Разработчик 1С 8.3 Абонемент ($m)
Подходит для создания web-страниц для замены управляемых форм 1С, красивых отчетов, интерфейса мобильного приложения на платформе 1С и для простых страниц веб-сайтов.
1 стартмани
10.04.2023 19504 190 acces969 31
Работа с интерфейсом Разработчик 1С:Предприятие 8 1C:Бухгалтерия Бесплатно (free)
Питничная фантазия на возможности в разработке интерфейсов формы с помощью Платформы 1С - делаем свою подсказку. Публикация содержит готовую библиотеку программного формирования данной подсказки.
12.08.2022 16992 top_1c 39
Работа с интерфейсом Разработчик 1С:Предприятие 8 1C:Бухгалтерия Абонемент ($m)
"MVC плохо применима в 1С" - познакомьтесь с моделью состояния и, возможно, ваше мнение поменяется! Представленное решение является эволюционным развитием идеи реализации MVC для 1С. В новой версии добавлены DSL для описания модели состояния, а также параметризация свойств параметров и элементов формы.
1 стартмани
05.07.2022 17981 kalyaka 8
Отчет "Обороты счета" является примером сложной перекрестной таблицы.
Реализовать такую построителем невозможно. Остается ручной кодинг.
Сила СКД - в составлении перекрестных таблиц
В теме предлагается читателю сравнить представленный отчет и типовой в БП 1.6 по быстродействию и самостоятельно сделать вывод : что быстрее ?
Отчет для ветеранов , которые настаивают , что СКД -"бантик".
В теме я почтительно пытался их переубедить .
Убежден , что после такого примера они "дружною толпою" перебегут на сторону энтузиастов СКД.
Перекрестную таблицу ты "грамотно" составленным запросом в 1с не создашь.
Тебе придется "вручную" обрабатывать выборки запроса и в цикле выводить области табличного документа. Посмотри код типового отчета "Обороты Счета" в БП 1.6 или УПП .
Проблема перекрестных таблиц ( то бишь таблиц с динамическими колонками) в СУБД обсуждалась где-то в середине 90-х годов. Разные Субд по-разному решили эту проблему.
Недавно у меня не получилось выделить (цветом, шрифтом, не важно) итоги по группировкам (строки/колонки - только итоги) в сложной перекрестной таблице. Потратил несколько часов, но так и не допер :(
В появившемся окне
Группировка1 это строки
Группировка2 это колонки.
В перекрестии этих строк и колонок можно создать область макета для форматирования соответствующих ресурсов.
Например , чтобы как- то выделить последнюю итоговую строку отчета - нужно
в группировке 1(строки) поставить "Заголовок" - в Группировке 2(Колонки) поставить "Общий итог подвал". Могу соврать , но примерно так.
Но это даже хорошо ! Стало ясно еще более отчетливо :
как угодно оптимизированный "ручной" кодинг проиграет по быстродействию СКД.
Насчет оптимизации. Да я отпимизировал существующий код. Но кто сказал, что методика используемая для построения типового отчета является наиболее эффективной? Может проблема здесь? Ведь в типовом отчете данные собираются двумя запросами, а в СКД одним. Уверен, что при достаточной проработке методики формирования отчета можно значительно повысить скорость вывода данных в отчет и без СКД. Например, можно попросить Душелова написать ВК :)
Придётся проверять так : насоздавать "лишних" операций так , чтобы все колонки дебета и кредита были заполнены и тогда уже сравнить СКД и твой отчет с отключенными расшифровками.
Правда , сразу нужно отметить :
Расшифровки, замедляющие быстродействие типового отчета в 2раза (!), всё равно нужны и отключать их при сравнении некорректно . Ведь в СКД расшифровки -то используются и оптимальная работа с расшифровками - это одно из больших преимуществ СКД перед "ручным" кодингом.
При корректном сравнении даже как угодное оптимальные расчет и запись расшифровок займут время и "кодинг" все равно проиграет в разы.
Мой Прогноз : ВК не спасет , Душелов не спасет ... и никто не спасет .
Нехорошо это.
Тут бы с MS SQL, Oracle, DB2 (реляционных по сути) разобраться хоть как нибудь ,
а нам предлагается как спасение - "Постреляционная СУбд Cashe5" , требующая своего языка доступа к Базе данных (SQL- на свалку, все реляционно ориентированные приложения , стало быть тоже). Вот заживём !
Чем черт не шутит , но что-то с 2003г (время написания статьи) я не слышал чтобы Cashe5 отгрызла хоть какой-то кусочек рынка (для бизнес -приложений) у тех же MS SQL, Oracle, DB2 .
Может подождем пока Cashe5 сдохнет... или завоюет весь мир ?
Тогда и обсудим чем она хороша (плоха) ?
Неокрепшие умы могут не окрепнуть, а задубеть.
Вот это, действительно - "Нехорошо".
Я уважаю Ваш "конкретный" (прагматичный) подход к нашим задачам.
Но не видеть (или не знать), что "...использование реляционного подхода не столь эффективно в таких приложениях, как АСУП,..."(с) - это ОЧЕНЬ "Нехорошо".
Разработчики 1С-ов - видят и знают. Но решают проблемы "реляционного подхода" за деньги пользователя (покупателя). А мы публикуем и долго обсуждаем статьи по алгоритмам из двух циклов. А это ОЧЕНЬ грустно...
Сильно.
Тот самый случай , когда невозможно определить :
То ли очень глупо , то ли очень умно.
А то , что мы обсуждаем алгоритмы из двух циклов... Это правда.
Когда-то давно я взгрустнул познакомившись с бухгалтерскими задачами.
Но потом как-то прошло...
Я не говорю про "бухгалтерские задачи" из двух циклов.
Тема моих высказываний: "Проблема перекрестных таблиц ( то бишь таблиц с динамическими колонками) в СУБД обсуждалась где-то в середине 90-х годов"(с)(7).
Т.е., опять, проводим "научные" исследования на пустом месте, когда "Мы пишем запросы!". Нет никакой проблемы с динамическим колонками - два простейших цикла...
То есть вопрос - в реализации платформы на практике. Или - насколько 1С-ные разработчики восприняли теорию, которая упомянута в (94).
- выполнение двух запросов, получение их результатов.
- собственно "ручной" кодинг : цикл, в котором построчно выводятся результаты
запроса в выходной табличный документ (по вашему "Таблица").
Аналог этого отчета на СКД содержит , грубо говоря, те же запросы, а вот обработку результатов запроса и рисование отчета производит внутренними механизмами СКД.
Никакого выигрыша в скорости выполнения запросов ("первый этап") при использовании СКД мы не имеем. Выигрыш имеем за счет реализации "второго этапа" : обработка результатов запроса и рисование отчета.
Никакого своего , "внутреннего" языка запросов СКД не имеет.
А в (94) Владимир говорит о чём -то своём ... далёком и отвлечённом.
P.S. Я изложил упрощенно-грубо , в первом приближении , необходимом для понимания.
"Владимир говорит о чём -то своём ... далёком и отвлечённом"(с)
Игорь.
Я уже и не знаю о чем говорить. ;-)
Говорю о "теории" про два цикла - мимо.
Предлагаю провести конкретные замеры - мимо.
Предлагают разобраться в сути ускорения - мимо.
И постоянно, с Вашей стороны, "крепкая конкретика", снабженная "качественными" оценками, типа:
"... многократно проиграет в быстродействии."(с)
"... алгоритм , на мой взгляд, для больших таблиц выиграет у любого другого."(с)
"... размер таблиц ... может быть как угодно большим ."(с)
"... таблицы ... могут быть очень большого размера."(с)
"... для как небольших, так и очень больших объемов данных (свыше 120-150 ГБ)."(с)
На мой взгляд это гадание "на кофейной гущи". :-(
Я понимаю, что вы поставлены ("домиком") в условия обязательного использования "1С 8.х" и "запросов". Типа, жизнь заставляет... Но, Вы, как мне показались, пытаетесь осмыслить внутреннее устройство системы, а не тупо жать на кнопки. И это вызывает уважение с моей стороны. И, извините, вызывает желание "подтолкнуть" Вас к более глубокому анализу - зачем, где, когда и почему "Мы пишем запросы!"(с). Я постараюсь больше этого не делать...
Мы расходимся с Вами в том , как вести дискуссию в теме.
Я считаю , что автор темы должен играть первым номером. Что это значит ?
Автор темы должен делать утверждения. Они могут быть и неверными. Но они должны быть. Далее автор должен представить конретную разработку , подтверждающую его правоту. Далее автор должен привести сравнительный анализ (с чем -либо), сделать выводы. Причем четкие , определенные - такие, которые можно было бы оспорить.
Ясная, определенная позиция - это клад для оппонента , который хочет эту позицию опровергнуть.
Действительно , возьмем фразу- утверждение (извиняюсь за самоцитирование) - "... многократно проиграет в быстродействии."
Для чего она ? - Она для оппонента, желающего её опровергнуть.
Для этого есть все возможности - в теме-то указано что сравнивать и как сравнивать.
Смотри (88).
Именно этим автор выказывает уважение возможным оппонентам , т.е. честной игрой по правилам. А колкости можно пропукать мимо глаз ...
Я часто (бывает и не по делу) с удовольствием выступаю в темах Арчибальда. Почему ?
Потому что он играет по тем же правилам.
Когда же автор ведет себя безопасно , не делает утверждений , (пусть резких, пусть неверных) , а делится размышлизмами , которые невозможно ни подтвердить, ни опровергнуть - тема получается ни о чём и быстро вянет.
Делайте утверждения , Владимир !
"Когда ... автор ,,, делится размышлизмами ..."
- Тем самым, автор предлагает собеседнику поразмышлять, т.е. - думать.
"Я считаю , что автор темы должен..."
- Да. Я заметил, что Вы считаете, что все должны излагать свои мысли, так как это Вам хочется. Ваше право - считать. Право других людей - игнорировать Ваши "хотелки".
"Мы расходимся с Вами в том , как вести дискуссию в теме."
- А мы с Вами и не ведем дискуссию. Её, просто, не существует. Пример. Два специалиста обсуждают принципы работы пульта ДУ для телевизора. Один говорит о функциональной нагрузке кнопок (включение, регулятор громкости, выбор каналов и т.д.), а другой о способе передачи информации от ДУ к приёмнику (протокол, физика, принципиальная схема устройства, элементная база и т.д.).
"Делайте утверждения..."
- Игорь. А мои фраза, типа: "Такой задачи (проблемы) не существует". Это, разве, не утверждение. Или надо действовать проще - поставить "минус". Или сказать, что "Автору нужно помочь с выражением того , что он хочет сказать."(с).
Игорь.
Поиск "волшебных палочек" для "автоматизации" труда программиста ведётся с момента появления самой профессии "программист". Язык запросов - одна из таких "палочек". Весь мир (думающая его часть) уже давно пришла к выводу, что эта палочка является зубочисткой. А Вы с 1С-ами пытаетесь ковырять этой палочкой в другом месте. Это не гигиенично... ;-)
P.S. Попробуйте эту "колкость пропустить мимо глаз". ;-)
Утверждение , которое здесь приводится ни опровергнуть , ни подтвердить нельзя.
О чем спорить -то ?
Зубочистка или нет ? Весь мир или не весь мир ? Гигиенично это или нет ?
Всё пустое, всё мимо ...
А Вы начните свою статью словами " Эх, вы одинесники... тёмные и дремучие "
(.. это так - для затравки разговора , чтобы народ подтянулся).
Затем приведите пример , который люди могут потрогать , пощупать , попробовать, сравнить.
Сделайте выводы о гибельности 1с-овского курса, которые можно будет опровергнуть ( плохо -хорошо, быстро-медленно). И тогда мы поспорим .
А сейчас что ? (101) - это мило , забавно... НО НЕ ЦЕПЛЯЕТ.
"Всё пустое, всё мимо ..."
- У Вас в глаз соринка попала в форме "восьмерки". Протрите глаза. Вы на мои "статейки" и "поделки" смотрели?
"О чем спорить -то ?"
- Именно - так. Спора не может быть. Опять повторю - мы говорим о разных вещах. Думаю, пред началом спора (обсуждения) имеет смысл договориться о предмете спора.
"А Вы начните свою статью словами..."
- Не понял! Я написал статью? Или Вы написали статью? Или Вы мне предлагаете написать статью? Лично я не вижу статьи в обозначенной Вами теме "Мы пишем запросы!". Предмета для статьи - НЕТ. Я не пишу запросы. И у меня не возникает никаких проблем (вопросов) для широкого обсуждения простейших алгоритмов реализации моих задач. А у Вас возникает. Почему?
"Сделайте выводы о гибельности 1с-овского курса..."
- Не могу. Т.к. этот курс будет жить долго и счастливо. Как и многие другие "курсы" для массового потребления, типа MS Windows, SQL серверов, алкоголя, наркотиков и т.д. ;-)
"НО НЕ ЦЕПЛЯЕТ"
- Смените продавца "цеплялки". ;-)
При сравнении двух отчетов , отключено разворачивание по Кт. Включено только по Дебету. "Лишними" операциями добились заполнения всех колонок счетов дебета , Получили таблицу 2500 строк - 25 колонок ( из которых полностью заполнены 20 по счетам Дебета).
Результаты :
Твой отчет 12 сек
Мой отчет 10 сек
Вывод : в предельном случае (когда все колонки заполнены на 100% ) отчет с отключенными расшифровками проиграет те самые 20%. ЧТо подтверждает результат , который ты получил ранее.
Обработку расшировки при выборе ячейки мы можем сделать какой угодно : по элементу расшифровки определяя все текущие необходимые значения.
В моём отчете и не планировалось его делать. Зачем ? Цель была другая. Но ничто не мешает сделать расшифровку в моем отчете , аналогичной в типовом отчете БП 1.6.
Расшифровка в СКД в моём отчете уже ЕСТЬ !
Всем ячейкам табличного документа поставлен в соответсвие "ЭлементРасшифровки". При двойном клике на ячейке уже выведенного отчета - я не использую всех возможностей расшифровки и не строю другие отчеты , хотя с помощью переданного в процедуру "ЭлементаРасшифровки" можно получить все необходимые данные для построения подчиненного отчета.
Зачем ? К быстродействию уже выведенного отчета это не имеет никакаго отношения.
Замерить и узнать :
можно уже сейчас. Запусти мой отчет и типовой . Сравни результаты. Вот и всё.
При использовании СКД после выполнения отчета каждой ячейке выходного табличного документа ставится в соответсвие "ЭлементРасшифровки". И когда пользователь выбирает ячейку (нажимает Enter или двойной клик) на ней - ему передается этот самый "элемент" как параметр. По этому элементу методами ПолучитьПоля или Получить Родителя можно определить либо все поля текущей группировки или элемент расшифровки верхнего уровня .
Извиняюсь. Это я, на всякий случай, своими словами передал содержание документации.
+119 Расшифровки тоже можно формировать более эффективными методами. Почему это не сделано? Наверное всё дело в пользователях - они не жалуются. Есть варианты: не пользуются этим отчетом; пользуются этим отчетом крайне редко; пользуются другим отчетом, который шевелится побыстрее.
1. Запусти типовую БП 1.6.
2. Запусти типовой отчет для 62 счета , который называется "Обороты Счета".
Засеки время.
3. Запусти текущий отчет (ОборотыСчетаБП1_6.erf).
4. Убери галочки в настройках как показано на третьем сверху рисунке темы.
5. Установи 62 счет за тот же период.
6. Кнопка Сформировать
Засеки время и сравни с п.2
1. Ты посчитал что расшифровки можно выбросить из п .2. ?
Мы ими можем пренебречь , они не нужны в отчете ?
2. Возьми больший период (чтобы в типовом он выпонялся 2-3 мин.) .
Тогда какое соотношение ?
(30) Конечно. Но отчет демонстрационный, код в нём минимален, директивы для компилятора убраны.
(27) Алексей . отправь мне "гостинец" - оформленный как внешний отчет "обороты счета" из типовой. С твоими исправлениями.
Ты не подумай - я тебе верю. Просто проверю.
При старте 1с Предприятие 8.1 метаданные не грузятся.
Подгрузка необходимых метаданных( а не данных !) происходит по мере обращения к ним.
Поэтому если запустить 1с Предприятие 8 и последовательно два раза запустить один и тот же отчет , то можно убедиться , что при втором запуске время исполнения отчета существенно меньше. После первого обращения метаданные уже в кэше.
Теперь вопрос : а третий запуск отчета будет быстрее чем второй ? Другими словами ,
используются при третьем запуске данные( а не метаданные!) кэша 1сПредприятия, которые остались в нем после второго запуска ?
1. Если в отчете используется запрос , для извлечения данных, то третий запуск будет не быстрее. Опыт показывает , что время 2,3, 4, 5 , запуска с небольшой погрешностью одинаково.
2. Если в отчете используется объектная техника доступа к данным ( Получаем объект и обращаемся к его реквизитам через точку) - то всё может быть. Не пробовал.
Правда , такое обращение к к данным в отчете - экзотика.
Игорь.
Метаданные в кэше это хорошо. Но если из-за этого "время исполнения отчета существенно меньше"(с), то это говорит об очень плохой реализации алгоритмов работы с метаданными. Сомневаюсь я в этом. Думаю, сильнее влияют на время повторного запуска, именно, сами данные. Про третий запуск можно не рассуждать. Но надо сказать - какой отчет запускается третьим. Т.е. если нет желания "перезагружать систему", то можно запустить несколько раз с чередованием два разных отчета. А по уму - надо запускать три раза каждый отчет с "перезагрузкой системы" перед каждой серией тестов. А потом внимательно (вдумчиво) смотреть на числа.
P.S. Извините меня, что я донимаю Вас этой информацией (вопросами). Но сам провести тесты не могу, т.к. у меня нет компьютера. А было бы интересно посмотреть на результат замеров.
После первого запуска , второй и последующий запуски отчета одинаковы по времени выполнения - это факт ( и при файловом и SQl- варианте).
Всё остальное - мои рассуждения. Не меньше , но и не больше.
Это я так .. для прояснения ситуации.
В (75) лишь разделил свои размышления и факты.
А перезапустить систему перед отчетом нетрудно. После презапуска системы показывает такое же время при первом запуске и при втором как и до перезапуска системы.
В (37) речь шла об одном сеансе 1сПредприятия , в котором последовательно дважды запускался отчет.
В (77) сраниваются по быстродействию :
1. Первый запуск сеанса 1сПредприятия : дважды запускается отчет.
- Выход из сеанса
2. Второй запуск сеанса 1сПредприятия : дважды запускается отчет.
И говорится о том , что в п.1 и в п.2 время исполнения отчетов одинаковое.
2. 45,173 сек
6. 39,845 сек
Над оптимизацией вывода результатов можно еще поработать. Сбить 2-3 секунды реально. Т.к. ~70% времени выполняются запросы, можно покопать ещё там.
Про расшифровки. Я не утверждаю, что расшифровки не нужны. Просто в типовой конфигурации на их формирование уходит значительная часть времени - почти половина времени формирования отчета. Я за честное соревнование.
Хотя я надеялся, что расшифровки появятся в варианте отчета с СКД.
1. Отчет , прикрепленный к текущей теме (ОборотыСчетаБП1_6.erf)
2. Типовой Отчет конфигурации БП , прикрепленный в (36) и исправленный Alexk-is. Расчет и запись параметров расшифровки удалены из типового отчета.
1с Предприятие 8.1. SQL-вариант. БП 1.6
Настройки для п.1. :См.Рисунок темы третий сверху. Дополнительно :
Отметки у подчеркнутых красным группировок сняты.
У группировок СчетКтКорр и СчетДтКорр установлен тип "Иерархия"
(разворачивать колонки будем только по корр.счетам и корр.субсчетам,
выводим все субконто основного счета)
Настройки для П.2:
Установлены отметки "По субсчетам" и "По корр.субсчетам".
Выводить будем все субконто основного счета.
Для п.1. и п.2. устанавливается один и тот же счет (например счет -группа 62).
и один и тот же период (например, квартал).
По п1. и п.2. запуск осуществляется по 3 раза подряд в отдельных сеансах 1с Предприятия.
Результаты тестирования :
п.1 - 20 сек
п.2. - 37 сек
Проигрыш п.2. в 1.8 раза.
Вопрос : откуда могло взяться соотношение (36) , приведенное Alexk-is :
п.1 - 39 сек
п.2 - 45 сек ?
Предположительный ответ :
Если в настройках п.2 убрать отметку "По субсчетам корр.счетов" ( уменьшаем как минимум в два раза количество колонок) , а настройки п.1 оставляем без изменений то получим :
п.1 - 20 сек
п.2 - 24 сек.
Получается похожее соотношение , как Alexk-is
Переделал отчеты под УПП 1.2.
Результаты:
2. 23,172 сек
6. 11,891 сек
Разница более чем в 2 раза
Из-за чего такое различие по времени выполнения между БП и УПП? Думаю разница в составе данных, попавших в отчет. Соответственно для одного предприятия будет значительная разница, а для другого разницы не будет вообще или она будет не столь значительная.
Типовой отчет "Обороты счета", в котором для ускорения выключена расшифровка, работает примерно в 2 раза медленнее , чем представленный в текущей теме отчет , использующий СКД.
Теперь о тестировании на БП.
Почему получаем различные результаты ?
Объяснение :
- звучит для меня невероятно ( Для счетов в которых есть какие -то обороты ( 5-6 колонок счетов для дебета и кредита) - и строк в отчете не менее 80-100)
Считаю , что в этом случае представленный отчет и для БП должен выиграть в быстродействии как минимум 1.8-2.0 раза.
Без третейского судьи тут никак.
Ну быстрее отчет работает написанный на СКД и что из этого следует?
Итак , у вас есть регистр
Измерение1,Измерение2, Ресурс.
Вам нужно получить отчет "Перекрестная таблица" :
В строках Измерение1 ,В столбцах Измерение2 , в "перекрестье" Ресурс.
Если Измерение1 - Номенклатура , Измерение2 - Склады , Ресурс - Остаток.
То получить нужно :
---------- Склад1 -- Склад2 ----Склад 3
Стол
Стул
Шкаф
ИТОГО
Главной отличительной особенностью такой перекрестной таблицы является неопределенное заранее количество столбцов (динамические столбцы).
Как вы это будете делать в 8-ке ? Без построителя , и без СКД ?
Созданием такой перекрестной таблицы занимался каждый в своей жизни.
И выкручивался как мог - "вручную" . Выкрутились и разработчики "типовой" БП .
Так вот . Такую часто повторяющуюся задачу можно реализовать на уровне платформы.
(что , конечно, значительно эффективнее).
Первой попыткой в 8.0 было создание ПостроителяОтчетов. Но он позволял строить лишь простые перекрестные таблицы (Обороты счета на нём не построишь) .
Потом в 8.1 в 2007 г. появидось СКД , позволяющее на уровне платформы решать задачи построения более сложных перекрестных таблиц гораздо более эффективно чем пользовательский кодинг. Что и было продемонстрировано в текущей теме.
Правда другие СУбд , решили эту задачу на уровне платформы значительно раньше.
2. Простой пример перекрестной таблицы реализовать несложно. Да и в (26) речь не о сложности . А о том, что задачу построения перекрестной таблицы лучше эффективнее решать на уровне платформы. То есть при помощи СКД.
Строго говоря , утверждать что-либо можно только из опыта.
Берем Регистр со структурой в (26) и большим объемом данных. "Ручным" способом (Без построителя и СКД) рисуем отчет из (26) . Затем то же рисуем в СКД и в Построителе.
Сравниваем.
Затем то же проделываем с отчетом "Обороты счета". Сравниваем.
Мой прогноз : СКД победит и в первом и во втором случае.
Предполагаю , что :
штатный отчЁт - уже ничего не стоит ...
просто отчЁт - сделает кто как сможе и будет работать на ... 0...20 % медленне ... и то не факт ... вопрос а судьи кто ? и кто ЧТО знает КАК реализовать ...
отчЁт на СКД - ??? ... крАсивая фишка ... не вижу никакго эффекта ни от её изучения ... ни от её использования ... опытным - это мало помогает ... а для новых - забивает голову "иными" костылями ...
... вотЕСТЬмнение ...
п.с. постоянная потребность в "новых" отчётах - говорит об неУстоявшейся системе и правил Учёта и Управления ... так что ... ? ... вот ...
п.с.2. ВСЁ что меньше 12% - это проценты туда-суда-Нефакт ... увеличение на 50 % - есть вопрос задуматься ... вот если производительность вырастае в разы !!! - тогда есть смысл "смотреть" и изучать ... а так ... вроде все заняты делом а КПД - смешное ... зато пантов-то ... пантов-то ... вотТАКОЕоскорбительноеМнение ...
...
п.с. постоянная потребность в "новых" отчётах - говорит об неУстоявшейся системе и правил Учёта и Управления ... так что ... ? ... вот ...
Я считаю, что ты неправ, Шёпот. Требования "новых" отчетов -- прямое следствие роста и развития бизнеса. Если в компании пользуются только отчетами, созданными три года назад -- это свидетельствует о том, что с тех пор компания не далеко продвинулась. Это конечно относится не ко всем инструментам. Некоторые не устаревают очень долго, ими можно пользоваться десятилетиями :).
Бизнес -- как живой организм, так же растет, изменяется и когда-нибудь умирает. Если у бизнеса не возникает новых задач, значит он стоит на месте.
(42) ... в разы ... хм ... ещЁ один вопрос а зачем ... ? важна не только "сама"производительность отчЁта но и количество его вызовов ... например, проведение и перепроведение ВАЖНЕЕ чем раз в день вызвать несколько отчЁтов ( даже пусть в пиковые, отчётные периоды вызывается несколько раз ... и что... ? ... отчет готовится за минуту или за 20 сек - не отчёты ЕСТЬ лимитирующая стадия работы ...)
... хотя в целом производительность в разы - СОгласен ... если Alexk-Is подтвердит ...
... однако, ! ... хотя это будет важно в основном для крупных и очень крупных компаний ... для рядовых - это мёртвому припарка ... повторюсь - лимитирующая стадия работы это не получение отчётов ... !!!
... вот ...
п.с. ускорение отчётов - проще достигуть оптимизацией базы... нужными и точечными данными и их получением (а не тащить всЁ ради не понятной универсальности) ...
... вот ...
просто отчЁт - сделает кто как сможе и будет работать на ... 0...20 % медленне ... и то не факт ... вопрос а судьи кто ? и кто ЧТО знает КАК реализовать ...
отчЁт на СКД - ??? ... крАсивая фишка ... не вижу никакго эффекта ни от её изучения ... ни от её использования ... опытным - это мало помогает ... а для новых - забивает голову "иными" костылями ...
Представленный отчет является демонстрационным. Как его использовать решает читатель.
Так об этом и толкую.
Выигрыш от использования СКД для больших, сложных перекрестных таблиц : В РАЗЫ .
Ответ Alexk-Is готовится.
... а ещЁ лучше вернуться в "семёрку" а эту "восьмёрку" послать ... причём в очень НЕэтичное место и в очень НЕэстетичной манере ...
... ВОТ ...
... восЬмёрка своими "бантиками" .... уже достигла уровня своей НЕкомпетентности ...
...
п.с. при этом мы же знаем что 8 - ка ... это бантики ... хоть и крАААсивые ... однозначно ... !
...
Речь о чем идет (заметь, аватарка гласит "Мы пишем запросы"). О том, что восьмерочный механизм СКД настолько приличен, что восьмерочный же кодинг не оправдывает себя - при изрядных трудозатратах выигрыш весьма невелик. Сравнение с семеркой столь же неуместно, как сравнение Виндов с ДОСом - Ясно жде что в ДОСе тот же функционал на порядок быстрее и на два порядка менее требователен к памяти. Однако ж - прогрессьь...
Никто здесь "семерку" и не вспоминал и "сравнение с семеркой" притянуто Арчибальдом за уши.
Практичнее думать о себе , а не о провальности 8-ки ," с точки зрения экономики" ...
Практичнее овладевать СКД , а не переживать "о 98% предприятий".
СКД ускоряет другое - скорость разработки, удобство разработки и доработки, увеличивает производительность труда программиста.
.. мало сделать отчёт ... его надо ещЁ и переделывать ... и ещё не известно кто ЭТО будет делать и когДА... !
... вотМнениевот ...
Представленныи отчет для чего ?
Для того чтобы любопытный пользователь сам проделал опыт и убедился СКД - это не "бантик", а прежде все более высокая скорость выполнения сложных отчетов (перекрестных таблиц).
См (47)
...
...
... вотМнение ...
Двадцать лет «эффективного рынка» - падение сборов зерна на 20%
... и ещё: средняя оплата труда на земле сейчас в три раза ниже советского колхозного уровня.
(Все цифры даны только по РСФСР, разумеется, и в сравнении с цифрами по РФ).
...
..."Я понимаю, что многим не может нравиться факт, что колхозы в 30-х спустя всего несколько лет превзошли результаты частной формы собственности, причем и итоги и дореволюционные, итоги помещичьего землевладения, и итоги после революционные – итоги землевладения частного, крестьянского, землевладения фермерского типа, уверенно показав преимущества социалистической формы собственности.
История поставила и третий эксперимент – эксперимент 90-х и нулевых, с тем же результатом – чистая победа колхоза над капиталистом.
Но это же факт.
Не тужьтесь опровергнуть, только пукнете и испортите тут воздух, господа.
"....
... многие скажут что не в тему ... но я бы не стал так утверждать ... вспомните закон аналогий ...
... вот ...
И используя "закон аналогий" получим :
Но это же факт.
Не тужьтесь опровергнуть, только пукнете и испортите тут воздух, господа.
Выходит , ты , Шепот ,( по аналогии...) - "за наших " ? За СКД ?
... зачем же рассматривать выгоды "чего либо" без их Издержек ... ? ... ! ...
... нуу.... не окупится "ваше" СКД на наших предприятиях ... следовательно "по отдельности" НАМ хорошо а "всем вместе" будет ПЛОХО ...
... бег по кругу ... как музыка попсы - три ноты в цикле ...
... засим умолкаю ... от своего же ЗАнудства уже тошно стало ... вот ...
п.с. : «Сейчас православие — это основа модернизации. Лично я считаю, что русские компьютеры должны создаваться при русских монастырях: умные молитвы, умное делание, умное монашество. Мы считаем, что православный инновационный центр должен открыться в Сколкове, потому что Церковь — это опора модернизации, а не помеха.»
...
п.с.2 : Замкнутый контур из икон, украшенных монетами, усиливая специфическую активность мозга, может усилить сопротивляемость повышенной солнечной активности и повышению электромагнитного фона
Новая российская наука.
... где-то тут и СКД ... чешется ... вот ...
Предмет для статьи – есть, и он обозначен в заголовке.
Если бы тема не была интересна, то не было бы сотни с лишним комментариев.
И вообще, воспользуюсь приемом Арчибальда – средний рейтинг проголосовавших за статью = 381,5. Дальнейшие аргументы (статья – не статья, нужна – не нужна) вряд ли будут более показательными, чем этот.
Ирина.
Скажу больше. И спора никакого нету! Есть "глобальный" вопрос. Средства "автоматизации" программирования - СКД, запросы и сама платформа 1С должны, на мой взгляд, упростить и облегчить труд программиста. Но создаётся впечатление, что этого не происходит. Т.е. я, по жизни, разрабатываю такие же задачи (в случае темы обсуждения - формы) без СКД и запросов. И никаких вопросов (тем) для общественного обсуждения не возникает. Никаких исследований производительности не требуется проводить. Типа, как написал - так и работает. Больших временных затрат программиста на разработку - не наблюдаю.
Владимир, насчет "глобальности" вопроса - мне кажется, что в основном этот труд облегчается. Даже на примере элементарных обновлений (сравнивая 7.7 и 8). И СКД упрощает этот труд. Во всяком случае, я, не будучи программистом, иногда тоже по необходимости составляю какие-то отчеты, именно с помощью СКД получается с ними разобраться, и довольно быстро. Другие способы написания отчетов за это время вряд ли освоишь. "Больших временных затрат программиста на разработку - не наблюдаю" - да, все делается быстро, если уметь. В том же 7.7 отчеты, насколько я помню, написать намного сложнее, чем в 8 (Это все субъективное мнение, и уже совсем не по теме статьи, конечно)
Ирина.
В Вашем сообщении ключевая фраза: "не будучи программистом". И всё, что Вы написали - абсолютно верно. Но цикл тем от Игоря - другой. И я пытаюсь с ним обсуждать не СКД и, даже, не 1С (любой версии).
К вопросу об "автоматизации" программирования - похвалюсь ;-)
Первая моя самостоятельная разработка была: "Генератор отчетов для СУБД ...". После внедрения этой разработки десять проблемных программиста лишились работы. А конечный пользователь забыл дорогу в отдел программирования. В разработке был сделан ЯМД для пользователя не программиста. В этом ЯМД, естественно, был язык запросов. И это было в начале 70-х годов...
Игорь.
Извините. Не в тему скажу. Очередную глупость.
Вы написали: "А "генератор отчетов" реализовывал в том или ином виде каждый уважающий себя начинающий программист."(с).
Я так понимаю, что СКД, условно, можно назвать генератором отчетов для конечного пользователя (не программиста). Не думаю, что фирма 1С набрала "начинающих" программистов в "конце" десятилетнего проекта. Мне это напоминает "бег по кругу". Т.е. долго-долго разрабатываются средства "автоматизации" труда программиста. Потом вспоминаем - для кого это всё нужно. Вспоминаем, о конечном пользователе. Или этот пользователь достал нас своими "хотелками". И... На тебе очередной генератор отчетов. Только отстань от меня - программиста. Не мешай мне заниматься объектным программирование для предметной области под названием - программирование.
Но очень хочется увидеть не методы "объектов" реляционной СУБД: Новый(), Записать(), Удалить(), Найти(), Выбрать() и т.д. А увидеть, например, для объекта "товар" методы, типа: Поступление(), Перемещение(), Продажа(), Списание() и т.д. И будет нам ВСЕМ - счастье... ;-)
"объекты, ... "немножко" не учетные."
- А если посмотреть на саму "учитываемую" предметную область. Например, на реальную жизнь, то совсем НЕ "немножко".
(131) Игорь.
"На уровне конфигурации вполне можно реализовать методы Поступление() и т.д."
- А "хочется" на уровне платформы. Её среднего уровня (не в терминах 1С 8.х).
"И тогда окажется , что эти методы так сложны даже для определенной предметной области"
- Возможно, по реализации. Но не по использованию. Ведь существует метод - "Хочу всё" в объекте "Мир". И многие им успешно пользуются не программируя методы. ;-)
"что без программиста НИКАК"
- А я и написал "счастье - ВСЕМ". Программисты делают реализацию методов, а пользователи их используют. Все при деле и деньгах. И не мешают друг-другу. Вопрос только - "какое имя объекта?". Очень обидно, что 1С-ы разработали объектную модель для предметной области под именем - "Запрос".
"Так уж лучше мы дадим не узкоспециализированный язык для программистов , а более "широкий""
- Точно. :-) Универсальное решение уже давно создано - алгоритмический язык. Всё остальное - частные решения.
Это очень спорно... но пусть ! И тогда окажется , что эти методы так сложны даже для определенной предметной области (скажем, торговли) , что без программиста НИКАК.
Так уж лучше мы дадим не узкоспециализированный язык для программистов , а более
"широкий" . И окажется , что от "Новый - Записать-Удалить" - никуда не деться. Круг замкнулся.
Игорь.
Конкретно в Вашу тему. ;-)
В (26) сообщении сказано: "Главной отличительной особенностью такой перекрестной таблицы является неопределенное заранее количество столбцов (динамические столбцы)." Но пример со складами не очень удачный. Т.к. список складов всегда известен. Другое дело, если в условия данного примера добавить, примерно, такой текст: "Требуется не выводить колонки со всеми "пустыми" значениями остатков". Тогда, думаю, пример и со складами сгодится. Т.е. требуется определить "список" динамических столбцов. Чудес не бывает - надо просматривать всю таблицу и "набирать" (допустим в массив) уникальные значения по колонке "Склад". Алгоритмов не так много.
1) Тупой просмотр с начала таблицы всех записей. Поиск уже существующего значения в массиве и добавление не найденного значения в массив.
2) Установить порядок просмотра по колонке "Склад". Взять значение первой строки. Запомнить в массиве и рабочей переменной. Далее выполнять в цикле (до конца таблицы) поиск по ключу записи с первым большим значением рабочей переменной. Запоминать новое значение в массиве и рабочей переменной.
3) Иметь "специальный" индекс по колонке "Склад" в котором хранится только уникальное значение колонки. Тогда просто просмотреть таблицу по этому индексу.
В "методах" #2 и #3 выполняется количество обращений к таблице равное количеству "динамических колонок"+1. Ну а просмотр таблицы для построения строк с "разносом" "Остатков" по колонкам, с учетом (использованием) массива "имён колонок", по колонкам отчета - не требует никаких хитростей. ;-)
А теперь "изображаем" эти "два цикла" запросами. Считаем (в уме) количество и "качество" обращений к таблице БД. И долго-долго обсуждаем "зубочистку". Но это уже без меня. Для себя я эту тему закрываю, до появления Вашей новой публикации в цикле "Мы пишем з...". Скучно и грустно это обсуждать... :-(
Прочитав пп. 1,2,3 - пожал плечами. Ну , примерно так и реализовано в типовом отчете "Обороты счета" БП 1.6. Суть статьи в том , что интерактивно созданный на СКД отчет обладает большим быстродействием, чем типовой в БП 1.6, содержащий в себе эти п.п 1,2,3.
Этот утверждение автора можно проверить.
... к чему решать "НЕ"существующие проблемы ... всегДА есть 1С 7 ... и другие решения ... для сотен и сотен предприятий 8-ка "ЕСТЬ" ничем не оправданная "расход" и средств и сил ...
... зачем стрелять из пушек по воробЬям ...
... ВОТ ...
п.с.
... есть много и разных решений ... есть 1С ... назовите другие ? ... так хорошо описанные, документированные, и имеющие столько ресурсов в инете ... ??? ..
итог: имеем то что имеем ... ! если чему то научились - пишите и развивайте своЁ ...
... рассуждать о "Запросах" ... в рамках 1С - суть игры - потолок разработчиков 1С (их ограничения) ... ещё раз повторяю - хотите развиваться в "Запросах" в рамках 1С - учите матЧасть "прямых" запросов ... яркий пример Абадонна, появились статьи Че ...
... вот ...
... говорить о преимуществах СКД - смешшно-с ... исходя из математики - система вторичная ( а СКД - есть уже далеко не вторичная по отношение к чистым запросам эСКуэЛь, система) - на порядок затратнее и сложнее ... это проблема всех ПОДсистем ...
... вот ...
...
Я всегда воспринимал СКД как движок, а не как бантик для отчётов. Пользуюсь СКД чисто программно (создаю в коде, набиваю кодом настройку компоновщику, исполняю, сваливаю в коллекции, юзаю хитрые отборы, леплю наборы и т.д.). Мне очень нравятся те возможности СКД, которые касаются чистой "внутренней" работы с данными. Поэтому считаю развитие этой идеи в 8.2 не худшим вариантом.
А я толкую : чтобы только использовать эти методы пользователь должен быть программистом. Владимир , эти споры закончились давно ...
Не припоминаете название дискуссии из 90-х : Бухгалтер или программист ? -суть которой : можно ли придумать такой язык (такие методы), чтобы он был понятен бухгалтеру ? Отголоски той дискусси отчетливо видны в языках продуктов : Бухгалтерия 6.0 и Предприятие 77. Появление Предприятие 8 - окончило те споры - нужен программист , нужен полноценный язык программирования, нужна архитектура клиент-сервер, нужно возвращаться на столбовую дорогу развития СУБД.
Игорь.
Странно, что ставится равенство между "Пользователь" и "Бухгалтер".
Я не участвовал в дискуссии "Бухгалтер или программист ? ". ;-)
Т.к. не могу представить вопрос глупее, чем этот.
Я в (133) написал, что: "Универсальное решение уже давно создано - алгоритмический язык. Всё остальное - частные решения." И очень радует, что современники развития продуктов 1С к этому пришли. На самом деле этот вопрос поднимался очень давно. Просто 1С-ники этого не знали, начиная свою деятельность. Они, вообще, начали с "чистого листа", так как будто до них вообще ничего не было в вычислительной технике.
В своих "мечтах" я написал слово "пользователь" имея ввиду "Вас", а не бухгалтера...
P.S. Про "столбовую дорогу развития СУБД", выше по теме, я дал ссылки. И не для обсуждения доли рынка той или иной СУБД. А для осознания, того, что столбовая дорога уже давно свернула. А Вы и 1С-ы уже давно буксуете в чистому поле. И затрачиваете на это массу своих сил и ЧУЖИХ денег...
Насчет сопоставления языков семерки и восьмерки на полноценность - это уж, простите, профанация. По каким критериям сравнивать? Уж скорее восьмерочный язык ближе к оболочке (пакету, библиотеке) для полупрограммистов, чем в алгоритмическому языку. Чем больше в языке "бантиков", тем дальше он от алгоритмического (собственно, данная публикация - это попытка придать прикладной макроконструкции статус универсального языкового компонента).
Типизация данных - тоже хороший пример. Язык должен, конечнобладать конструкторами составных типов данных. Языку, ориентированному на конкретную предметную область позволительно кроме элементарных типов и правил конструирования/наследования составных типов иметь еще несколько готовых типов/классов. Но иметь три названия для СпискаЗначений из одного элемента (в восьмерке он называется еще Структурой и Соответствием) - явный перебор.
вЫлЫсЫпЫдЫстЫ... © ЧеБуратор
Ты же замахнулся на сравнение (??) "алгоритмичности"(??) 77 и 8 , дескать восьмерочный язык менее похож на "алгоритмический" , а ближе "оболочке","библиотеке". Сама постановка такого вопроса - бессмысленна .
Язык , содержащий алгоритмические конструкции ( а именно "цикл" и "альтернативу")- есть алгоритмический язык. Язык 77 и язык 8 - алгоритмические.
Сравнивать 77 и 8 нужно не по "алгоритмичности" , а по языковым конструкциям , реализующими доступ к данным. И получаем главное отличие - язык запросов.
Всё остальное , в т.ч. "типизация данных" - это мелочи, которые можно обсудить отдельно : зачем нужен "СписокЗначений", что такое "структура" и в чем её отличие от "соответствия". На Чебура в этом вопросе ты сослался - зря.
Впрочем, читая "вЫлЫсЫпЫдЫстЫ... " - каждый думает о чём -то своём.
Ты прав - я сузился , потому что кхе..кхе.. слишком широк . И выделил главную суть в развитии 6.0 - 77 - 8.х. По-моему, дело обстоит именно так :
движение в сторону полноценной платформы для создания СУБД -шных приложений (конфигураций).
Ты же остался "широким" и рассуждаешь вообще что хорошо , что плохо. Про SQL, про перекосы , про геморрой . Что ,согласись, очень и очень спорно.
А ты "сузься" , т.е. абстрагируйся от "геморроя" , и скажи ,не давая оценок :
в чем она суть движения 6.0-77-8.х ?
6-7 Анализ. Разработчики попытались классивицировать учетные задачи - и отделили от бухучета оперативные (оперативный учет) и среднеежемесячные (расчет). Для каждого из получившихся трех видов реализовали специфические учетные регистры и библиотеки для работы с ними. В общем-то с компонентом Расчет они попали впросак, поскольку не хватило у них знаний предмета, что отнюдь нельзя ставить им в вину - в предмете сам Минтруд не очень-то разбирается. Второй косяк, сделанный на этом этапе - неудачная попытка "посмертного автобухучета" на базе оперативного. Тем не менее, попытка была методологически правильной, плохая методология все же лучше, чем отсутствие методологии.
7-8 Синтез. разработчикам в какой-то момент показалось они ухватили суть учета - фиксацию в регистрах, - и отчетности - запросов к регистрам. Попытались с переменным успехом регистры унифицировать. А для этого нужно в регистрах выделить нечто общее, некую объединительную атрибутику. Вот тут внимание! Что общего у этих различных по функциональному назначению и набору регистрируемых данных объектов?
Не получился синтез. Общим оказался (для разработчиков) не кокой-то атрибут, внутренне присущий объектам, а совершенно внешний - способ хранения в реляционной БД. Вот тебе и приоритет запросов. Дальше пошел перевод Скуля на условно-русский язык. И начинающие восьмерочники уже отчет от запроса не отличают.
Следующим шагом должен быть быть повторный анализ. И повторный синтез. Но это уж потом...
Про 7-8 с первого захода ни бельмеса не понял. Чудно как-то ты употребляешь известные мне термины. Пока у меня после каждой фразы в 7-8 стоит мысленный комментарий "ммммм....". Вообщем , пока робею.
После второго захода - отвечу.
Понятно , кроме определения : среднеежемесячный (учет).
Это так ты понимаешь компонент "Расчет" ? Как "среднеежемесячный" ? Может быть компонент "Расчет" определить попроще : как компонент для сложных периодических расчетов , то бишь зарплаты , учет которой тоже, кстати, оперативен .
Попали впросак , кто ? разработчики компонента "Расчет" или разработчики конфигурации "Зик" ? Или те и другие ? "Просак" - на уровне компонента или на уровне конфигурации ?
Это про что ? Про комплексную конфигурацию ? Т.е. разработчики этой конфигурации плохо реализовали посмертный "автобухучет" (внутреннюю выгрузку данных опер.учета в бухучет? Так ?
Александр.
Вы написали: "Общим оказался (для разработчиков) не кокой-то атрибут, внутренне присущий объектам, а совершенно внешний - способ хранения в реляционной БД."(с)
Соглашаясь с Вами, я бы еще к этому добавил, что им было "Известно, что классическая реляционная модель не имеет готовых средств для поддержки иерархии данных и ее реализация всегда требует кропотливой работы."(с)
И вся идея "1С 8.х "пронизана" мыслю: "... предназначенный для решения задач, которые плохо согласуются с классической реляционной моделью базы данных."(с)
Т.е. сделана титаническая попытка реализовать объектную (а по существу - иерархическую) надстройку над реляционной СУБД с ОГРАНИЧЕННЫМ составом "объектов": документ, справочник, регистры...
А т.к. такие надстройки, как правило, работают не эффективно, то пришлось городить сервер "приложений". Который, в основном "прикладывается" ;-) не к потребностям пользователя, а к проблемам надстройки: "Например, при выполнении даже весьма сложных запросов программа, работающая у пользователя, будет получать только необходимую ей выборку, а вся промежуточная обработка будет выполняться на сервере."(с) А по сути - классическая, для SQL-ной "1С 7.7", проблема "универсальных" запросов: "... механизмы платформы ориентированы на минимизацию объема данных, передаваемых на клиентский компьютер. Например, данные списков, табличных частей и отчетов передаются с сервера не сразу, а по мере просмотра их пользователем."(с)
Ссылки на источники цитат:
6-7 - у тебя Анализ. а 7-8 - Синтез.
Эти два метода применяются для построения модели. Какую же модель ты строишь ?
Ответ : Модель платформы 1с в развитии.
У тебя получилось :
6-7 . Здесь ты платформу разделил на три части(компонента) описал их кратенько и назвал это АНАЛИЗОМ. Ты выделил три компонента , потому что для каждого была возможна отдельная поставка.
7-8 Здесь поставка для отдельного компонента невозможна. Здесь всё три компонента в "одном флаконе". Поэтому ты назвал это СИНТЕЗОМ. Объединил , так сказать.
Оказалось , что ты в своем "широком" методологическом подходе попался на маркетинговый трюк 1с : разделил 77 и 8 по признаку возможности раздельной поставки. Ты даже не заметил , что поставка 77 возможна была в "одном флаконе" все три компоненты.
1. Поэтому платформы 77 и 8 нужно сравнивать как единые целые.
2. Поэтому 6-7 - никакой это не Анализ , а 7-8 - никакой это не Синтез и никакую модель развития платформы 1с ты не построил.
Модель развития платформы 1с можно построить лишь сравнивая механизмы двух платформ , анализируя их изменения и появление новых механизмов.
Теперь по содержанию 7-8.
Оно настолько загадочно , что я воздержусь от комментариев.
Еще раз: 1С должна (это миссия) в процессе своей деятельности построить модель учета, т.е. проанализировать учет и синтезировать ПО. В этом суть развития 6-7-8
Игорь.
Спасибо за пояснение.
Для себя делаю вывод, что если язык запросов SQL это ""Вершина" - в смысле достижение"(с) в теме СУБД, то СКД это вершина в учетных системах. А мне казалось, что это тоже самое, что и "...можно ли придумать такой язык (такие методы), чтобы он был понятен бухгалтеру ?"(с), только в другой сфере деятельности.
А суть этих "вершин" хорошо сформулирована в (149):
"Всё идет к этому-формализация манипулирования блоками данных не вдаваясь в детали."(с)
"Только реализовывается пока сложно."(с)
"Когда у процедуры 10 уровней вложенности..."(с)
Мне (дилетанту в хУ) это напоминает рыдания по теме "УУ". :-(
Пора вводить термин "сУУбд". ;-)
P.S. Извините, опять я написал не в тему. Но...
Только реализовывается пока сложно. Когда у процедуры 10 уровней вложенности и каждый уровень начинается с ПолучитьПараметрыУчетнойПолитики(), или когда количество регистров накопления превосходит количество счетов/субсчетов -- это уже не то.
Т.е. СКД занимается , грубо говоря , обратной операцией - "узлованием".
ключевое слово - рекурсия.
вопрос был: сможете ли вы сделать это в СКД, без ручного кодинга, согласно заяве в сабже?
есть метода = суммирование откуда вышли все остальные "минус", "умножение", "деление" ... далее интегрирование, дифференцирование ...
есть механические методы - единица, локоть, шаг, аршин ...
есть логика нуля - "выше/ниже", "тепло/холодно", "плюс/минус" ...
... например "вся математика" компьютерного процессора есть - "сложение" как математический метод и "сдвиг" как механический ... и логика нуля как символ и точка отсчёта ...
... "Запрос" - как язык есть язык декларативный (осведомляющий) - факт свершившийся и не имеющий "логики" ...
... СКД - это сложное, последовательное - уравнение (НеСистемаУравнений) ... т.е. работает с заранее известным набором данных (получаемых "Запросом" см. выше ...)... поэтому нет и не может быть логики ... а попытка наградить нижестоящую систему поведением вышестоящей - кроме путанного хаоса НИКОГДА результата не давала ...
...: "Формулируя закон необходимого разнообразия, У.Р.Эшби указывал, что для обеспечения процесса управления управляющая система должна обладать, по крайней мере, такой же сложностью, как и управляемая. " ...
... ВОТ ...
п.с.0. - для кого хороша СКД - в массе своей для людей не обладающие "логикой" - подобное тенется к подобному ... впрочем для них "этоСКД" и предназначено - пусть кушают ... пусть ... всякое ГМО лишает человека наследственности в 3-7 поколении ... ДОМ-2 одним словом ... ))) ... ПостМодернизм ...
п.с.1. СКД - мертворождЁнный ребёнок ... с ним повозятся и выкинут ...
п.с.2. такое ощущение что сегодняшняя бухгалтерия ничем кроме "отчётов" больше ничем и не занята - ни методикой ни методологией ... ничем ... она полностью села на иглу "от 1С" ...
(155)
... хотя надо сказать что проблемы НЕ линейного программирования (а рекурсия есть всё таки образец и простой способ динамического программирования) к задачам БУ имеет отдалённое приближение... вот ...
... кому интересны практические решения производственных задач и их решения математическими способами могут начать ... по сложнее но зато интереснее ...
...
Вернемся к Мише в (155).
СКД в данной задаче вообще ни к селу , ни к городу.
Но можно вести речь об использовании запроса для решения мишиной задачи.
Мы , т.е. автор темы, ответим Мише узко :
В типовой конфигурации БП 1.6.( Справочник СпецификацииНоменклатуры подчинен справочнику Номенклатура) получить одним запросом плоскую таблицу материалов для номенклатуры ("Электровоз") с расчетом необходимого количества каждого материала - НЕВОЗМОЖНО.
Теперь ответим шире, не привязываясь к типовой конфигурации :
Думаю , использование запроса возможно и эффективно для более простого случая когда дерево-иерархия организовано на одном справочнике, имеющим вид иерархии :"иерархия элементов".
Явное использование рекурсии для получения таблицы материалов здесь НЕНУЖНО.
Достаточно использовать неявную рекурсию в запросе (фразы "ИЕРАРХИЯ", "ТОЛЬКО ИЕРАРХИЯ").
В статье утверждается , что использование СКД даёт резкий прирост производительности при построении сложных отчетов.
Приведен пример : прикрепленный к теме экспериментальный отчет.
Дан образец для сравнения : типовой отчет "Обороты счета" БП 1.6.
Экспериментальный отчет выигрывает у типового от 2 до 5 раз . Читатели могут в этом убедиться .
Ты опровергаешь этот вывод ?
У тебя есть какие -то контрпримеры ?
Или использование СКД при построении отчетов вообще недостойно обсуждения ( для ветерана) ?
... хотите быть "умными" изучайте прямые запросы т.к. сам язык запросов и ширше и хлубше ... а если хотите целлулоид от своей безграмотности и манией величия выраженное в количестве отчётов то пожалуйста - СКД ...
механизм ПостроительОтчёта и его "форма"усовершенствователь Универсальный - был оптимальным вариантом ...
... механизм "расшифровок" - был знаком и раньше ...
... СКД это соединение "Запроса" как доступ к таблицам и "ТЗ" как возможность "свободного" оперирования данными ... такое можно и так делать ... записать такую последовательность в файл - удовольствие мнимое - как и то количество отчётов которое можно делать этим СКД ... мне не понятно зачем делать столько отчётов ... а для реальной жизни - отчёт меняется - "никогда" ...
... вотТакоеСтароПердунскоеМнение ...
....
... просто "скд" мы и раньше сами делали (лично "я" по НЕсовершенству своих знаний ...) ... только зачем это делать в НеДобровольноПринудительном порядке ...
... в целом - нас ВСЁ одно никто не спросит - принимайте и расслабтесь ...
... вообщем я за "ЗА" ! ... ОН такой скд-ешный ...
... ВОТ ...
vs
"СКД в данной задаче вообще ни к селу , ни к городу"
:)
УПП, выход и вход спецификации - в табличных частях.
необходимость: по плану производства - план закупок
особенно, если надо получить горизонтальный разворот с итогами.
Если в простой отчет надо прикрутить заданную печатную форму, выигрыш по времени на разработку снижается.
Если запрос действительно сложен, выигрыша по времени разработки уже практически нет, поскольку основное время - думать над связями таблиц, и тут уж СКД не СКД - не важно.
Если запрос сложный и таблица задана - тогда СКД только если будет выигрыш производительности исполнения.
особенно, если надо получить горизонтальный разворот с итогами.
Давай так :
Хм.. Чему ,собственно, и посвящена эта статья. Сторговались ?
"В 8-ке это ненужно" - показал ведь, рекурсия в спецификациях.
то нужно использовать ADO-соединение.
Фраза, обращенная к Шепоту : "8-ке это ненужно" - означает , что 99% задач в типовых конфигурациях не требуют "прямых запросов".
Можно даже сказать : "Прямые запросы" - это зло ; наследие мрачных "семерочных" времен.
Глянул на структуру справочника "СпецификацииНоменклатуры" в БП 1.6. И думаю , что ты глубоко , жестоко неправ . Я хочу сказать , зря ты пугал здесь народ.
Никакие рекурсии , никакие хранимые процедуры, никакие ADO-соединения для задачи определения плоской таблицы материалов (разузлование) НЕ НУЖНЫ. Всё должно решаться быстро и штатными средствами 1с. Простой цикл с запросом.
Если нестрашно , давай померяемся.
В (155) Миша сформулирал задачу разузлования в общем виде без привязки к конфигурации. Сказал , что в этой задаче ключевое слово - рекурсия.
Раз задача разузлования сформулирована в общем виде , то совершенно логично , что я воспринял её как обычную задачу разузлования для одной таблицы - в БП1.6 именно такой случай.- Справочник НоменклатураСпецификаций. Раскручивая его для какого -то определенного элемента номенклатуры, мы и должны получить таблицу таких материалов(номенклатуры) , которые не имеют спецификаций (т.е. самый нижний уровнень) .
Вот я и считаю, в настоящий момент, что для такой задачи не нужны ни рекурсия , ни что-то другое экзотическое. Предложил в этой задаче Мише померяться этими... ну , умениями.
Подождём .
"Простой цикл с запросом"(с)
Простой цикл БЕЗ запросов. Или рекурсия - для наглядности. ;-)
Кому нужны такие "штатные средства", которые не позволяют, без длительного раздумья и обсуждения "статьями" и "форумами", решать элементарные задачи? Для создания многочисленных отчетов? Остаётся, только, согласиться с Александром:
"такое ощущение что сегодняшняя бухгалтерия ничем кроме "отчётов" больше ничем и не занята - ни методикой ни методологией ... ничем ..."(с) (156) "Шёпот теней"
Дак это уже во многих учетных системах такое. Отдельно прогер приложений, прогер форм, прогер репортов. Все идет к тому. Тут свои плюсы и свои минусы
А вот насчет "Возможность множественных сложных настроек - нисколько не плюс для конечного пользователя.", думаю, наоборот - это плюс для конечного пользователя. Вместо создания кучи отчетов, в СКД сделать возможность различных настроек. Для анализа и прочих вещей очень удобная вещь. Мои пользователи очень легко освоили это дело. Даже простые кладовщицы этим "влет" пользуютя. Другое дело, стандартные отчеты. Бухгалтерские или утвержденные на предприятии. С подписями там или еще чем то. Там можно и "ручное" программирование. Все "предопределено". Но и тут, СКД очень неплохо помогает, например, для быстрого первоначального наброска отчета. А вот "бантики, рюшечки, картинки" уже можно потом добавить.
Аппологетам 7.7 не надо мандражить, грызть ногти и смотреть как уходит все в 8-ку. Бросайте это дело. Попробуте потихонечку изучать 8-ку. И не надо болеть по поводу того, что 8-ка будет "дороже" для фирм.
Автору респект. Очень :D
... освоили "влёт" ... ))) ... уххх ... ох ... ё-маё ...
... только УУ-зооЛОГИ и МИНИджэры переходят с 7-ки на 8-ку ... впрочем если ВАМ совершенно некуда девать ваши денежки - то переход как раз для вас ...
... мандражируют как раз 8-очники ... особенно 8.2 ... хотя 1С облегчили задачу перехода - очередным "клажением" на всех ... они не знают как обосоновать - ВСЁ стало дороже а эффекта никакого ... а у 7-ников - всё не просто а очень просто ... !
... вотЕстьМнение ...
Скажу только одно. Переход на 8-ку оказался очень даже производительным и незатратным для бизнеса. В принципе, не "у 7-ников - всё не просто а очень просто ... ! ", а у пользователей. Я работал и на 7.7. На 8-ке для программера все проще. Кто перешел на 8-ку уже не имеет желания на 7.7 возвращаться. Это о чем то говорит. И не надо про "привыкание". Как раз, привычка многих держит на 7.7
Ну попробуй, хотя бы чуток, поработать на конфах 8-ки.
Обсуждаем вопрос как создать обработку для разузлования номенклатуры .
В обработке требуется задать номенклатуру, на выходе получить таблицу материалов нижнего уровня.(Колонки в выходной таблице : Номенклатура,Количество)
Разумные ограничения :
У каждой номенклатуры не более одной спецификации.
В выходной таблице не более 1 000 000 записей-материалов (для "электровоза" хватит)
Уровней вложенностей не более 100.
Ты представляешь свою обработку с РЕКУРСИЕЙ - я свою С ЦИКЛОМ . Вот и померяемся . Как ?
Реально вложенность 20 - очень большая спецификация
Материалов - 100 000 - тоже с запасом
И, реально же, одна спецификация у номенклатуры выделяется регистром сведений ОсновныеСпецификацииНоменклатуры. Но это уже - УПП.
зы: "Итерация от человека. Рекурсия — от Бога."
Дональд Кнут Искусство программирования, том 1. Основные алгоритмы = The Art of Computer Programming, vol.1. Fundamental Algorithms. — 3-е изд. — М.: «Вильямс», 2006. — С. 720. — ISBN 0-201-89683-4
1. Условия ( 20 и 100 000) твои принимаются.
2. Регистр для определения спецификации не учитывается ( будет только одна спецификация у номенклатуры.
3. Используется Демонстрационная БП 1.6.
Для тестового заполнения Справочников Номенклатура и Спецификации Номенклатуры
Чего нибудь каждый напишет.
Ну так как ? Меряемся ?
Тему "Рекурсия против Цикла" открываешь ?
Фраза ремесленника :
"Итерация от человека. Рекурсия — от Бога"
тонет в изречении математика :
Натуральный ряд чисел создал Бог, все остальное - придумали люди.(с) Кронекер
Мой-то идол покруче твоего будет !
дерево из реляций вытаскивается рекурсией.
в 1сном "языке запросов" рекурсии, которая появилась в MSSQL с 2005 - нет, соответственно, и СКД здесь против "ручного" кодинга не может ничего.
Об этом и шла речь.
А рекурсия против цикла - это твоя собственная выдумка, бой с тенью. Удачи, пусть победит сильнейший.
Получается , что в этой конфигурации нет проверки на "зацикленность" при заполнении справочника "СпецификацииНоменклатуры"? И пользователи вводят в этот справочник что хотят ?
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 75878
Создание 28.09.10 09:01
Обновление 14.10.10 08:52
Просмотры 33093
Загрузки 267
Рейтинг
61
Комментарии 189
Код открыт Не указано
Рубрики Работа с интерфейсом
Кому Разработчик
Тип файла Внешний отчет (ert,erf)
Платформа 1С:Предприятие 8
Конфигурация 1С:Бухгалтерия 2.0
Операционная система Не имеет значения
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)