Да, да ... добавлю, что конструкция данного задания должна решить следующее (это как понял я):
- хуман, садиться за ПК и тыкает в программе 100 новых приходов, 200 изменений, 1 брак и т.п. , а далее жмет "применить".
летит значит запрос c множествами в БД:
insert into "Движение"
select * from #предположим табличка с данными из программы, ну или набор данных через "union all"
все ... больше ничего нету.
А в этой табличке лежат данные вида:
1,0,1,100
1,1,0,2
1,0,1,100
1,1,2,100
1,2,3,100
5,3,6,100
5,3,0,100
...
И она может быть весьма большой.
Ага, еще и с ошибками, предположительно отрицательным остатком и даже дублями, продажей "из воздуха" и т.п.
Да, кто-нибудь вообще подумал о том что делать с этой транзакцией если в ней только 1 ошибка. Отменять все или исключать одну ...
Лично я, решал от такого примера.
Как там заказчик планировал вносить изменения это уже его трудности.
1,2) Я пусть сделал не верно, но все действия которые могут быть работают :) insert+update+delete.
все лишнее блокируется, а то что можно заносится+ удаляется, пересчитывается и отображается в другой таблице. Собственно, просто тут выложен insert, а другие не стал выкладывать ибо суть такая же.
3) как сделать update на 2-1000 разных строк разом без использования какого-либо цикла?
4) вообще, я предположил, что он остановит только себя, ибо как сказано в справочнике "rollback transaction;" может стопорить как явную так и не явную транзакцию. собственно, "insert" и есть неявная транзакция. Хотя, для гарантии стоило сделать явную транзакцию. К тому же это блок с insert, а update, delete идут другими отдельными триггерами.
На счет try/catch попробую, если на работе не завалят работой :)
====
как вы бы сделали:
1) идея хорошая
2) я предполагаю, что в "размещении" будет пусто, а в "движении" останется мусор, а его быть не должно. Опять же ... как update множество, с исключением плохих параметров в этом множестве?)
3) с этим у меня тоже циклов нету. там просто сложение и вычитание по нужному складу и всех влияний на него.
4) согласен.
5) тут нет. нет в этом примере отрицательного значения. Т.к. это множество и его нужно же сначала сгруппировать по sum(х) и уже полученное число из этого множества сложить\вычесть из того что было, проверить на отрицательность и потом добавить\отменить\изменить. а вот если мы делаем update на группу значений ибо нету даты опять же ... то под update может попасть n^n элементов, пересчет сумм которых вернет <0 на складе и такой update нужно остановить без повреждения данных t1 и t2.
Не совсем согласен, что if это плохо да и вообще циклы и #tmp плохо. Да, можно иначе в данном примере. Но, как вы заметили задача поставлена не особо корректно. Вы обратили внимание на дату, я тоже, но еще я обратил внимание, что не сказано как это надо сделать. Сказано - "нужно решить".
Учитывая что нет даты, то нет конкретики в запросе.
Работа будет с множествами и их подмножествами, а это означает каждый ваш запрос будет возвращать 1-N. И даже сейчас не совсем понимаю как вообще без логического цикла какого -либо решить сие задачу.
А если :
прилетел ОДИН запрос на 100 инсертов и 400 апдейтов и 10 делитов (ибо если все продали, зачем его хранить) разных складов и товаров?
Когда вам говорят: заблокируйте клиентов из группы такой-то. Вы же сразу спрашиваете, каких именно, правильно?! Ведь параметров может быть тьма - тьмущая ...
Я считаю свой код верным ибо он работает со всеми условиями update\insert\delete к тому же это 15 минут мышления. Второе - это просто метод. я не городил непонятно что, а делал определенную задачу . Правильность пути решения - это уже третий вопрос. Если бы я сидел перед руководителем, который мне поставил бы эту задачу, то пообщавшись мы бы пришли к общему знаменателю.
Но, если от тебя хотят "сделай, короче, красиво, но так, что бы мне это понравилось", то и получают ...
Я вообще не понимаю абстрактные задачи, а на выходе хотят что-то конкретное.
А ваш ответ мне понравился :)
motral: ВОТ !!! И я тоже не дурак :D
И мне даже мельком показалось (исходя из того, что это зоотовары ...) что, они искали решение некой конкретной задачи. Ибо косяки по базе ползут. Ну, пусть даже я ошибаюсь, но я же сделал то, что нужно было по заданию (пусть, этот метод не идеален).
А потом мне стало интересно, бывает ли такое, что тырят код, а потом кидают .... =\
Случалась ли с кем подобная стори ...
motral: говнокод?) в студию ваш код, товарищ :)
А если учесть, что это я написал почти за 15 имеющихся минут insert update и delete, то для меня это весьма не дурно. Но не в этом даже дело. Дело в том, что именно нужно работодателю. Вот могу сие хозяйство в 5 вариантов расписать. А толку?! Даже, если я перепишу set и #tmp, то и в этом случае упрощать уже будет нечего, а признают негодным. Почему? Да просто потому, что надо было по-другому (ибо есть варианты).
Меня интересует как, а как, говорят не многие ... лучше пример напишите, чем трепаться.
Для примера общался я года так 2 назад с руководителем IT некой фирмы.
2 часа разговора о функциях, заданиях, триггерах, транзакциях и т.п. + решение задачек на бумажке ...
И что ты думаешь? Не взяли.
Просто потому, что я никогда не использовал cross apply и не смог правильно на листочке написать решение задачи через этот оператор (вот я сказал зачем он нужен, но нарисовать не смог, ну, руки не помнят ... )
2 б***ь часа ...
Так что, если у вас есть что-то по существу по данному вопросу, то излагайте.