Oremaxs_ustinovпропущено...

Курсоры? Тяжело придумать пример более плохого кода.

пропущено...

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

Когда покажите результаты лучше чем эти Тестирование производительности №1 Стресс-тест и эти Тестирование производительности №2 Нагрузочное тестирование тогда будем обсуждать качество кода.
Резервирование товара

Строк в секунду 342,95
Я когда тестировал производительность моего кода резервирования, получил чуть меньше 1000 товаров в секунду - 900 с чем то. У многих товаров по несколько строк резервирования, так что строк в секунду раза в полтора больше, но не считал, сколько именно строк было.
К сожалению, я в той фирме больше не работаю, и сделать более полные тесты не могу. Я и тот тест сделал только один раз. Увидел, что пиковая производительность значительно перекрывает потребность, и больше не тестировал. Ну и скорость больше не оптимизировал, хотя было что оптимизировать.

Oremax, я не хочу сказать, что у вас плохая или медленная система. Но использование курсоров - мягко говоря не лучшая идея. Вы что, действительно их постоянно используете в своей системе?

Программист 1сСтранно - зачем Вам как кодеру цвет ж*пы знать? Вы же сами говорили что Вам достаточно знаний кодера, а всякие там бизнес процессы- этим глупостями пусть другие занимаются...

ps Я бы конечно сначала разобрался в причинах пропажи резервов, причин невозможности сборок, разобрался бы почему и из-за чего подобные ситуация возникают и возможно решил их не используя ни одной строчки кода. Но мы же не ищем легких путей? Код наше все?
Я не спрашивал про детали бизнес - процесса, а спрашивал про поведение (возможности) программы в ситуации, когда кладовщик принял на склад меньше товаров, чем указано в документах. И мне действительно интересен ответ на этот вопрос - в свое время потратил много времени, чтобы найти решение, и интересно, как другие решали эту же задачу. В свою очередь я могу объяснить, как такие ситуации решаются в моем алгоритме.

Программист 1с, когда человек начинает задавать не относящиеся к предмету обсуждения вопросы только для того, чтобы скрыть, что ему нечего ответить по существу - это всегда очень заметно.

Oremaxs_ustinovЯ когда тестировал производительность моего кода резервирования, получил чуть меньше 1000 товаров в секунду - 900 с чем то. У многих товаров по несколько строк резервирования, так что строк в секунду раза в полтора больше, но не считал, сколько именно строк было.
К сожалению, я в той фирме больше не работаю, и сделать более полные тесты не могу. Я и тот тест сделал только один раз. Увидел, что пиковая производительность значительно перекрывает потребность, и больше не тестировал. Ну и скорость больше не оптимизировал, хотя было что оптимизировать.
s_ustinov, я считаю, что было бы хорошим тоном вместе с цифрами описать методику и условия тестирования или не приводить цифры вовсе.
Ок.
К сожалению, у меня не было возможности провести полноценное тестирование. Поэтому тестировал "на коленке":

На тестовом сервере (характеристики не помню, но далеко не самый новый и мощный - в 2013 году ему было уже несколько лет) была копия рабочей базы.
Я сформировал список товаров, по которым необходимо было создать резервы (есть в заказах покупателей или в неучтенных межскладских перемещениях). Таких всего оказалось меньше 15 тысяч.
После чего написал простую процедуру. Эта процедура с помощью Service Broker запускала много экземпляров процедуры пересчета резервов. Фактически, я смотрел, как работают сообщения, тестирование производительности было второстепенным.
В результате у меня очень быстро запустилось много экземпляров процедуры пересчета резервов, каждый экземпляр процедуры пересчитывал резервы для 200 товаров (точно уже не помню, может и 100).
И за чуть больше чем 15 секунд все экземпляры процедуры завершили работу (некоторые отработали за 3 секунды, другие подольше, а один то ли 15, то ли 16 секунд работал). Я тогда посчитал - больше 900 товаров в секунду обработано. В результате было создано около 40 тысяч строк резервов.

Методика тестирования не самая совершенная, но мне хватило.

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

Программист 1сs_ustinovТо резервы пропадают, то кладовщики не могут нормально учесть складские операции из-за резервов. Как вы решили задачу обработки таких ситуацийs_ustinovпропущено...

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

Программист 1с, когда человек начинает задавать не относящиеся к предмету обсуждения вопросы только для того, чтобы скрыть, что ему нечего ответить по существу - это всегда очень заметно.Тоесть пропажа резервов, или проблемы с учетом резервов - это мелочь неинтересная Вам? И из-за того что Вы не разорались в бизнес процессах, вы решаете эту задачу кодом? Может надо было просто подумать получше?

ps И в ответ на разумные вопросы - один и тот же ответ, то анекдот про ж*опу. то рассказ что оппонент ничего не понимает... Уже интересно какую очередную глупую отмазку придумаете, из-за Вашего неумения посмотреть на проблему целиком, а не рассуждать как недальновидный кодер.
А почему вы решили, что я не разобрался в бизнес процессах? И какая связь между бизнес процессами и пропажей резервов или проблемами с учетом резервов?

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

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

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

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

я вас больше скажу: бывают повторные приемки: когда часть товара не удалось опознать, эту часть приходуют повторно в рамках прихода. отыскавшийся товар снова падает в резервы, снова смски менеджерам: а вдруг клиент еще не отменил заказ...да, жизнь, она такая
То есть при отклонениях резервы просто теряются и корректировки надо делать вручную...
А как "отыскавшийся товар снова падает в резервы"? Если резерв уже отменен и менеджеру смс отправлен? Или снова падает в резервы тоже вручную?
И как "по правилам отбираются и отменяются резервы" - отбирается самый поздний заказ и его резервы отменяются или используются более сложные правила?

_bob
не теряются, а отменяются. заказ меняет свой статус, менеджер заказа предупреждается и дальше ДА: связывается с заказчиком, переносит строки заказа, либо удаляет позиции..........а у вас как-то иначе?

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

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

или вы про какие-то другие автозапчасти тут нам рассказываете?
или мы с вами в разных реальностях находимся?
У вас немного другая страна, так что не могли заметить.
http://www.elit.ua/

Когда я обсуждал с менеджерами, что надо делать, если товар не приехал в перемещении, все отвечали одинаково - если он где-то есть - привозить. Разумеется, клиентам не нравится, что пообещали товар завтра, а он приехал послезавтра. Но еще больше им не нравится, если товар вообще не приехал. И случаи, когда клиент отказывается от заказа по причине срыва сроков - редкость. Не имеет смысла им звонить и уточнять - у нас небольшая накладка произошла, сегодня товар не привезли, должны привезти завтра - сохраняем заказ? В 99% клиент подтверждает заказ.
Поэтому в моем варианте алгоритма ситуация, когда товар не приехал, вообще никак не обрабатывается . Алгоритм просто "не видит", полностью приехало перемещение или нет - он никак не анализирует те резервы, которые были и уже учтенные перемещения - это сложно и долго. Он просто резервирует товар там, где найдет. И если в перемещении с центрального склада товар не приехал, но на центральном складе этот товар есть - зарезервирует на центральном складе и товар приедет следующим перемещением.
С одной стороны, в этом есть некоторая проблема. Нет события, к которому можно привязать отправку емаил или смс с предупреждением, что сроки выполнения заказа срываются.
С другой стороны, резервирование вообще не требует от менеджеров и кладовщиков дополнительных телодвижений. Оно полностью работает в фоновом режиме. И если товар где-то есть - он будет доставлен (возможно, позже, чем обещали).
У проблемы оповещения о срыве сроков есть другой вариант решения. Для каждой строки заказа можно рассчитать и сохранить ожидаемый срок выполнения (если товар есть на локальном складе - дата заказа, если на центральном - дата заказа + 1 день и т.д.). И регулярно запускать проверку (например, пару раз в день) - соответствуют ли ожидаемые сроки выполнения текущим резервам. Например, срок выполнения 09.01, сейчас 11.01, товар зарезервирован на складе, откуда будет отгрузка - все хорошо. Или срок выполнения 12.01, товар зарезервирован на центральном складе, срок поставки с которого +1 день, 11.01 + 1 день = 12.01 - тоже всё хорошо. А например срок выполнения 11.01, товар зарезервирован на центральном складе, срок поставки с которого +1 день, 11.01 + 1 день = 12.01 - сроки сорваны. И рассылать менеджерам отчет о срыве сроков. Или же включить эти данные в отчет о готовности заказов к отгрузке - есть специальный отчет, показывающий, какие заказы полностью готовы к отгрузке (все товары зарезервированы под заказ на складе отгрузки), какие частично.
Правда, сроки доставки я не доделал, и не знаю, сделали этот функционал или нет.

Вообще тема резервов для подобных фирм часто достаточно болезненная. _bobно шансы получить "отказ поставщика" есть, и они прямо пропорциональны остаткам. я те детали которые в малом количестве на остатках почти никогда не заказываю: наверняка их не привезут - это во многом именно проблемы резервирования.
Те варианты реализации резервирования, что я видел, работали ненадежно и требовали много ручного контроля. Например, межскладские перемещения. Даже если всё приехало, не факт, что резерв не потеряется. Когда резервы "переносятся" с перемещения на локальный склад, из-за дедлоков процедура может слететь, и резерв в результате "потеряется" - будет числиться за перемещением, которого уже нет (учтено), а товар, который есть на складе (который привезли) находится в свободном остатке, и другой менеджер может продать другому клиенту. А потом начинаются разборки в стиле "мой клиент этот товар 2 недели ждал, пока его привезут - что мне ему говорить?!?!"

_bobs_ustinovпропущено...


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

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