Оптимизация Цикла

[Tomash]

добрый день

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

покопался и нашел цикл, пробегающий по уже всем существующим кодам товара для установления нового, уникального

//________________________________

Процедура ВводНового()
ПеремКода=0; //<<------------------------------ ПеремКода
Справ=СоздатьОбъект("Справочник.Номенклатура");
А=0;
Пока А=0 Цикл
Если (Число(Код)<0) Или (Справ.НайтиПоКоду(Код)=1) Тогда
ПеремКода=ПеремКода+1;
Код=Число(ПеремКода);
Иначе
А=1;
КонецЕсли;
КонецЦикла;

//_________________________________

в общем, именно "пробегание" по всем уже существующим кодам и затягивает процесс.
если выставить начальное значение ПеремКода=10000; то создание карточки занимает десятую долю секунды

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

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

 

[unknown181538]

Сначала ответьте на вопрос, почему у вас не используется автоматическая установка кода, предусмотренная платформой? Скорее всего, сбита нумерация. Возможно, ее можно просто поправить.

 

[Дайнеко]

Абалдеть! Самое красивое решение - удалить эту процедуру.
А взамен, в конфигураторе поставить у этого спр-ка свой-во "Автоматическая нумерация.

Ну а в порядке решения головоломки, даже у такого, "топорного", решения есть оптимизация:

Спр.ПорядокКодов();
Спр.Обратныйпорядок(1);
Спр.ВыбратьЭлменты();
Спр.ПолучитьЭлемент();
НовыйКод = Число(Спр.Код) + 1;

 

[Tomash]

Сначала ответьте на вопрос, почему у вас не используется автоматическая установка кода, предусмотренная платформой? Скорее всего, сбита нумерация. Возможно, ее можно просто поправить.

слишком сложный вопрос

если точнее, то конфа очень старая, 7.7, самописная, в которой чего только не наворочено, причём сменяемыми одним за другим программистами, так что она вся как лоскутное одеяло, никакой общей мысли, общего стиля или подхода к решению задач

нумерация сбита, да. поправить когда-то пытались, по дошедшим до меня слухам "столкнулись с непреодилимыми препятствиями", наворотили чёрт знает чего, вместо нормального решения поставили пару "заплаток" и забыли


2Дайнеко

попробовал, очень быстро выдаёт код = 1, документ не сохраняется из-за "неуникальности кода"

извиняюсь, моя оплошность, работает, НО, начал выдавать отрицательные коды, -00014, -00015 и так далее

даже не знаю, нормально это или нет, но быстро, это радует

 

[unknown181538]

"Ну а в порядке решения головоломки, даже у такого, "топорного", решения есть оптимизация: Спр.ПорядокКодов();
Спр.Обратныйпорядок(1);
Спр.ВыбратьЭлменты();
Спр.ПолучитьЭлемент();
НовыйКод = Число(Спр.Код) + 1;"
Мне кажется, это решение должно дать тот же результат, что и автонумерация.

 

[-master-]

НовыйКод = Число(Спр.Код) + 1;

это называется - прощай база...

 

[Tomash]

это называется - прощай база...

можно по-развёрнутей ответ чем это грозит

 

[-master-]

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

 

[unknown181538]

"Вы прикиньте, если в это время создается еще один документ (другим челом), или несколько, какой код будет у них - правильно один и тот-же, а это и значит - кирдык.Что-бы такого не произошло, надо лочить всю таблицу на все время создания документа, а это уже тормоза, кривая архитектура и как следствие - система в корзине.Остается один выход - использовать что-то типа авто-инкрементации (т.е. какими-либо системными фишками), либо реализовать их руками."
Вообще говоря, такая проблема существует и в стандартном механизме 7.7. Номер присваивается при создании документа, и два пользователя могут начать создавать его одновременно. При записи он кажется, предлагает изменить номер. Просто при записи надо новый номер определять. Ничего особенно страшного тут нет.

 

[-master-]

т.е. смотрю в книгу и вижу фигу? ну да ничего страшного, просто фига...
и эта, вопрос не про номер до записи и после, а про то что во время сохранения получить можно одинаковые.

 

[Tomash]

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

ну сейчас это почти так и есть, за исключением того, что проводится проверка на уникальность кода при сохранении карточки

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

по-сути, задачу действительно можно разделить на 2 составляющие:

1. Главная: ускорить выбор нового уникального кода

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

2. По желанию: обеспечить возможность одновременного создания карточек, чтобы при этом каждой из них присваивался уникальный номер. Что-то вроде резервирования номера, база сетевая, может какую-нибудь глобальную переменную ввести, посоветуйте

 

[unknown181538]

"т.е. смотрю в книгу и вижу фигу? ну да ничего страшного, просто фига...и эта, вопрос не про номер до записи и после, а про то что во время сохранения получить можно одинаковые." Транзакции не смогут происходить одновременно.

 

[-master-]

а кто сказал одновременные транзакции? при чем тут транзакции?
между получением информации и вставкой ее проходит много времени и случится может все что угодно

напрример тут

select @code = Max([code])+1 from documents
insert into documents (..., [code], ...) values (..., @code, ...)

никто не даст гарантию на уникальность, все просто

 

[unknown181538]

"а кто сказал одновременные транзакции? при чем тут транзакции? между получением информации и вставкой ее проходит много времени и случится может все что угоднонапрример тут select @code = Max(

)+1 from documents
insert into documents (..., [code], ...) values (..., @code, ...)никто не даст гарантию на уникальность, все просто"
В любом случае, система не даст записать документ с неуникальным номером.
Я уже написал, что проблема может возникнуть из-за того, что номер присваивается до транзакции записи. Но в результате документ просто не запишется, и придется присвоить новый номер.

 

[-master-]

Проблема не в том, когда генерируется номер, а в том, что при таком подходе нет гарантии уникальности.

Но в результате документ просто не запишется, и придется присвоить новый номер.

это плохой выход

 

[unknown181538]

Какого ваше предложение?)

 

[-master-]

выше давал

 

[Дайнеко]

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

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

А сосредоточится на вопросе: Можно включить "Автоматическую нумерацию"? Я вот что-то не понял автора: что мешает?
Фраза "вернуться к автонумерации - малореален" не очень информативна. Уверяю Вас - очень реально!
Надо: 1) взять мышь в правую руку, 2) кликнуть по слову "Конфигуратор", 3) в свойствах справочника поставить галочку "Автонумерация", вариант "В пределах всего спр-ка"

начал выдавать отрицательные коды, -00014, -00015 и так далее

Так разберитесь! Вариант такой: а вдруг код дошел до своего предельного размера?
Самый толковый вариант - простенькой процедурой перенумеровать все заново.

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

 

[-master-]

Дайнеко Ну надо же кому то поправлять тупников, не правда ли?

 

[Tomash]

А сосредоточится на вопросе: Можно включить "Автоматическую нумерацию"? Я вот что-то не понял автора: что мешает?
[...]
Так разберитесь!

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

следуя вашим словам, убрал процедуры насильственного втыкания номера, вернулся к автонумерации, получаю кода -000014, -000015....

Вариант такой: а вдруг код дошел до своего предельного размера?

попробовал увеличить длину кода на 2 порядка - получил новый код -0000001, -0000002...

поменял тип кода с текстового на числовой - получил код 990802, 990803...

в принципе, меня устраивают эти кода, остаётся только вопрос, насколько критично и на что может повлиять изменение типа? боюсь как бы не пришлось править половину отчётов и документов, в которых Спр.Код до сих пор обрабатывался как текст



//________________________________________________________________

Фраза "вернуться к автонумерации - малореален" не очень информативна.

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

т.е. процесс работы ведь в том числе включает и целесообразность затрат времени и сил к конечному результату.

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

но я конечно готов рассмотреть и ваши варианты, тем более если они откроют для меня нечто новое