Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 4 вперед Ctrl→ все |
ptr128 Member Откуда: Moscow Сообщений: 887 |
Я ничего не имею против триггеров. Но у меня претензии к безграмотным кодерам, не понимающим того, что триггер по определению выполняется внутри транзакции. |
||||
26 дек 17, 09:56 [21062179] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9646 |
ptr128, Забавный вы человек :) Сначала пишите фигню: 21060269 Когда вам на это указывают, наезжаете в ответ: 21060985 Потом доказываете то, что вас не просили, да еще и то, что в доказательствах не нуждается: 21061621 Затем отделываетесь общими словами там, где нужна конкретика: 21062179 И за все это требуете извинений. Смешно. |
26 дек 17, 11:20 [21062481] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
а тема то интересная :)
это как же... |
||
26 дек 17, 11:34 [21062546] Ответить | Цитировать Сообщить модератору |
ptr128 Member Откуда: Moscow Сообщений: 887 |
invm, Забавный Вы тролль :) Сначала кривляетесь, по сути, утверждая, что никаких дидлоков не будет.
Потом занимаетесь демагогией, приплетя вдруг триггеры:
Совершенно проигнорировав то, что триггеры употреблялись в совсем другой фразе:
Которая говорит только о том,
Следовательно, пытаться разбить одну большую транзакцию на мелкие, в триггере просто бессмысленно. А когда я доказываю свое утверждение
,даже с триггером, который Вы зачем-то приплели, Вы просто продолжаете хамить совершенно никак не обосновывая своих слов. При этом Вы еще не понимаете, как можно извиняться за откровенное хамство
|
||||||||||||||
26 дек 17, 11:37 [21062553] Ответить | Цитировать Сообщить модератору |
Goga-Gola
Guest |
а в 1C функции типа "ЕстьNull" - это неразумные программисты делали? да и названия там все по-русски и нет проблем.. А объемы продаж говорят сами за себя. Или ваш продукт успешнее? :) |
||
26 дек 17, 11:37 [21062556] Ответить | Цитировать Сообщить модератору |
ptr128 Member Откуда: Moscow Сообщений: 887 |
Чукча не читатель, чукча писатель? 21061621 |
||||
26 дек 17, 11:39 [21062565] Ответить | Цитировать Сообщить модератору |
Jaffar Member Откуда: Сообщений: 633 |
ВСе это чушь. Это же обычная складская задача. Используйте складской подход. Есть историческая таблица с остатками типа: (IDTowar, Date, Count, SUM) и таблица с документами типа IDDOC TypeDoc, DTDOC DeltaCount, Price Sum, и т.п. Документы меняют состояние исторической таблицы с остатками - все остальное ерунда. |
26 дек 17, 11:47 [21062610] Ответить | Цитировать Сообщить модератору |
Jaffar Member Откуда: Сообщений: 633 |
Jaffar, и конечно вся логика будет сосредоточена в триггере на таблицу с документами. с разбивкой по типам и провести / откатить документ. логику можно вынести в процедуры а их внести в триггер. Но лучше приводить исходные параметры документа к универсальному набору, который будет изменять состояние таблицы балансов. |
26 дек 17, 11:50 [21062628] Ответить | Цитировать Сообщить модератору |
Jaffar Member Откуда: Сообщений: 633 |
Jaffar, триггеры рулят потому что только они гарантируют логическую связь данных. |
26 дек 17, 11:52 [21062638] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
не вникая в суть нагенерированного бреда, вперед CREATE TRIGGER TEST_T_TR ON TEST_T AFTER INSERT AS UPDATE T SET QTY=T.QTY+CONVERT(int,RAND()*100) FROM TEST_L T (TABLOCK) JOIN TEST_Q Q ON Q.ID=T.ID AND Q.THREAD=CONVERT(int,RAND()*10) GO |
||||
26 дек 17, 11:57 [21062667] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
в документации есть такое? |
||
26 дек 17, 12:07 [21062710] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9646 |
А утверждение о неприменимости триггеров так и осталось без объяснений... И кто же тут демагогией занимается? И это мы еще не обсуждали
Внимательно перечитывайте собственные сообщения, которые я цитирую, может тогда поймете о чем речь. Заодно найдете в одном из них порожденную вами же связь между триггером и дедлоком. Впрочем, дискутировать с вами бестолку - ошибок не признаете и слишком заняты самолюбованием... |
||||||||
26 дек 17, 12:09 [21062716] Ответить | Цитировать Сообщить модератору |
ptr128 Member Откуда: Moscow Сообщений: 887 |
Ну Вы достаточно ёмко и самокритично озаглавили свой пост. Но я все же разберу его
Во-первых, начнем с того, что есть не таблица с документами, а, как минимум, две таблицы - заголовок документа и его строки. Во-вторых, просто обновить агрегированные количества одним запросом нельзя, так попытка
Что доказано тут 21061621
подразумевают, следующий механизм. 1. В каждой строке документа у нас есть флаг, который мы выставляем в 1 в случае успешного резервирования. В заголовке документа имеем так же флаг проведения всего документа или, что чаще встречается, факт проведения отражается совсем в другой таблице. 2. В таблице агрегатов имеем не только актуальный остаток, но еще и зарезервированное количество. Доступное количество рассчитывается как их разность. 3. По каждой строке документа отдельной транзакцией выполняется резервирование (увеличение зарезервированного количества) с проверкой того, хватает ли для этого доступного количества. В той же транзакции в строке устанавливается флаг резервирования. 4. Если резервирование всех строк прошло успешно, то есть доступного количества хватило для всех позиций в документе, мы опять, по каждой строке документа отдельной транзакцией выполняем уменьшение актуального количества, зарезервированного количества и сбрасываем флаг резервирования в строке. 5. Если резервирование хотя бы для одной строки не удалось, то мы снова, по каждой строке документа, в которой установлен флаг резервирования, отдельной транзакцией, уменьшаем зарезервированное количество и сбрасываем флаг резервирования. 6. Механизм логической транзакции и средства восстановления после сбоя я тут опускаю, хотя их реализация обязательна. |
||||||||
26 дек 17, 12:09 [21062720] Ответить | Цитировать Сообщить модератору |
Cammomile Member Откуда: Сообщений: 1214 |
Рукожопое поделие, удачно зашедшее в нищем пост-совке. У предприятий уже был спрос на автоматизацию бизнеса, но еще не было денег ни на обучение специалистов, ни на западный продукт, ни опыта внедрения.А тут еще и чрезвычайно низкий порог вхождения быдлокодеров был обеспечен как раз тем, что вместо английского, который надо учить и понимать, можно было писать ПосчитатьНакладная(документ, цена). А теперь, дружок, марш в гугел с запросом "Best CRM Software 2016" (или 2017) и найди мне там 1С хотя бы в топе 20... |
||
26 дек 17, 12:25 [21062770] Ответить | Цитировать Сообщить модератору |
Goga-Gola
Guest |
Cammomile, еще один "Мэтр" с уровнем общения младшего школьника... назови свое творение, я поищу его в списке ТОР 2000000.... |
26 дек 17, 12:37 [21062813] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
то как портирован 1С на ms SQL это полная жопа, и тут не надо даже доказывать - отгулите десятки тем с производительностью даже на этом форуме. + оптимизация всего этого только через ресурсы систем, в итоге колхоз со 100 комбайнёрами работает на топовых серверах, с комментарием by design |
||
26 дек 17, 12:43 [21062829] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9646 |
|
||
26 дек 17, 12:45 [21062843] Ответить | Цитировать Сообщить модератору |
ptr128 Member Откуда: Moscow Сообщений: 887 |
Задайте конкретный вопрос - получите конкретный ответ. А мне Ваша логика совершенно непонятна и Вы ее нигде еще не озвучили.
Ну я думал, что Вы хоть немного в теме. Впрочем это явно выходит за рамки простых задач, как у ТС, потому будем считать для Вас простительным. 1. Обновление нескольких записей одной таблицы в произвольном порядке в пределах одной транзакции гарантировано приводит к дидлоку. Вопрос только в количестве записей, количестве пользователей и во времени, когда это произойдет. 2. Обновлять записи в таблице всегда в одном порядке не позволяет сам синтаксис UPDATE. 3. Блокировать всю таблицу, в которой обновляются записи, не применимо с точки зрения производительности системы. 4. Остается только единственный путь - разбить одну транзакцию на множество мелких, что не возможно сделать внутри триггера, так как любой триггер всегда выполняется уже внутри транзакции. Вывод: если для избежания дидлоков одну большую транзакцию необходимо разбить на несколько мелких, то в триггере это сделать не возможно.
И к чему? К тому что пользователь, построивший отчет в тот момент, когда выполняется постинг увидит, что часть количеств уже списалась, а часть нет? И на что это повлияет? А что было бы, если бы пользователь построил отчет на секунду раньше, еще до начала постинга? Или на секунду позже, после завершения постинга? У Вас страхи совершенно детские и абстрактные. Вам Ваши способности даже не позволяют их конкретизировать )))
Пожалуйста, не лгите так нагло. Или скриншот сюда. |
||||||||||
26 дек 17, 12:52 [21062873] Ответить | Цитировать Сообщить модератору |
Cammomile Member Откуда: Сообщений: 1214 |
Ну, мои творения, как правило, это внутренний корпоративный софт топовых РФ (и не только рф) контор. Я, вроде бы, нигде не указывал, что разрабатываю коммерческие ЦРМ на продажу. Так, что не вижу, поводов тыкать мне тут "покажи свое". |
||
26 дек 17, 13:01 [21062896] Ответить | Цитировать Сообщить модератору |
ptr128 Member Откуда: Moscow Сообщений: 887 |
Именно так. Потому что, по умолчанию, на SQL сервере транзакции в дидлоке сидят до 5(!) секунд. Так как при этом данные транзакции могут блокировать еще ряд других процессов, то такой подход может приводить к зависаниям на эти 5 секунд вообще всей системы. Я даже не знаю области применения такого решения, чтобы заказчик не вытряс душу из техподдержки. |
||
26 дек 17, 13:06 [21062922] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9646 |
Мда...
Состав транзакции определяется бизнес-требованиями, а не капризами разработчика. Если требования предписывают необходимость обработки множества строк в одной транзакции, то так и должно быть сделано. А возникновение при этом дедлока - побочный эффект, обработку которого грамотный роазработчик обязан предусмотреть. Но, похоже, что "грамотный" - это не про вас. |
||||||
26 дек 17, 13:17 [21062951] Ответить | Цитировать Сообщить модератору |
ptr128 Member Откуда: Moscow Сообщений: 887 |
Предложите свое "грамотное" решение. Или только флудить в состоянии? |
||
26 дек 17, 13:18 [21062957] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
ptr128, ладно, блокировать мы боимя, индексы создавать можно на твой афигенный аргумент? CREATE NONCLUSTERED INDEX IxTemp ON TEST_Q (THREAD,ID) и да все взрослые дба говорят абсолютно одно и то же, дедлоки будут, главное их контролировать и не генерировать специально как вы |
26 дек 17, 13:19 [21062963] Ответить | Цитировать Сообщить модератору |
ptr128 Member Откуда: Moscow Сообщений: 887 |
Давно так не ржал. Еще и коллег повеселил ))) Бизнес-требование, если это, конечно, не заказной тендер, не то что состав транзакции не ограничивает, а даже платформу и программный продукт. Клиенту важен результат, а как его разработчик добился - его интересует исключительно только с той точки зрения, за сколько часов разработчика ему акт выставили. |
||
26 дек 17, 13:23 [21062990] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9646 |
Попытайтесь осознать, что дедлоки - нормальный продукт жизнедеятельности многопользовательского окружения.
|
||||
26 дек 17, 13:24 [21062994] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 4 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |