AkinaPS. Конечно, поле валидности кажется лишним - валидность можно формально определять по максимальности штампа времени. Но это более "тяжёлое" по нагрузке решение. Впрочем, для непакетных, чисто интерактивных, работ с данными вполне возможно и такое решение.

я бы предложил не валидность, и клиенту следить не менялись ли данные....про последнее как???? чтобы клиент не сделал, он либо не гарантирует что данные пока он думал не поменялись, либо этот процес думанья при активной блокировке приведёт к подвисанию всех процесов которые ждут освобождение этого лока.


в субд добавить поле, аля хеш или любая другая юник фигня, которая тригером меняеться при каждом изменении данных тип датавремя с автообновлением...для высоких нагрузок где в секунду может пройти несколько изменений не очень хорош.

и изменения делать по другому

Апдейт трали вали ГДЕ допол_хеш_юник_или_както_так_поле = заданой величине.

если запись менялась пока мы телились, обновление не произойдёт, ибо хеш не совпадёт.

но это путь, когда нам надо логика

если петя хочет менять, то нельзя менять, если петя видел более старые данные чем на момент изменения.

ЗЫ
пример, есть поле зашифрованая величина, и хеш этой величины.

петя щитал значение ШИФР(мой пароль) и ХЕШ(мой пароль)
поставил новый пароль - новый1пароль, за это время вася тоже менял этот же пароль - поставив новый2пароль.

если последним менял петя, то петин и будет активный...противоречия в данных нету.
нам важно лишь чтобы зашифрованное значение и хеш были от одной и тойже строки.

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