Denis Trunin's Blogs: Blocking in D365FO(and why you shouldn't always follow MS recommendations)

[Vadik]

Цитата:

Сообщение от Pandasama

А вот тут можно подробнее, почему одинаково (пусть это уже и оффтоп)?

Веронятно потому что в кэш (CacheLookup=Found) что-то кроме AccountNum положить надо? И потом как-то резолвить из него

Цитата:

Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля

Best practices это же не религиозные догмы, и мы инженеры а не последователи культа. Это рекомендации, их нужно понимать, применять осознанно и проверять. Я не сталкивался с ситуациями где такая оптимизация в моем коде что-то решала бы (по крайней мере там где нет массивных BLOB-ов хранящихся в базе данных). С Azure SQL это мне кажется еще менее актуально, тут скорее латентность и geographic redundancy кроют пропускную способность как бык овцу

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