EDT как Array

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

Зря Вы это сделали... С полями типа Array проблем больше, чем достоинств.

Физически, каждый отдельный элемент типа Array - это отдельное поле. Значит, обращаться необходимо к каждому такому полю персонально. Посмотрите, например, форму заказов на закладке "Аналитика". Там идет обращение к каждому элементу по имени.

Если Вы только начали разрабатывать структуру, то я бы посоветовал Вам отказаться от Array и использовать обычные типы данных.

[KingPeas]

Цитата:

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

Зря Вы это сделали... С полями типа Array проблем больше, чем достоинств.

Физически, каждый отдельный элемент типа Array - это отдельное поле. Значит, обращаться необходимо к каждому такому полю персонально. Посмотрите, например, форму заказов на закладке "Аналитика". Там идет обращение к каждому элементу по имени.

Если Вы только начали разрабатывать структуру, то я бы посоветовал Вам отказаться от Array и использовать обычные типы данных.

Да уж это точно. Была таблица с 16 однотипными полями, решил превратить их в одно... Все бы хорошо да поле типа строка размер Memo. На базе такого типа массив не формируется.Так что скорей всего придется переделывать назад. Всего то хотел чтобы таблица не разбухала при увеличении списка параметров.

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

Цитата:

Сообщение от 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 метода по его названию

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