Создаю форму в тонком клиенте, создаю реквизит формы типа "ТаблицаЗначений".
Где хранятся данные этой таблицы? На клиенте или на сервере?
Если я делаю поиск в этой таблице, происходит два вызова сервера (видно в информационном окошке) с довольно большой задержкой. Это нормально?

(39) это было бы идеально да
но мы живем в одинэсе )

(41) она тогда и вызывается. там еще нужно несколько вызовов, я ее для примера привел.

(42) Окстись. Запросы, они к БД. Можно, конечно, во временную таблицу загнать. Но зачем??

(44) для чего нужны другие вызовы ?

(46) Для передачи даты налево. Это обработка по приему платежей в ОСМП. Это не так важно, забейте.

(45) учится человек)
(42) во временную заворачивай
реквизит скорее всего выгрузить надо будет в параметр запроса

(48) реквизит типа ТаблицаЗначений на сто строк - в параметр запроса длиной в пять строк???
Я начинаю сомневаться в такой оптимизации.

(47) ну я учусь в общем-то вместе с тобой) только учусь переваривая подходы других людей
когда бывает мозг замыливается чужие подходы иногда полезны весьма ))

(49) не сомневайся - делай )

такой подход позволит безболезненно пережить расширение нагрузки в десятки раз
не на этой базе так на других к которым ты приложишь руку
не живи одним днем )

(52) О да. Перегрузка туда-сюда сотен тысяч строк - чудеса масштабирования.

впрочем дело хозяйское - я показал уже в (15) как уменьшить расходы вдвое )
в 8.2 надо быть плюшкиным в кубе )

(53) у меня уже такая ситуация - на момент внедрения не планировался бурный рост количества заказчиков
сейчас лезу в более чем годичный свой код с оптимизациями )

понимая что сейчас бы переписал все иначе совершенно

(55) Я о том, что для локального поиска в таблице значений по простым критериям - глупо использовать временные таблицы. Если упрется в производительность - индексы добавит и всё. Это гораздо более правильное и масштабируемое решение будет.

(53) сервак же резиновый и все сделает - у него голова большая.

это ж в каких книжках рекомендуют такую чушь?

(57) меня бесит что просто Найти похерили на клиенте
вот ее бы могли бы оставить + без обращения к серверу

(57) для локального поиска Сtrl+F ))

странная полемика пошла.
А давайте каждый напишет, как он бы переделал фрагмент (8) и разберем код каждого?

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

(59) Велика беда. Для легких поисков можно и без него обойтись - тупым обходом.
Я тяжелые поиски сам бог велел на сервер выносить.

(58) для хорошего сервака плевое дело

(61) извини - это дорого )

(62) автор я.
У меня есть таблица с 20-ю полями. Мне нужно найти в ней одну строку и получить все значения полей из нее.

(64) Вот только не надо тогда лапшу на уши вешать про масштабируемость, если вся твоя масштабируемость упирается в железо, которое сроет все твои косяки.

(63) ну нафиг - циклы это отрыжка какая-то
хотя... если именно сэкономить сервер

(66) Если речь о сотне строк и перебор не ведет в серверным вызовам (я просто в УФ не настоящий сварщик) - я бы просто перебрал на клиенте. Должно быть очень быстро, если 1С еще где-то не потоптались.

(66) по быстрому (15) - на будущее - запрос
хз какие в будущем условия будут - в найти ты только равенства можешь отобрать

(67) нет блин - надо всю работу на клиент переложить причем с голимой встроенной синхронизацией с серваком
+ еще за вариант с обходом в цикле надо сразу к стенке по хорошему ставить ))

мой вариант (8)

&НаКлиенте
Процедура ПриИзмененииЭлементаФормы(Элемент, Знач АвтоОпределениеСотовогоПровайдера = Ложь)
   
   // Отбор для ДанныеФормыКоллекции
   ОтборДфк = Новый Структура("ИдПровайдера", ВыбПровайдер);  
   мДфЭлКол = ТабПровайдеров.НайтиСтроки(ОтборДфк);
   
   Если мДфЭлКол.Количество() Тогда
       СтрокаПоискаТЗПровайдеров = мДфЭлКол[0];
   КонецЕсли;

КонецПроцедуры;

(71) У нас с вами разные представления об оптимальности и масштабируемости. Настолько разные, что делают спор бессмысленным.

(69) ты реально не понимаешь что тонкий может на самом лажевом железе крутиться ?
а если еще в идеале эту конфу завести на веб-клиенте который на телефоне запущен...
будем двуядерные смартфоны советовать как платформу?

Я поржал. Над собой, не парьтесь. Тему можно закрывать.
Решение проблемы оказалось в том, что затронули слегка и чисто случайно.
В (27) указаны две процедуры, которые и давали задержку. Они вызываются просто немерено в обработке, и после указания "&НаСервереБезКонтекста" они стали выполняться неизмеримо быстрее.

(72) баня) (15)

баня=баян

(73) вероятно) потом как-нибудь пересечемся еще )) когда повсеместно будет 8.2

(76) ошибаетесь. Отличия от моего кода:
В (15) структура отбора не хранится.
В (72) только то, что нет сравнения на >0.

(74) Простой перебор небольшой коллекции даже убитую нокию не затормозит.

(79) накуа отбор хранить? он сразу дематериализуется когда становится ненужен
сравнения нет - наверное описка

(80) + А вот накладные расходы на серверные вызовы и синхронизацию контекста могут быть весьма ощутимые.

(80) хз надо пробовать
я просто все время намекаю что небольшая коллекция легким движением руки может стать большой
то есть не нужно имхо затачиваться на относительные понятия маленький\большой

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

в

// ....
...

они могут пригодиться, не могут убиваю сразу

(84) В данном случае Экспериментатор прав - отбор хранить не нужно, он не используется позже.

(84) хотя раз пригодились? )
обычно понятно в каком контексте производится отбор и получать его составляющие мало смысла
да и оптимально выполнить отбор по структуре надо один раз

(85) вообще старайся чтобы логический блок кода располагался на одном экране (запросов не касается)
если логический блок кода не влезает на экран значит надо оптимизировать еще

(84) кстати как убиваешь структуру? переприсвоением?

(87) экраны разные бывают) По этому правилу для 1024х768 задолбаешься оптимизировать.

(0) ТС - потом если сделаешь померяй отладчиком что быстрее на объеме найтистроки или запрос ?
хотя я думаю выбор ты уже сделал)

(89) конечно 1920х1080

(83) Я тоже х.з, ибо на тонком клиенте опыт небольшой. Но предыдущий опыт подсказывает, что заведомо легкие вещи нет смысла гнать на сервер. Надо взвешенно подходить в каждом случае. Перестраховка на каждом углу она ведь тоже не даром - увеличение латенси на простейших вещах из-за лишних серверных вызовов плохо сказывается на юзабилити. О производительности клиента думать конечно надо, но не надо забывать и о качестве канала. Это сплошь и рядом играет более важную роль.

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

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

(90) вопрос не в скорости в этом случае, а теперь представь, что юзеров пара сотен и все они сношают сервер, качая солидные данные тз с форм и сделай куммулятивные замеры, если сервер вообще будет отвечать)

(94) дык все равно сношают сервер )
я уже говорил что запрос к ТЗ имеет смысл если планируются сложные отборы на больших объемах данных
на самом деле смотреть надо задачу более широко - возможно ТС вообще неправильный подход к решению избрал

(93) УФ лишь средство помогающее реализовать потребности бизнеса
когда средств становится недостаточно - потребности реализуются другими доступными способами
каждый судит по своему опыту и со своей колокольни

(95) кратко опиши мне задачу в условных терминах(Справочник.Дыни например) для которой необходимо разполагать на УФ таблицу значений с объемом данных в тысячи или десятки тысяч строк.

Естественно на таких объемах слабый клиент будет подтормаживать на поисках и отборах строк.

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

Так опишешь задачу?

(97) Справочник есть справочник. Он хранится в базе, держится естественно на сервере. Вы лучше представьте себе таблицу, которая получается с левого сервера в интернете при начале сеанса работы, и от нее уже отталкивайтесь.
Вы же не будете каждый раз справочник заполнять/очищать?

(97) например задача из логистики, когда клиенту надо выбрать из множества доступных ему точек доставки с сопутствующими сведениями из разных таблиц базы данных
причем количество доступных точек доставки непредсказуемо и может варьироваться от 0 до нескольких тысяч

+(99) правда критерии отбора клиент делает заранее до вывода результат в ТЗ но это только сужение поиска

(97) как я понимаю все же одинэс не такие глюпые и выясняют модифицированность данных формы
так что осталось решить только как оптимальнее делать отбор данных из ТЗ

(98) )) я ж говорил ему что задачи бизнеса бывают разные
таблицы только хранят данные а вот выборка по ним может быть весьма витиеватая )

99 точки доставки должны быть некими классификаторм в БД и его состав всегда конечен при создании формы.

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

Грузить же массу данных в некую мифическую тз на форме и потом чесать репу как в ней что-то найти - кривое проектирование)

который будет выступать мастер-таблицей для заполнения тз прежде всего

(103) О чем вообще спор? Классификатор, справочник - какая разница? Из них даже ежик будет запросом данные тягать!
Речь идет именно о том, как оптимизировать выборку из ТЗ. Почему использованы ТЗ, я тоже уже объяснил.

(102) вы кроме 1С работали с таблицами БД, сейчас на 8.2. можно представить дсписок произвольным запросом как комбинацию таблиц ТБ, строковых, числовых констант и т.д.,
т.е. одим запросом построить тот же вид пользовательских даныых с которым вы извращаетесь помещая его в тз)

(103) ДС проходили - тормозит
в ТЗ клиенту предоставляется информация о городе доставки, точке доставке, грузополучателе и договоре с клиентом
все это разные таблицы БД
отбор клиент осуществляет быстро вводя различные свойства этих условно говоря колонок
иерархия долго и непонятно для клиента - клиент ОЧЕНЬ разный и его уровень мне не интересен - важен заказ

(105) способ оптимизации очень прост - минизировать данные тз, я не поверю, что если я вижу на форме тз с тысями строк, то не было другого способа пердстваления вида.

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

(106) где это обосновано там используется ДС - но у него свои выкрутасы

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

(107) иерархия просто и понятно для клиента если ее показать просто и наглядно.

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

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

(111) в вашей задаче подход изначально неверен - для нее нужен вебсервис, тогда и проблема с громадной тз отпадает

(112) кстати вспомнил что просили эту таблицу еще штатно выгружать в таблицу
вот почему пришлось там оптимизировать плоский список

(113) расскажите это ОСМП. С ее десятью миллионами терминалов.

(115) тгда другого пути у вас не будет, обсуждаемый костыл рано или поздно станет не эффективен

(0) Данные ТЗ хранятся на сервере в данных сеанса. Для отображения данных ТЗ у клиента, они конвертируются в ДанныеФормы и передаются клиенту. ДанныеФормы <> ТЗ. Обращение к ДаннымФормы (на клиенте) для их перебора или поиска однозначно приведет к серверному вызову.

(116) другого пути - это какого? Господи, задача ограничена:
Факт = Есть ТЗ.
Факт = Есть необходимость найти в ней строку.
Цель - сделать это самым оптимальным способом.

Все! Нет справочников, нет классификаторов и иерархических списков!

(112) тормозов нет касательно именно этой таблицы - по крайней мере жалоб от клиентов не поступает
неожиданные тормоза стали на подобном в (0) случае
когда найтистроки на клиенте вызывали тормоз на паре сотен строк в ТЧ документа
вообще наверное меня можно не принимать всерьез так как УФ используются во всех видах клиентов
+ отладка сервера включена
но в идеале надо чтобы не тормозило во всех видах клиентов чтоб наступило всеобщее счастие ))

(118) Оптимальный способ это вызов контекстной серверной процедуры, поиска в ней данных.

118.

Решение задачи в следующей вашей постановки

"Вы лучше представьте себе таблицу, которая получается с левого сервера в интернете при начале сеанса работы, и от нее уже отталкивайтесь"

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

(120) А если достаточно данных формы? Разве я не могу без вызова сервера обойти представление данных (ДанныеФормыКоллекция)?

(121) Честно признаюсь, я не понимаю, что такое элемент данных и элемент управления данными.

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

ТС может представить исходные данные как внешний источник данных в 8.2 и по нему уже делать хоть ДС хоть что ??

ТабПровайдеров как получается ?

(122) И это приведет к серверному вызову, так как на стороне клиента ДанныеФормы могут являться лишь частью данных реквизита формы. Для ТЗ это особенно актуально, так как ее данные могли быть изменены и уже не равны ДаннымФормы.

(125) одним ответом сервера ОСМП. Вся сразу. В виде XML, из которого собирается таблица.

(127) большая судя по всему ?

наверное
я бы заполнял некий регистр сведений этими данными
чтобы избежать многократных созданий временных таблиц для запросов к ТЗ
запрос по регистру будет быстр
далее как представить этот регистр на клиенте - дело фантазии разработчика

(128) примерно 100 строк, 20 колонок. я уже говорил.
(129) Эта таблица уникальна у каждого пользователя, а порой - и при каждом запуске.
Кроме этой таблицы есть еще порядка 20 похожих списков от 5 до 500 записей.

(129) И да, пользователей около 100.

(131) Таблицу надо пользователю показывать? Или только выборку из таблицы?

(132) при настройке - надо. При повседневной работе - нет.

юзай пока (15) а потом при необходимости перепишешь

или тоже лаг большой ?

(135) Лаг давно ушел, см (75).
Просто спор уже на принцип пошел - как оптимальнее.

(126) То есть, отображение ТЗ в тонком клиенте идет порционно, подкачивая данные по мере необходимости так же, как и для динамических списков? Понятно, что динамические списки еще и из БД порционно выбирают. Я в части клиент-серверного взаимодействия интересуюсь.

(136) )) не поверишь я только сейчас этот пост заметил - так увлекся )

(137) по моим наблюдениям ТЗ целиком попадает на клиент

(20) "с какого перепугу нагибать сервер если это данные исключительно формы, Тз - чисто виртуальная сущность представленная на форме, хрена соваться с ней на сервак без острой необходимости, просвети."

Я вот тоже не пойму. Нет, я вот в 8.2 пока не силен. Но ТЗ (данные которой используются чисто в форме) - обрабатывать тоже на сервере надо?
Мой моск сломан.

(140) одинэс походу решил воплотить триединство в УФ
клиент, сервер и отображение ))

"чисто формы" нету - матрикс хаз ю )