EDT как Array

[Владимир Максимов]

Цитата:

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

Всего то хотел чтобы таблица не разбухала при увеличении списка параметров.

Не понимаю, каким образом использование Array позволит решить эту задачу? Физически ведь это по прежнему будет несколько отдельных полей.

Использование определенных типов данных лишь косвенно влияет на размер таблицы. Да и то, в очень специфических ситуациях.

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

[KingPeas]

Цитата:

Сообщение от Владимир Максимов

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

Попытаюсь объяснить зачем все затевалось. Работаю с ReportingServices в аксапте. Представьте есть отчет содержащий 15 параметров. Каждый месяц формируется около 100 видов этого отчета с разными вариантами параметров. На стороне аксапты формирование отчета организовывалось на базе пакетной обработки. На RS скорость исполнения возросла на 20%, но запускать пакеты на формирование отчетов в RS из аксапты большого смысла нет.
У RS есть служба управляемых подписок - на основании запроса формировать отчеты. То что надо для таких случаев. Получается надо таблицу которая будет содержать нужные параметры и использоваться в запросе RS. Но согласитесь если для каждого отчета на RS делать свою таблицу это будет несколько расточительно. Поэтому сделал общую таблицу содержащую значения для формирования подписок.Состав полей очень простой: код класса формирующий подписку, путь к отчету, список параметров(Parameter1, Parameter2 и т.д.) и признак активности подписки чтобы ее можно было выключать временно. Сначало параметры забил отдельными полями, сейчас превратил их в массив так табличка симпотичнее выглядит). Вот собственно и все... Механизм отладил уже работает

[mazzy]

Цитата:

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

Но согласитесь если для каждого отчета на RS делать свою таблицу это будет несколько расточительно.

Категорически не соглашусь.

[KingPeas]

Цитата:

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

Категорически не соглашусь.

Поясните пожалуйста свою позицию?В чем прелесть если аот вырастет на 100 новых таблиц?
Я исходил из того, что используя одну таблицу буду не только экономить узлы AOT, но и упрощу настройку подписок на RS. А каковы ваши мотивы для такого утверждения?

[mazzy]

Цитата:

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

Поясните пожалуйста свою позицию?В чем прелесть если аот вырастет на 100 новых таблиц?

Вопрос поставлен некорректно.
От простого добавления 100 таблиц ни холодно, ни жарко.

Прелесть состоит в том, что эти 100 таблиц будут иметь свои типизированные поля, свои валидейты, свои индексы, свои relation'ы, свои права. Каждую таблицу можно будет отнести к определенному проекту и функционалу.

В общем, вы получите проверку на уровне компилятора, а не во время runtime.

Цитата:

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

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

А зачем "экономить узлы AOT"?
Но зато ваша экономия приведет к огромному динамическому программированию, к "универсальным" валидейтам, к неподъемному программированию прав
Подробнее см. Значение display метода по его названию

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

[KingPeas]

Цитата:

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

Прелесть состоит в том, что эти 100 таблиц будут иметь свои типизированные поля, свои валидейты, свои индексы, свои relation'ы, свои права. Каждую таблицу можно будет отнести к определенному проекту и функционалу.

В общем, вы получите проверку на уровне компилятора, а не во время runtime.

Это имело бы значения если бы эти таблицы использовались в DAX. Но их основное назначение хранить параметры для стороннего приложения и легкий доступ к ним в этом приложение. Типизированные поля это хорошо, но для исполнения в RS необходимо передавать параметры в виде сопоставимом с RS. То бишь дату например я передаю используя date2StrUsr(). Иначе параметр может просто не попасть в отчет, или даже привести к ошибке исполнения. Если будет 100 таблиц то везде требуется не забыть преобразовать данные при сохранении параметра. Заполнение параметров осуществляется из диалоговых форм Runbase к которым пользователи уже привыкли. Если они и введут неправильный параметр (например ранг в запросе) в итоге получат неправильный отчет, но то же самое они получали в аксапте, так что пока разницы не чувствую.
Поэтому все параметры преобразуются в строку и хранятся в одной таблице. А добавление параметра осуществляется через единый метод в наследнике Runbase.

Цитата:

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

Но зато ваша экономия приведет к огромному динамическому программированию, к "универсальным" валидейтам, к неподъемному программированию прав
Подробнее см. Значение display метода по его названию

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

Пришлось повозиться пару дней чтобы организовать таблицу для гибкой привязки параметров в аксапте с параметрами непосредственно в отчетах RS. Можно и без этого было обойтись, но неудобно переносить с одного сервера на другой и сервера перенастраивать при новых путях для отчетов на RS или изменении порядка параметров в отчете со стороны аксапты или RS. На этом динамическое программирование закончилось).
А насчет прав доступа выкручиваюсь таким образом). Разграничение доступа к таблице настройки параметров вручную осуществляется через форму. Те кому не положено не допускаются к ней обычными средствами. А заполнение прочих подписок выполняется через наследники Runbase. То есть если у пользователя есть права на формирование отчета он может добавить запись в подписку для данного класса. Если возникла ошибка при создании записи подписки достаточно в диалоге изменить значения полей с уникальным именем подписки и его пересохранить. А дальше все будет зависеть от безопасности на RS.

[mazzy]

Цитата:

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

Это имело бы значения если бы эти таблицы использовались в DAX. Но их основное назначение хранить параметры для стороннего приложения и легкий доступ к ним в этом приложение.

А в самом приложении?

Цитата:

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

Пришлось повозиться пару дней чтобы организовать таблицу для гибкой привязки параметров в аксапте с параметрами непосредственно в отчетах RS. Можно и без этого было обойтись, но неудобно переносить с одного сервера на другой и сервера перенастраивать при новых путях для отчетов на RS или изменении порядка параметров в отчете со стороны аксапты или RS. На этом динамическое программирование закончилось)

Спасибо. Надо подумать.