148-Sadovnikov >"Проявилось с ростом базы."
любопытно, сколько товаров в базе, сколько документов/строк?

И еще, посмотри что у тебя творится при поиске строки в документе, что проиходит при нахождении дубля, нет ли повторного обращения к расчету цен, сумм, ндс и т.п. как если бы это была совершенно новая, незаполненная строка.

Ценообразование.Цена(Номенклатура, КатегорияЦен, Дата);
Медленная функция будет...

161-Маус > Товаров - около 3000 всего... Документов - несколько сотен приходных накладных, пара десятков тысяч чеков. Ну и остального понемногу.
162-bma1 > Я там выше код выложил.
163-bma1 > Ну да. Скоростью блистать не должна. Но отрабатывает только на первой штучке товара. А мы теряем последующие.

2(164) Потому что в накладной не держите штрих-код. Ищите сразу дубли строк по щтрих-коду, без поиска номенклатуры.

165-bma1> Согласен, стоит попробовать.
Когда рисовал базу - был уверен, что восьмерка по индексу с охренительной селективностью должна просто со свистом искать.

2(166) у меня 38000 позиций. Ищет практически мгновенно.

Розница 2.0, около 40 тысяч позиций, комп - на intel atom
нет проблем с производительностью

(166) Не, не стоит. Просто вытащи функцию поиска товара по штрихкоду в общий модуль с повторным использованием значений. Хотя ИМХО дело все равно не в поиске номенклатуры, замер надоть. Кстати приходные накладные начинают тупить с первого сканирования или нет?

я за вами слежу. и записываю.
попутное имхо - должно быть сделано так, чтобы во врем яОПЕРАТИВНОЙ РРАБОТЫ - ничего не вычислялось. ничего не анализировалось. а дергалось уже готовое.

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

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

167-bma1 > Вот так и должно быть. Сегодня планирую базу помучать маленько и погледеть в чем затыки. Я тоже не особо верю, что именно в поиске по штрихкоду - уж больно малые объемы информации в базе.
168-Управление торговлей 11 > Вот извини, но твоим уверениям что со скоростью все хорошо я поверю в последнюю очередь. Уж больно разные у нас понятия о приемлимом быстродействии.
170-Чучундер > Поясни? Точнее, покажи, что именно в моей конфиге считаешь неверным в этом плане?
171-Зелёный тролль > Да, вроде, не зашпыняли :) Нормальное обсуждение идет.
172-Пудель > Имеешь в виду регистр Подажи или что-то другое?

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

2(174) ты прав, хотя с "регламентным заданием раз в сутки" погорячился, чуток почаще надо.
P.S.
Я видел на днях понравившуюся мне реализацию, где был регистр сведений со штрих-кодом, текущими остатками (в регистре присутствовали только те позиции, что были на остатке), ценой и ссылкой на справочник номенклатуры. Так как в той конторе справочник номенклатуры был за 250000 позиций, из которых на складе реально пристуствовало позиций 10000 - это давало существенный прирост скорости поиска.

(175) возмолжно, тут от специфики наверное зависит. единственное, что врознице любят всякие развесистемые схемы дискацнтов всяких...
.
ну и глубоко укоренившееся во мне мнение - универсальные решени - зло. Хочешь чтобыбыло хорошо - делай спецрешение.
.
ну а садовников, я думаю, порвет всех, как только поймет/выяснит чт о и где и как 1с ведет себя неправильно... ;-)

(176) Ну пока себя неправильно ведет Садовников. Снеговика все-таки нужно готовить по методичкам от 1С, а не пытаться угадать поведение СУБД. Отчеты тормозят только из-за того, что структура данных спроектирована по классической теории БД, без оглядки на 1С. А по штрихкодам нужен замер - без него гадание на кофейной гуще. ИМХО там тоже какая-то не слишком трудноразрешимая лажа.

(173) Я уже подзабыл какие там регистры в отчёте, примерно так:
1. в одном месте условие по типу регистратора - я бы переделал на индексированный реквизит или даже измерение, и вообще ситуация, когда мы отбираем по типу регистратора - ненормальна с методической точки зрения.
2. плюс вполне возможно, что реквизит номенклатуры, по которому отбор, лучше будет смотреться не в справочнике, а регистре/регистрах накопления допреквизитом,
3. а также подумать, для того же реквизита не будет ли быстрее работать регистр сведений.

177-Reaper >178-Пудель > 1С умудрилась нарисовать систему, попирающую законы построения БД?
178-Пудель >2 и 3 не понял. Поясни?

174-Чучундер > Не высокая интенсивность этой розницы. Совсем невысокая. Именно по этому еще и не дошли руки до нормальной оптимизации.
И тормоза, как я неоднократно писал выше, совсем не в розничном куске.
175-bma1 >[em](в регистре присутствовали только те позиции, что были на остатке[/em] - а как там поступали в ситуации, если покупатель притащил на кассу товар, которого нет на остатках?

Для настаивающих на том, что в регистр Продажи необходимо запихать движения расходных накладных и доп измерение, говорящее о том, это была именно расходная накладная. Вот количества документов в базе (чеков и расходных накладных):
ЧекККМ 25 720
РасходнаяНакладная 552
В 95% случаев по этому регистру анализируются именно продажи по чекам.
Абсолютно не вижу смысла делать так, что бы расходная писала в регистр Продажи...

(181) Я тебе уже накидал вариантов и с измерением и с отдельными ресурсами. Ты хоть что-то попробовал? Или теоретизировать интереснее?

182-Reaper > Каюсь - нифига не делал. Вчера планировал поэкспериментировать, но пришлось срочно в магазин ехать...
Я ж говорю - еще не прижало так, что бы всё бросать и срочно увеличивать скорость работы.

182-Reaper > Кстати, а ты чего в выходной день на форуме зависаешь?

(181) учитывая это, лучше убрать в запросе обращение к движениям регистра остатков, переписать на выборку по документам. размер таблицы РН меньше таблицы движений остатков на два порядка. методически это порнография, но в данном конкретном случае тормозить должно меньше, чем обращение к регистру остатков.
(179) -> (182) :)

185-Пудель > Вот с этим предложением согласен.
"методически это порнография" - идут лесом методологи, непонимающие, что и регистр и табличная часть документа - это таблицы.

(186) вот это меня тоже всегда настораживало... обосновывали тем что де регистры оптимизированы типа... правда что там принципиально автоматизировать...?

в базах данных всё - таблицы

187-Чучундер > Вот-вот-вот... В 7.7 еще можно было как-то обосновать возможностью индексы на регистры наставить. В ограниченных пределах, конечно же. В восьмерке же большую часть индексов отдали на откуп прогеру.
188-Маус > Расскажи это методологам от 1С...

184-Sadovnikov > У меня в течении следующей недели должна взлететь первая туча из грозового фронта. Да, да, именно так. Это у маркетологов "облака", а когда в этой каше варишься - имеешь грозовой фронт с толпой туч, каждая из которых норовит тебе молнию выслать. 2 недели без выходных, эта вот третья будет. Молюсь, чтоб хотя бы следующие выходные отдохнуть... А на форум выглядываю, пока у меня интеграции гоняются, или тяжелые алгоритмы пашут.

190-Reaper > Та же фигня... Сижу, ваяю обмен с "горячо любимым" МосПивом. Пока сохраняется, тыкаю "Обновить" на форуме...

[quote=Sadovnikov;26352959]а как там поступали в ситуации, если покупатель притащил на кассу товар, которого нет на остатках? [/quote]
Это 100% форсмажор. Прежде чем продать такой товар, необъодимо выяснить, откуда покупатель его взял. В последнее время с "загнивающего Запада" и в Россию пришло поветрие устраивать суды с магазинами из-за некондиционного товара. А если в руках у покупателя товар, которого не должно быть - необходимо сперва тщательно проверить его происхождение.

192-bma1> То есть, товар отбирается у покупателя и откладывается в сторону до окончания разборок?

2(193) А как иначе? Представь себе, что ты владелец, к примеру, продуктового магазина. Покупатель приносит на кассу тот товар, кторого по базе быть не должно. Ты пробиваещь чек и сидишь ждешь, когда этот покупатель по этому чеку подаст в суд, например за просроченный товар (ты же не можешь гарантировать ничего, продав тот товар, которого у тебя быть не должно), может покупатель специально пронес в магазин этот товар, чтоб тебя подставить.
В том магазине продают запчасти, и если будет разборка, откуда у покупателя на руках взялась бракованная или поддельная деталь - магазину серьезно не повезет.

Главное не чтобы товар не пронесли просроченный, а главное чтоб покупателя не пронесло

194-bma1 > У меня немного по другому. При продаже не анализируются остатки. Однако, ежемесячная инвентаризация, плюс постоянные проверки сроков годности. Шанс нарваться на просрочку (тьфу-тьфу-тьфу) - минимальный.
По этому исходил из принципа, что если покупатель притаранил к кассе товар, то он его купит.