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

[belugin]

Теперь вопрос, допустим, вы переименовали поле или перенесли в другую таблицу. Как вы убедитесь, что вы изменили все связанные текстовые запросы - в Ax с Query это делает компилятор.

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

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

[Сисой]

Я использовал несколько раз СКД для управления параметрическими запросами вне задачи получения отчетности. Навскидку напомню об универсальных обработках для работы с разными объектами. Но у СКД есть один минус: хотя источников данных может быть много (в т.ч. и несвязанных между собой), тексты запросов с именами таблиц (предложение From ) все равно хранятся в текстовом виде и их нужно парсить.

[Reaper]

Цитата:

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

Теперь вопрос, допустим, вы переименовали поле или перенесли в другую таблицу. Как вы убедитесь, что вы изменили все связанные текстовые запросы - в Ax с Query это делает компилятор.

Модификации запросов обычно делаются в IDE - изменил что-то и изменения пошли во всей структуре загруженной в IDE.

Цитата:

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

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

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

Это да, скажу больше - для меня этот язык и есть основной. Весь же остальной язык использую очень мало.

Цитата:

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

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

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

[Reaper]

Цитата:

Сообщение от Сисой

Я использовал несколько раз СКД для управления параметрическими запросами вне задачи получения отчетности. Навскидку напомню об универсальных обработках для работы с разными объектами. Но у СКД есть один минус: хотя источников данных может быть много (в т.ч. и несвязанных между собой), тексты запросов с именами таблиц (предложение From ) все равно хранятся в текстовом виде и их нужно парсить.

Источником данных для СКД могут быть и непосредственно объекты. И описать их взаимодействие можно кодом, без вызова IDE вовсе. Вопрос только зачем?

[mazzy]

Цитата:

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

Вопрос только зачем?

Упорно напоминаю нечитателям из-за чего возобновился сыр-бор в этой ветке:

Цитата:

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

Мдя... Некоторые 1Сники задаются вопросом: v8: В чем смысл такого кода

И в самом деле, зачем 1Сники пишут ТАКОЙ код?

[sukhanchik]

Цитата:

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

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

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

[Reaper]

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

[gl00mie]

Это все, конечно, идеологически верно, но тема - про технологические возможности платформы. Так вот, одной из особенностей представления запросов в Аксапте в виде связанных объектов (с учетом таких возможностей, как relation'ы на расширенных типах данных и перекрестные ссылки) является то, что пользователь может самостоятельно изменить используемый запрос, в частности, добавить в него связанные datasource'ы и осуществлять фильтрацию и сортировку по их полям.


За счет этого пользователи практически на любой форме/отчете/"обработке" могут тонко настроить используемый в дальнейшем запрос без помощи разработчика.

[Reaper]

Теперь мы тоже можем так:


И это все та же Система Компоновки Данных

[mazzy]

Цитата:

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

Теперь мы тоже можем так:

А первый рисунок повторить?
кроме того, в критериях на втором рисунке можно указывать выражения http://axapta.mazzy.ru/lib/search/

[Reaper]

1. Вида связи 1:n нет как такового.
2. Критерии выбираются только из фиксированного списка

Встречные вопросы:
1. Механизмы AX дают пользователю превратить плоский список в дерево по произвольным полям?

2. На предыдущем рисунке зеленым подсвечено поле "сумма" - это условное оформление, которое позволяет управлять отображением произвольного поля (цвета фона, текста, шрифт, содержание) в зависимости от описанного пользователем критерия. AX имеет аналог?

[Сисой]

Цитата:

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

А первый рисунок повторить?
кроме того, в критериях на втором рисунке можно указывать выражения http://axapta.mazzy.ru/lib/search/

К сожалению, в базовых отборах гридов 1С даже базовые шаблоны LIKE недоступны. Максимум - возможен поиск подстроки ("Содержит").
В качестве альтернативы 1С предоставляет механизм полнотекстового поиска, существенно превосходящий язык выражений Ax по возможностям:
Полнотекстовый поиск в 1С.

[mazzy]

Цитата:

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

Встречные вопросы:
1. Механизмы AX дают пользователю превратить плоский список в дерево по произвольным полям?

В дерево - да.

Но лучше его не использовать из-за потенциальных тормозов иерархического представления данных из реляционной базы (ищите на форуме, обсуждалось неоднократно). А также из-за принципиальных проблем с поиском и фильтрацией внутри дерева (тоже обсуждалось).

По произвольным полям - ни в коем случае нет. Что ж производительностью то будет, если пользователь будет дерево строить по произвольным полям? Да еще по таким, по которым индексов нет... Тут хочется отключить даже сортировку по произвольным полям. А вы дерево предлагаете...

Цитата:

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

2. На предыдущем рисунке зеленым подсвечено поле "сумма" - это условное оформление, которое позволяет управлять отображением произвольного поля (цвета фона, текста, шрифт, содержание) в зависимости от описанного пользователем критерия. AX имеет аналог?

нет, настройки нет.
только программированием.
и только на уровне строки грида.

[Reaper]

Э, нет, Сисой, так не честно. Полнотекстовому поиску 1С нельзя задать область поиска, так что по выражениям в критериях мы терпим фиаско. И опрос о востребованности тоже поднимать смысла нет - возможности обсуждаем, а не применение их.

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

[ibc]

В 1С СКД невозможно писать динамические запросы и/или динамически указывать источники данных! То есть все имена в СКД прописываются статично. Невозможно указать к примеру так
Поле запроса №45 должно браться из переменной ПолеХ или формироваться по формуле (Формула), если Поле Запроса №23 соответствует условию (Условие) - Это минус СКД.
В Х++ для этого нужно писать код, мышкой такое условие, как я понял то же не задать в настройках! Или я ошибаюсь?

[Reaper]

Цитата:

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

В 1С СКД невозможно писать динамические запросы и/или динамически указывать источники данных! То есть все имена в СКД прописываются статично. Невозможно указать к примеру так
Поле запроса №45 должно браться из переменной ПолеХ или формироваться по формуле (Формула), если Поле Запроса №23 соответствует условию (Условие) - Это минус СКД.

Вы неправы, уважаемый. Извиняюсь за много букв, но

		. ="ВЫБРАТЬ
		                                 |	Номенклатура.Ссылка,
		                                 |	Номенклатура.Наименование,
		                                 |	0 КАК ПорядокСортировки
		                                 |ИЗ
		                                 |	Справочник.Номенклатура КАК Номенклатура
		                                 |ГДЕ
		                                 |	Номенклатура.Наименование ПОДОБНО &ПерваяСтрокаПоиска"; 
		
		..("ПерваяСтрокаПоиска", "");

Данный кусок кода прямо в ходе с работы с формой переназначает запрос - источник данных динамического списка на форме.

[mazzy]

Цитата:

Сообщение от Сисой

В качестве альтернативы 1С предоставляет механизм полнотекстового поиска, существенно превосходящий язык выражений Ax по возможностям:
Полнотекстовый поиск в 1С.

это не альтернатива. это совсем другой инструмент.

(пока запускаю аксапту и готовлю скриншот, уже опередили)

Цитата:

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

Полнотекстовому поиску 1С нельзя задать область поиска

именно так.

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

Ну, и конечно надо признать, что полнотекстовый поиск на русском языке в 1С реализован намного лучше. Тут они молодцы. Майкрософт не занималась разноячными правилами поиска, в Аксапте ищется на всех языках одинаково.

(щас скриншот таки сделаю)

добавлено:
можно я все-таки не буду дожидаться окончания индексации в русской базе?
вот скриншот из международной демобазы.
в категории попадает таблицы, в которых Аксапта нашла записи

[gl00mie]

Цитата:

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

На предыдущем рисунке зеленым подсвечено поле "сумма" - это условное оформление, которое позволяет управлять отображением произвольного поля (цвета фона, текста, шрифт, содержание) в зависимости от описанного пользователем критерия. AX имеет аналог?

В AX есть возможность "расцвечивать" строки и/или отдельные поля, но только за счет написания соотв. кода. Аналога "условного форматирования" на основе пользовательских критериев нет, но это, извините, какая-то фильтрация для бедных. Если мне надо будет видеть строки с суммами от сих до сих или больше скольки-то, то я просто задам это условие в фильтре и увижу лишь нужные мне строки, а не буду листать хрендцать экранов, выискивая зеленый фон у полей сумм.

PS. Когда от "светофоров" есть реальная польза, они обычно рисуются по более сложным алгоритмам, чем банальное сравнение, и за счет других инструментов - это скорее область Business Intelligence.

[belugin]

Цитата:

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

Если мне надо будет видеть строки с суммами от сих до сих или больше скольки-то, то я просто задам это условие в фильтре и увижу лишь нужные мне строки, а не буду листать хрендцать экранов, выискивая зеленый фон у полей сумм.

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

[Сисой]

Цитата:

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

Когда от "светофоров" есть реальная пользова, они обычно рисуются по более сложным алгоритмам, чем банальное сравнение, и за счет других инструментов - это скорее облать Business Intelligence.

Привожу пример полезного светофора: расцветка строк по статусам заказов, если разработчик не удосужился задать расцветку или обеспечить механизм ее настройки под юзера.