В принципе, по технологическим возможностям платформа 1С сильно приблизилась к Аксапте

[lev]

Цитата:

Сообщение от ibc

А любые запросы в т. ч. вложенные запросы таким же образом можно сделать?

(select b1,b2 from (select * from Tab1))

любые запросы, любой сложности

[Reaper]

Не утерпел господа, зарегистрировался. Больно жарко у вас тут, чуть-чуть ясности: аналог класса Query() в 1С - это пресловутый УниверсальныйОтчет из типовых конфигураций (прикладных решений) 1С: передаем ему объект - источник данных и описываем структуру выбираемых полей, условий и прочих радостей. Правда исполнение этого отчета конечно-же куда как топорнее представленного примера.

А в 195-м посте вопрос был о средствах визуального конструирования запроса. Т.е. написания запроса в DAX при помощи мыши, без использования клавиатуры . И ответ непосвщенному 1Снику интересен весьма.

[gl00mie]

Цитата:

Сообщение от Reaper

в 195-м посте вопрос был о средствах визуального конструирования запроса. Т.е. написания запроса в DAX при помощи мыши, без использования клавиатуры . И ответ непосвщенному 1Снику интересен весьма.

Ответ на этот вопрос можно найти в узле AOT\Queries:

[Reaper]

Собственно 1С любую текстовую болванку запроса открывает в виде:

[mazzy]

Цитата:

Сообщение от Reaper

Собственно 1С любую текстовую болванку запроса

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

[mazzy]

Цитата:

Сообщение от Reaper

аналог класса Query() в 1С - это пресловутый УниверсальныйОтчет

Нет, конечно. И это тоже уже обсуждалось пару раз.

прежде всего, "пресловутый УниверсальныйОтчет" возвращает данные в виде таблицы для печати, в ячейках таблицы хранятся строки (таблицы абсолютно неприспособлена для дальнейшей обработки программистом)
а Query возвращает данные в виде записей таблиц, которые предназначены прежде всего для программиста.

потом вы правильно сказали - в 1С передаем объект. а как этот объект создать/построить - головная боль программиста.
А query - это как раз и есть этот объект, который строится программным образом (или рисуется в AOT мышкой). Результатом работы с Query как раз и является текстовая строка.

и так далее...
поищите. в 1С нет аналога Query.

[ibc]

В 1С нельзя просмотреть структуру вложенных запросов в виде дерева, как в аксапте, только текущий слой в конструкторе запросов!
В 1С сам запрос храниться в виде текстовой строки, которую конструктор парсит при открытии, а в аксапте запрос хранится в виде структурного дерева, а не текстовой строки!
К аксаптовскому запросу можно обратиться, как к узлам этого дерева, а к 1С-кому запросу, как к строке.

P/S Из, того, что мне удалось понять про аксапту!

[Reaper]

Я из универсального отчета добьюсь возврата вменяемого результата, а не таблицы для печати, да и делается это просто. Проблема не в этом.

Как я понимаю из скриншота - DAX хранит в себе не запрос, а описание запроса (может даже в xml но этот факт виднее вам). 1С же принципиально не реализует такого подхода и парсит конструктором текст (из-за чего конструктор частенько лажает, чем бесит). И обусловлено это на мой взгляд маркетинговой политикой 1С. Если реализовывать аналог DAX - для того чтобы получить текст запроса для анализа нужно будет запускать отладку. В таком случае мне будет уже проще запустить среду СУБД, отловить запрос уже там и анализировать его там же. Для 1С такая методика борьбы за производительность неприемлема ввиду того, что они декларируют абстрагирование разработчика от физической БД. Да к тому же тогда лесом пойдет их центр управления производительностью. Существующий же подход позволяет среднестатистическому специалисту не понимать работы СУБД и не прикасаться к ней, а опираться в работе исключительно на отладчик и ЦУП.

Могу ли узнать, как в визуальном конструкторе запроса DAX указать состав полей динамическим в зависимости от внешних условий?

[sukhanchik]

Цитата:

Сообщение от Reaper

Для 1С такая методика борьбы за производительность неприемлема ввиду того, что они декларируют абстрагирование разработчика от физической БД. Да к тому же тогда лесом пойдет их центр управления производительностью. Существующий же подход позволяет среднестатистическому специалисту не понимать работы СУБД и не прикасаться к ней, а опираться в работе исключительно на отладчик и ЦУП.

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

[belugin]

>>Могу ли узнать, как в визуальном конструкторе запроса DAX указать состав полей динамическим в зависимости от внешних условий?

Можно:
1. Программно добавить поля в запрос, сконструированный ранее из IDE
2. Предоставить пользователю диалог, в котором он добавит условия, сортировки и соединения с другими таблицами

[belugin]

Цитата:

Как я понимаю из скриншота - DAX хранит в себе не запрос, а описание запроса (может даже в xml но этот факт виднее вам). 1С же принципиально не реализует такого подхода и парсит конструктором текст (из-за чего конструктор частенько лажает, чем бесит). И обусловлено это на мой взгляд маркетинговой политикой 1С. Если реализовывать аналог DAX - для того чтобы получить текст запроса для анализа нужно будет запускать отладку.

Получить текст запроса на X++ можно наведя курсор на источник данных запроса
Чтобы получить код на TSQL надо восполлзоваться аксаптовским трассировщиком или написать спецтул, который будет включать трассировщик запускать запрос и выводить результат трассировки.

[Reaper]

Спасибо. Таким образом отличие свелось к наличию класса-обертки. Без отличия методики: в обеих системах запрос делаем через IDE, в обеих системах дорабатываем полученный от IDE результат кодом.

[mazzy]

Цитата:

Сообщение от Reaper

Я из универсального отчета добьюсь возврата вменяемого результата, а не таблицы для печати, да и делается это просто. Проблема не в этом.

Ну, ну

Цитата:

Сообщение от Reaper

Как я понимаю из скриншота - DAX хранит в себе не запрос, а описание запроса (может даже в xml но этот факт виднее вам). 1С же принципиально не реализует такого подхода и парсит конструктором текст

То, что 1С парсит - это ее проблемы.
Главное отличие в том, что программисту отчет нужно парсить, чтобы изменить параметры, добавить условия и пр.
Именно из-за того, что ПРОГРАММИСТУ нужно парсить, и появляются такие безумные технологии

Цитата:

Сообщение от Reaper

И обусловлено это на мой взгляд маркетинговой политикой 1С.

Конечно. Верю. С 2001 года, как появилась "восьмерка", верю.

Цитата:

Сообщение от Reaper

Если реализовывать аналог DAX - для того чтобы получить текст запроса для анализа нужно будет запускать отладку.

Это в 1Се так. В Аксапте можно просто повисеть мышкой над запросом. И не забываем про метод toString()

Цитата:

Сообщение от Reaper

В таком случае мне будет уже проще запустить среду СУБД, отловить запрос уже там и анализировать его там же.

Ха-ха-ха.
В 1Се может быть действительно это и "проще".

Цитата:

Сообщение от Reaper

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

Угу. Неприемлема, так неприемлема.

Цитата:

Сообщение от Reaper

Спасибо. Таким образом отличие свелось к наличию класса-обертки. Без отличия методики: в обеих системах запрос делаем через IDE, в обеих системах дорабатываем полученный от IDE результат кодом.

Ха-ха-ха...
Конечно же нет. Разница проявляется в том как "дорабатываем".
В Аксапте программист вызывает метод, который коректно изменяет запрос.
В 1Се программист парсит строку и заменяет подстроки безо всякого синтаксического и семантического контроля.
Действительно, никакой разницы

Как заявил Сисой в начале ветки "В принципе, по технологическим возможностям платформа 1С сильно приблизилась к Аксапте"
Угу-угу. Верю.

[belugin]

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

[Reaper]

В терминах 1С это Система Компоновки Данных. Вот только если начать их сравнивать через форум - умрем. Больно уж там функционала много навешено.

[mazzy]

Цитата:

Сообщение от Reaper

В терминах 1С это Система Компоновки Данных. Вот только если начать их сравнивать через форум - умрем. Больно уж там функционала много навешено.

- А много-ль корова дает молока?
- Не выдоишь за день, устанет рука!


...У нас есть такие приборы,
но мы вам о них не расскажем...

[Reaper]

Честно - вот ну не понимаю, чем не угодило текстовое представление запроса. Или на уровне восприятия работа с классом приятнее? Чем работа с классом облегчит понимание чужого кода? Ну буду я парсить код работы с классом, а не сам запрос - в чем разница?

[mazzy]

Цитата:

Сообщение от Reaper

Ну буду я парсить код работы с классом, а не сам запрос - в чем разница?

Парсить код?
мдя...

читайте здесь

Цитата:

Сообщение от mazzy

и задать, и открыть, и настроить, и использовать потом его в коде, и менять из кода.

сортировка в запросе
сортировка в запросе
сортировка в запросе

вот еще Отображение AOT_Query на форме часть 2
и так далее по ключевым словам querystr и findOrCreateRange*

ЕЩЕ РАЗ: ищите по ключевым словам querystr и findOrCreateRange*

[Reaper]

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

[mazzy]

Цитата:

Сообщение от Reaper

Ни разу не использовал вне получения отчетов за отсутствием необходимости.