Теоретический вопрос

[Kotъ-Begemotъ]

Заранее прошу прощения, может быть вопрос вызван недопониманием, но вот какое дело:
В базе версии записей хранятся в виде "дельты", так? Вот скажем есть таблица из 20 полей. Делается апдейт ОДНОГО поля. Новая версия (вернее "дельта") будет состоять только из информации по ЭТОМУ полю?
К чему я это спрашиваю - возможно ли теоретически сделать следующее - если пользователи обновляют ОДНУ и ту же запись, но РАЗНЫЕ поля, не получать конфликта, а корректно учитывать изменения каждого, и выдавать ошибку блокировки толко если эти изменения "пересекаются" по какому-то полю? Ну, скажем для транзакций read_committed конечно. Чисто теоретически?

[hvlad]

Заранее прошу прощения, может быть вопрос вызван недопониманием, но вот какое дело:
В базе версии записей хранятся в виде "дельты", так? Вот скажем есть таблица из 20 полей. Делается апдейт ОДНОГО поля. Новая версия (вернее "дельта") будет состоять только из информации по ЭТОМУ полю?

Не совсем так. Уровню работы со страницами данных начхать на структуру записей, он про поля ничего не знает. Есть две версии записи - исходная и новая. Новая хранится целиком (в сжатом виде есс-но), исходная - как дельта, применяемая к новой. Дельта есть закодированная разница двух байтовых потоков.

К чему я это спрашиваю - возможно ли теоретически сделать следующее - если пользователи обновляют ОДНУ и ту же запись, но РАЗНЫЕ поля, не получать конфликта, а корректно учитывать изменения каждого, и выдавать ошибку блокировки толко если эти изменения "пересекаются" по какому-то полю? Ну, скажем для транзакций read_committed конечно. Чисто теоретически?

Нет. И способ хранения записей тут абсолютно не при чём.

Если запись настолько не целостна, что разные её поля допустимо (постановкой прикладной задачи) редактировать одновременно разными пользователями, то это явная ошибка проектирования и данные поля должны относиться к разным таблицам

[Kotъ-Begemotъ]

Не совсем так. Уровню работы со страницами данных начхать на структуру записей, он про поля ничего не знает. Есть две версии записи - исходная и новая. Новая хранится целиком (в сжатом виде есс-но), исходная - как дельта, применяемая к новой. Дельта есть закодированная разница двух байтовых потоков.

Ага, понятно с этим - раз байтовые потоки и нет никакой информации о полях, то конечно такого не сделать в принципе, ясно, спасибо за разъяснения.

Если запись настолько не целостна, что разные её поля допустимо (постановкой прикладной задачи) редактировать одновременно разными пользователями, то это явная ошибка проектирования и данные поля должны относиться к разным таблицам

А вот с этим не могу не согласиться! Типичный пример - диспетчер принявший заказ замечает в нём ошибку и пытается исправить. В это время заказ уже "пошёл в работу" то есть как раз поступает на выполнение... Другое дело что программно это можно обработать, но сам факт - ситуация ведь возможная?

[hvlad]

Если запись настолько не целостна, что разные её поля допустимо (постановкой прикладной задачи) редактировать одновременно разными пользователями, то это явная ошибка проектирования и данные поля должны относиться к разным таблицам

А вот с этим не могу не согласиться!

Т.е. - согласен

Типичный пример - диспетчер принявший заказ замечает в нём ошибку и пытается исправить. В это время заказ уже "пошёл в работу" то есть как раз поступает на выполнение... Другое дело что программно это можно обработать, но сам факт - ситуация ведь возможная?

И что реально пойдёт на выполнение ? Исправленный заказ или нет ? И как исполнитель об этом узнает ?

В данном случае я бы сказал, что постановка задачи (как обычно), не допускает одновременного редактирования разных частей заказа

[Kotъ-Begemotъ]

Т.е. - согласен

Ну очепятался, заработался совсем )) Пора за пивом идти видимо ))

И что реально пойдёт на выполнение ? Исправленный заказ или нет ? И как исполнитель об этом узнает ?
В данном случае я бы сказал, что постановка задачи (как обычно), не допускает одновременного редактирования разных частей заказа

Ну это уже другие вопросы Я просто к тому, что подобное МОЖЕТ случиться, и вовсе не обязательно это неграмотный подход к проектированию. Просто надо предусматривать такие варианты В общем да, различные части заказа (да и любого документа) как правило редактировать просто не стОит, потому как бардак будет. Тут уже надо какой-то версионный механизм, да еще с персонификацией - кто, когда, в какую часть документа пытался что-то вносить... В случае скажем большого договора, который бригада юристов жуёт ))