v8: В чем смысл СКД? #391594

Возьмём простую торговую организацию. Скажем с УТ. СКД не было. И тут вдруг появилась. Что изменится?

Возьмём простую торговую организацию. Скажем с УТ. СКД не было. И тут вдруг появилась. Что изменится?

СКД = Сразу Как Долбанет! ;)))

смысл быстро забацать простой отчетик.

смысл быстро забацать сложный отчетик, простой и раньше легко было забацать

Доступно и всерьез (с)

смысл быстро забацать отчетик. а где логика?

забацать отчетик меньшим количеством научных тыков.

быстро забацать простой отчет

смысл в том, что это система компоновки данных - компонуй и используй, насколько мозга хватает. У меня, например, была задача в УТ такая, что никакой построитель не помог бы решить, только СКД.

изменится для кого? Сначала было построитель отчета. Штука хорошая, но - все ручками. Потом появилась надстройка Универсальный отчет - внешний тюнинг к построителю. Быстро делать красивые отчеты стало намного легче. СКД - это следующая ступень эволюции построителя. Теперь возможности "сделать быстро и красиво" заложены в платформу. Для пользователей - отчеты станут красивее и функциональнее. Для программистов - отчеты станет писать намного легче. А ты вообще к чему спрашиваешь?

А что имеется в виду под "все ручками".

Что имеется в виду под "сложными отчетами"? В основе отчета в СКД лежит запрос? Или же что-то другое? Почему спрашиваю - делаю всё на построителе отчета, много слышал про СКД и подумалось мне - не упускаю ли чего? Ступеньку же "универсальный отчет" я вообще пропустил.

можно озвучить задачу в УТ которую построителем не решить, а вот СКД сработала на отлично?

тоже пользуюсь построителем, см

руки кривые, или построителем пользоваться не может

Темой навеяло... SQL ведь изначально тоже задумывался как простое (для пользователя) средство доступа к базам данных.

Смысл в том, что чем сложнее реализация задачи, тем быстрее и проще её выполнить построителем и наоборот.

Если в основе СКД лежит запрос - то в построителе можно наваять что угодно. Зачем СКД? Можно конкретные примеры? На мой взгляд, наиболее гибкое решение - это конструктор выходной формы - для пользователя. "унивесальный отчет" это и есть такой конструктор, только в режиме предприятия?

Спрошу так - в СКД возможны корреляционные подзапросы? Каким-нибудь волшебным образом? Какой-нибудь расширенный функционал sql?

Вопрос сродни "в чем смысл мерседеса, если есть жигули???".

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

начинается....

смысл в том что большинство организаций - без грамотные... и самодурствующие...

я думаю, не сложнее чем в построителе.

сам виноват. надо было в сабже так и писать - Чем отличается построитель от СКД. а то прикинулся валенком...

Вот удивительно - об СКД столько разговоров, но внятно сказать - ЗАЧЕМ это нужно и чем отличается от построителя - никто не в состоянии.

группировки удобно делать - это раз.

не хочешь мерседеса - езди на жигулях. Цель "доставить из А в Б" они обе выполняют. Только на мерсе быстрее и с комфортом.

визуальных настроек больше - это два.

Если прочтешь книжку по СКД - вопросов чем отличается от построителя не возникнет

Если не секрет что за книга?

отчет СКД написанный в 8.1 работает в 8.2 через WEB без переконфигурирования

Книга есть, спецовая по СКД - у франчей есть. И у меня даже тоже.

задача? вот вам задача: типовая УТ. Торговля компами. У док. "Заказ покупателя" появилась ссылка на док. "Опрос". Нужен отчет, представляющий анализ спроса и некоторых внешних факторов (ответы Опроса). Основные Показатели - суммы и проценты "продаж", кол-во опросов и процент соответственно. При этом в одной колонке - сумма продаж отдельно компов, а в другой - отдельно другие железки (не входящие в комп). Железки желательно отобразить в иерархии. Поля группировок - Ответственный, Ответ, Док, Номенклатура. Внимание фишка: сумма компов документа не имеет смысла в строках с номенклатурой, иными словами должна быть только в итогах группировок. А вычисляется она как сумма стоимости комплектух. Будет решение в рамках построителя не сложнее пары запросов и пары галочек грамотных, напишите в личку ;)

+ Построитель для лохов, а конкретные патцаны юзают СКД ?)

Смысл СКД в том, что написано в доке. А орать вовсе необязательно.

+1

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

Орешь ты, когда в заголовке темы все пишешь заглавными буквами

Вывод номера по порядку

Нет. Язык запросов в СКД такой же.

смысл СКД познают пользователи, которые посредством "этого" СКД из "примитивной" 1с получают набор нужной отчетности не привлекая к каждой мелочи программиста. причем пользователям уровня "бухгалтер" и "менеджер" даже счеты ненужны, они работают исходя из один_раз_показанного алгоритма и на все остальное им плевать, а вот какие либо экономисты/финансисты и прочие комм.директора очень, очень любят "это" СКД

решение есть коммерческая тайна уже. Могу "намекнуть" основную идею: вычисление итогов только по указанным группировкам и условное оформление.

да ради Бога. Коммерческая тайна какая-то, намеки... Мне-то это зачем?

В построителе нельзя использовать внешнюю ТЗ в качестве источника данных. Это хотя бы.

Можно

Можно, но только 1.

не знаю, зачем. Сам просил задачу.

, Неудачно выразился. Использовать внешнюю ТЗ в запросе.

Какая-то абсолютно флеймовая ветка... Когда у нормального прога возникает вопрос, зачем нужен тот или иной инструмент, он изучает доку и получает ответ. А не самовыражается на форуме в ключе "а докажите, что оно мне надо и может быть я буду им пользоваться". И это при том, что книга по СКД у него лежит...

Я ждал тебя, фишер. В чем проблема? Изучи доку, получи ответ и расскажи здесь.

2 Приятно, блин :) Идея СКД, если в самом деле интересно - ПОЛНОСТЬЮ ПАРАМЕТРИЧЕСКОЕ (в идеале) описание отчетов (программистом описываются только источники данных). Чувствуете разницу хотя бы по сравнению с созданием отчета с помощью мастера? Вы можете сказать, а нафига? Можно ведь прекрасно жить и без этого? Можно. Живите.

Но какая же должна быть квалификация пользователей для собирания таких отчетов? Особенно, если пользователь пришел с 7.7

когда у пользователя НЕТ желания работать то ему СКД естественно не нужна.. а вот если пользователю действительно НУЖНО работать - СКД ему очень, очень пригождается..

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

Это всего лишь основная концепция. Использовать её можно как угодно. Можно только для облегчения труда программиста. Можно полностью давать конструирование отчета пользователю на откуп. Можно предоставлять пользователю ограниченное воздействие на настройки отчета (типа как в построителе отчета), реализовывать альтернативный доступ пользователя к настройкам СКД. Это уже частности. Как уже было упомянуто, данная концепция кроме всего прочего позволила в 8.2 очень гибко учитывать права пользователя при формировании отчета и перенести формирование отчета полностью на сервер (с возможностью динамического распределения нагрузки при его формировании). Фишка в том, что "обычный" отчет является для системы черным ящиком, в то время как отчет СКД для неё - открытая книга. Соответственно система может его анализировать, оптимизировать его выполнение, распараллеливать вычисления и сколь угодно тонко влиять на его формирование. В полной мере эти возможности реализуются уже в 8.2

СКД нужна чтобы заманить кажущейся лёгкостью, поработить мозг 1Снеков, в нужный момент этот чёрный ящик не сработает и все они окажутся в аду

забыл демонический смех

Кроме шуток. Вещь конечно, отличная, но совершенно не предсказуемая. Возможно, следует заранее сказать заказчику, что вы выбираете перспективную технолонию, но некоторые вещи сделать может оказаться невозможно. (непредсказуемо долго). Можно упереться в сущуй пустяк и потерять на нём долгие недели Впрочем построителю это тоже свойственно. А ручной вывод не так плох как кажется. Он не тот что прежде уже - есть временные таблицы

Вдогонку. Можно провести аналогии между СКД и языками декларативного описания результата (тот же SQL, например). Вы говорите системе ЧТО вы хотите получить. А КАК ИМЕННО это получить - она решает сама. Прогрессивность такого подхода очевидна: разработка и сопровождение упрощаются, многие моменты становится возможным унифицировать и оптимизировать на уровне системы.

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

А кому щас легко :) Главное, что есть из чего выбирать. Хошь СКД, хошь построитель, хошь каждую ячейку любовно оформляй и печатай.

"совершенно не предсказуемая" - это как? При одинаковых условиях получаются разные результаты? Можно пример?

Исчезает возможность отладки чего ? Результирующий запрос получить не проблема - а в остальном вроде отлаживать и нечего.

У СКД перед построителем есть одно большое преимущество: СКД - это развивающаяся система, построитель - мертвая ветвь. "Результирующий запрос получить не проблема"   -  Ооо, можно узнать как?

"СборкаУсловия"  - 8.2?  прогресс однако.

Нет. Это просто имя источника данных в моей схеме.

+ Получаешь на выходе запрос собранный уже вместе с отборами и с учетом использованных настроек (к примеру отсекаются неиспользованные группировки). Параметры отборов запроса компоновка засовывает в набор своих же параметров с именами PХ где Х - число от 1 и дальше.

а я то, наивный.

нет, нет в СКД смысла. Им пользуются одни лузеры и лентяи. настоящие спецы отчет пишут три дня в блокноте (в том числе и запросы) а потом под требования пользователей пишут по три дня новые отчеты (даже если нужно просто оформление сделать или группировки сменить) никогда и низачто не изучайте и не пользуйтесь ЭТИМ СКД. навеяно: "Смотрю, как студенты понтуются, кто из них больше ни фига не делал и всё сдал. Эх... Когда я был студентом, я сдавал право одной очень милой женщине. Она была практикующим юристом, и я ожидал, что такой специалист меня сейчас будет гонять от и до по всему конспекту. Она посмотрела на меня и, ничего не спрашивая, поинтересовалась: - Оценку вам какую ставить? - Э... Пять хотелось бы - Отлично, - сказала она, и стала писать в зачётке - А вы что, даже ничего спрашивать не будете? - удивился я. Она оторвалась от заполнения зачётки, внимательно посмотрела на меня и сказала: - Запомните, молодой человек, чем меньше вы знаете, тем более ценна я как специалист. Эта фраза мне запомнилась на всю жизнь и больше я не страдал фигнёй во время занятий. И сейчас самое время мне, уже доценту и одновременно практикующему проектировщику зданий, повторить то же самое: Господа студенты, не учитесь, пожалуйста! Старайтесь как можно больше получить на халяву! Чем меньше вы знаете по окончании института, тем более ценен я как специалист и тем большую зарплату я могу потребовать за свои услуги!" (с) баш

Как?

Это почему же построитель - мертвая вещь?

+ А, не видел :))

потому что достиг вершины своего развития.

Скажите пожалуйста как называется книга по СКД? И может где-то ее можно скачать? Киньте ссылку(и), если есть!

Сразу разочарую в ней по существо ничего и нет кроме картинок. Посмотри лучше вдокументации к платформе, там более менее нормальное описание

Да ладно. Отличная книга для быстрого старта.

Вот книга. По ней изучить СКД легко и просто

Исчезает возможность отладки чего ? Результирующий запрос получить не проблема - а в остальном вроде отлаживать и нечего. Оооо. Это есть совсем не правда. Отлаживать там очень и очень есть чего. Т.к. в развитой компоновке будет не один запрос, а несколько разных, которые будут затем обрабатываться кучей разных выражений в выражении представления, выражении сортировки, выражения пользовательского поля, выражении в макете, всё это может осложняться вложенными компоновками... всё это дерьмище всё равно не может вывести так как нужно и сопровождается кучей гавнакода, который ходит по результирующией таблице заранее неизвестной структуры, цепляясь за знакомые куски текста в ячейках и пытаясь переформатировать это всё в конце концов как надо. Итого - сложная компоновка вполне может быть АДОМ

Но особая прелесть во всём этом - это диагностические сообщения. Которые иногда могут быть такими: "ошибка в компоновке данных"

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

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

Здесь есть и обратная сторона ;-) См

Ну, во первых книги по СКД у меня как не удивительно не оказалось. Странно, мне казалось, что я её покупал. Во вторых - насколько я понял - первое же супер преимущество СКД перед построителем - это то, что запрос формируется в конце, а не в начале. У меня характеристики номенклатуры и контрагентов хранятся в РС. В построителе - придется забирать их в запросе, даже если они потом и не будут нужны - пипец. А тут - если они не используются - в запросе не участвуют - это нереально круто. Просто не передать как круто. Иначе текст запроса пришось бы составлять по кускам и прочая маета. Мне нравится.

В конце чего запрос формируется?

В конце сборки макета (до получения данных)

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

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

Вон в УТ отчеты сначала были статичными, потом стало де-факто стандартом возможность переставлять группировки, а теперь СКД. Эволюция, блин.

самая типичная проблема - уберите или добавьте мне поле, я хочу, чтобы группировалось сначала по А, потом по Б, а не наоборот

А в построителе-то переставлять группировки в чем проблема??

+ Не в построителе, а в отчетах на его основе. Там тоже самое.

Я обычно делал 2 построителя отчета. Один - для интерфейса, а другой - для выполнения. В зависимости от настроек пользователя, формировал оптимизированный текст запроса второго построителя, еще с некоторыми фишечками:))

Ну мы ж тут про быстроту и простоту говорим...

Тоже так делал ... в схеме ничего не мешает делать также - только необходимость в подобном реже возникает.

В УТ СКД уже задействовано? Хочется взглянуть что это за зверь.... Че то я упустил момент:))

Тут уже говорили, большое преймущество СКД в развитии. Насколько я понимаю, ближайшем шагом будет возможность добавлять в источники данных внешние базы (скорее всего это будет что-то вроде ADO). А ещё можно почитать книжку, о которой тут тоже говорили, там есть глава "Отличия..." и не задавать глупых вопросов. А ещё, чисто субъективно, в СКД писать отчеты - одно удовольствие!