|
su.dbms.sql- SU.DBMS.SQL ------------------------------------------------------------------ From : Dmitry Shykhman 2:468/13.32 14 Mar 2001 23:02:07 To : Pavel Kingsep Subject : Проблема с бо льшими таблицами -------------------------------------------------------------------------------- 07 Mar 01 14:27, you wrote to me: DS>> Hегоже плодить конфликты. PK> ...лучше оставить их на "потом"... Пусть обновление потеряется... Лучше их не допускать. По логике задачи. А если невозможно - кто мешает перечитать запись и повторить изменения? Если изменения реально конфликтуют - спросить пользователя, если нет (правились разные поля или правки можно свести автоматом) - повторить без спроса. В большинстве случаев (imho) проблему потерянных изменений можно либо игнорировать, либо исключить _без_ длительных блокировок. DS>> И уж всяко не держать часами открытые транзакции. PK> Кому оно мешает? Только попытке записи в эту строку. Каковая запись может быть гораздо важнее, чем та, из-за которой её нельзя будет выполнить. А работничек пошёл курить и с концами. И срывается важный контракт :\ PK> Хорошо, давай посмотрим на это так - SELECT FOR UPDATE используется PK> для гарантирования того, что в период между чтением записи и её PK> модификацией она не изменится. Правильно. И этот период должен быть максимально коротким и не содержать действий непредсказуемых по времени, скажем, взаимодействия с юзером. Hапример: тебе надо исправить количество товара? юзер вводит _разницу_, и только тогда ты делаешь свой селект фор апдейт, правишь, и закрываешь транзакцию. PK> Если мне *нужно* именно такое поведение PK> - все принципы идут лесом. "Hет ничего практичнее хорошей теории" (С) кто-то из зубров, кажется Бор Сначала надо хорошо подумать, а точно ли именно это поведение (во всех проявлениях) тебе нужно? PK> JFYI, в одной из програм мне нужна была PK> сериализация транзакций - а это сильнее SELECT FOR UPDATE. И я её PK> сделал, так как она *была нужна*. Бывает. Мне, правда, таких задач не попадалось. Dmitry --- GoldED+/W32 1.1.4.4 * Origin: Lasciate ogni speranza (2:468/13.32) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms.sql/27613aafd409.html, оценка из 5, голосов 10
|