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

Tomash

Active member
16.01.2013
40
0
#1
добрый день

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

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

//________________________________

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

//_________________________________

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

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

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

unknown181538

НеГуру
28.12.2008
1 417
0
#2
Сначала ответьте на вопрос, почему у вас не используется автоматическая установка кода, предусмотренная платформой? Скорее всего, сбита нумерация. Возможно, ее можно просто поправить.
 

Дайнеко

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

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

Tomash

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

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

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

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


2Дайнеко

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

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

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

unknown181538

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

-master-

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

unknown181538

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

-master-

Well-known member
14.01.2012
616
12
#10
т.е. смотрю в книгу и вижу фигу? ну да ничего страшного, просто фига...
и эта, вопрос не про номер до записи и после, а про то что во время сохранения получить можно одинаковые.
 

Tomash

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

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

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

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

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

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

unknown181538

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

-master-

Well-known member
14.01.2012
616
12
#13
а кто сказал одновременные транзакции? при чем тут транзакции?
между получением информации и вставкой ее проходит много времени и случится может все что угодно

напрример тут
Код:
select @code = Max([code])+1 from documents
insert into documents (..., [code], ...) values (..., @code, ...)
никто не даст гарантию на уникальность, все просто
 

unknown181538

НеГуру
28.12.2008
1 417
0
#14
"а кто сказал одновременные транзакции? при чем тут транзакции? между получением информации и вставкой ее проходит много времени и случится может все что угоднонапрример тут select @code = Max(
Код:
)+1 from documents
insert into documents (..., [code], ...) values (..., @code, ...)никто не даст гарантию на уникальность, все просто"
В любом случае, система не даст записать документ с неуникальным номером.
Я уже написал, что проблема может возникнуть из-за того, что номер присваивается до транзакции записи. Но в результате документ просто не запишется, и придется присвоить новый номер.
 

-master-

Well-known member
14.01.2012
616
12
#15
Проблема не в том, когда генерируется номер, а в том, что при таком подходе нет гарантии уникальности.
Но в результате документ просто не запишется, и придется присвоить новый номер.
это плохой выход
 

Дайнеко

Well-known member
19.11.2009
951
0
#18
Я вижу у нас появились умники и увели вопрос в какие-то дебри, забыв об авторе и его проблемах.
Что ему делать?

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

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

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

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

-master-

Well-known member
14.01.2012
616
12
#19
Дайнеко Ну надо же кому то поправлять тупников, не правда ли?
 

Tomash

Active member
16.01.2013
40
0
#20
А сосредоточится на вопросе: Можно включить "Автоматическую нумерацию"? Я вот что-то не понял автора: что мешает?
[...]
Так разберитесь!
подскажите где искать процедуры, отвечающие за автоматическую нумерацию, мне казалось, что они зашиты в ядре программы и к ним вряд ли можно получить доступ. а работают по-факту они странно

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


Вариант такой: а вдруг код дошел до своего предельного размера?
попробовал увеличить длину кода на 2 порядка - получил новый код -0000001, -0000002...

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

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



//________________________________________________________________

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

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

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

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