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

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

Было!: есть реквизит формы "Штрихкод", и вот при изменении этого реквизита, мы получаем штрих(отправляемся &НаСервере), делаем запрос к регистру сведений, находим там номенклатуру к которой привязан этот штрихкод, дальше ищем эту номенклатуру в тч, и после того как нашли устанавливаем текущую строку на эту самую номенклатуру.

Стало!: сразу при заполнении тч достаем туда штрихкод, и при изменении реквизита штрихкод делаем поиск следующим образом:

СтрокаТоварыНаСкладах = ТоварыНаСкладах.НайтиСтроки(Новый Структура("Штрихкод", ПоискШтрихкод));
Элементы.ТоварыНаСкладах.ТекущаяСтрока = СтрокаТоварыНаСкладах[0].ПолучитьИдентификатор();


В моем представлении так должно было бы быть быстрее, НО кассры начал жаловаться что стало все этот диво работать медленнее.

Собственно вопрос: А ЧЕ ТАК-ТО!? (сервер не сильно мощный, даже на одной кассе системник мощнее...) Подскажите: кто тупит, я или кассиры? И может быть мне вообще пойти по другому путь(только не знаю по какому)? Как оптимизировать этот действие?

1с 8.3. уф
Заранее всем спасибо!

вариант 2 происходит на клиенте?

(1) да

(1) в этом то и была идея чтобы минимизировать вызовы сервера...

(3) Доступность:

Тонкий клиент, веб-клиент, сервер, толстый клиент, мобильное приложение(клиент), мобильное приложение(сервер).
___Вызов метода выполняет обращение к серверу. ___
(с) Синтакс помощник.

ищи перебором. или половинного деления, если отсортировано по ШК.

Пусть пилит временую таблицу ищет в ней.

(5) спасибо за подсказку. должно быть быстрее...

а если обращаться к самой тч, через запрос? или это не то пальто будет?

(6)Я так понял таблица грамадная и не изменяется. Пусть в менегереВТ будет. Теоритический при втором поиске она будет в темпах sql.

(4)
Доступность:

Тонкий клиент, веб-клиент, сервер, толстый клиент, мобильное приложение(клиент), мобильное приложение(сервер).
___Вызов метода выполняет обращение к серверу. ___
(с) Синтакс помощник.

Т.Е. ничего я не выгадал, так?

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

отсортировано оно не по шк, а можно ссылку или что-то про этот метод, желательно где написано для "одаренных", сейчас еще сам поищу.

спасибо

(0) а реквизит в ТЧ индексированный?

(7) ну как громадная. пару тысяч строк(не знаю мерки громадность в 1с...). в процессе создания чека не меняется. заполняется при создании на сервер.

(10) Чот меня понесло идея же была в поиске на стороне клиента ... тоже про (9) думал

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

Использовать не ТЧ, а Соответствие. Может, полегче будет.

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

(13) т.е. при создании на сервер зафигачить соответствие, засунуть туда идентификатор строки и  штрихкод. и потом просто устонавливать текущую строку. вариант, спасибо. буду пробовать.

(15) теже скорости неоткуда там приросту братся.

ТЧ в документе в итоге не хранится?

(14) а чем вас не устраивает рост БД? Ну докупите через 30 лет новый винт.

(15) не получится.

(16) неа.

(17) Он походу в ТЧ всю номенклатуру базы сливает и потом иещет в ней. Хранить дубли справочника номенклатура в каждом документе не хочет. Я правильно понял?

(19) Ну отчистит табличную часть перед записью.

А че, это все нельзя решить ДинамическимСписком, не?

поиск в ты на клиента - это ппц как медленно

*тч

(17) просто, я далековат от системного администрирования и от всех тонкостей 1с. и не знаю какой рост это за собой повлечет.

я когда увлекался php, (боже какой я старый...) тогда каждый лишний килобайт был на счету)))

огромноя просьба просветить что бы я мог и в дальнейшем использовать эти знания.

допустим в этой тч будет около 2 тысяч строк, около 150-200 чеков в день, ну и пусть хотябы это все будет на трех аптеках. значит в строках получаеться примерно около 1 000 000 строк в день. ну как-то так это не сильно скажеться на бд?

(25) ну допустим, длина реквизита 50 байт. Тогда если у вас 1000 документов с этим реквизитом, база увеличится на 50 кбайт. Ну даже если на мегабайт база вырастет, стоит ли вам париться?

(25) Нафига те их хранить если не надо??? Нафига те вообще этот реквизит если не надо?

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

(28) Теперь подумай логику и уменьши не количество вызовов сервера а количество передоваемой инфогрмации.

(29) +1 после каждого пика товар должен уходить в резерв. А хотя навернео один пк один склад.

(27) твой вариант про очистку тч перед записью гениален, я чот туплю)))

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

(29) инфа достаеться и так только та которая нужна, цены количество, номенклатура, срок. лишнего ничего нет.

(30) да пока один склад один комп. над резервированием начал разбираться уже. скоро будет..

(31) почему не динамический список, а тз?

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