Решается ли вопрос поддержки актуальности данных в вебе?
==========================================================

 В вебе традиционно забивается на синхронизацию данных - так я думаю.  

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

Особенно это задевает такие подходы как DDD: там "все в памяти".  

Ситуация ухудшается при работе с API. Данные вообще становятся одноразовыми.  
  

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

И нигде никогда не видел чтобы было сообщение что форма под редактированием. Хотя нет, есть исключение - сервисы типа GDocs.  

Пример:  

> В форме 10 полей. 1,2,3 изменил оператор А, 3,4,5 изменил оператор Б.  
> 
> В базу пойдет 1,2,3 [какая версия пришла второй], 4,5.

  
  

Проблема эта видится более глубокой чем кажется. И она не решается. Так ли это? 

 Вариантов масса:  

1. Пишем самый новый поверх старого (rewrite всей записи целиком).  

2. Обновляем только изменившиеся поля в записи (а не все подряд), (пустые поля - считаем как не изменившиеся, для удаления данных в полях используется отдельная функция).  

3. При начале редактирования - ставим "семафор" (в БД, например: "isLocked" - boolean и "LockedBy" - ID того, кто захватил ), что поле "захвачено" другим пользователем и блокируем попытку изменения с флагом ReadOnly. 

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

  
  

Нет.  

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

Другое дело, что, скажем, обновление лайков вполне можно сделать без поддержки строгого учета данных. Какая разница - увидит Маша на один лайк раньше, чем Саша. Или Саша будет первым.  
  

А такие вещи как работы с платежами в том числе и в вебе делаются строго. Ну если программист компетентен.  
  

UPD:  

> Пример:  
>   
> 
>  В форме 10 полей. 1,2,3 изменил оператор А, 3,4,5 изменил оператор Б.  
> 
>  В базу пойдет 1,2,3 [какая версия пришла второй], 4,5.  
>   
> 
> Проблема эта видится более глубокой чем кажется. И она не решается. Так ли это? 

  
  

Она и не должна решаться сама собой.  
  
**Ситуации - индивидуальны**  

В одном случае можно позволить редактировать поля независимо.   

В другом - поля редактируются только вместе.  

В третьем - вообще наплевать, главное максимально низкая стоимость разработки.  
  
**Как именно поступать в конкретном случае - решайте совместно с заказчиком.**  
  

Опытному разработчику **потому много и платят, что он все эти косяки способен предвидеть и предложить пути решения**. А вовсе не за то, что он быстрее код набивает и больше for и if в единицу времени напишет.  
  

Это вовсе не проблема. Рядовая типовая повседневная задача.  

Другое дело, что ее решать как правило и не нужно в вебе состоящим из бложиков да соц. сетей. 

> В вебе традиционно забивается на синхронизацию данных - так я думаю.

  

Здравствуйте:  
* [https://en.wikipedia.org/wiki/Optimistic\_concurren...](https://en.wikipedia.org/wiki/Optimistic_concurrency_control)
* [https://developer.mozilla.org/en-US/docs/Web/HTTP/...](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/409)
* [fideloper.com/etags-and-optimistic-concurrency-control](http://fideloper.com/etags-and-optimistic-concurrency-control)

  

Так что да - проблема глубокая, глобальная, встречается в большинстве многопользовательских информационных систем и **уже довольно неплохо проработана на разных уровнях** - от различного уровня изоляции транзакций в БД, до высокоуровневых механизмов в том же HTTP (см. ссылке выше). То что вы так думаете - это вы просто ещё не сталкивались, т.к да, **многие** в своих относительно примитивных веб-задачах забивают на проработку этих вопросов.  
  

А если вам гугл-докс, так это уже куда более сложные материи, см. [Operational transformation](https://en.wikipedia.org/wiki/Operational_transformation) и [CRDT](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type). 

 Если я правильно понимаю о чем вы, то вы несколько путаете теплое с мягким.  
  

> Проще говоря: открывается форма разными людьми и сохраняется с новыми данными. Хороший вопрос - "что будет".

В зависимости от того как устоено хранение данных будет либо две версии, либо последняя по времени, либо объединение двух этих версий, либо вообще ошибка и откат, либо самоуничтожение всей системы термитными шашками.  
  

Вот как вы напишете - так и будет. И это не только в вебе. Можете открыть один txt файл двумя виндовыми блоконотами и поредактировать.  
  

Большинство идет по самому простому пути - последняя по времени. Но **большинство != все**. Как вы верно заметили, и в гуглдокс и в некоторых других системах эта проблема решается тем или иным способом. А универсальной пилюли на все случаи нет. 

> Проблема эта видится более глубокой чем кажется. И она не решается. Так ли это?

  

сейчас придет какой-нить хардкорный функциональщик и расскажет вам шо почем Ж)  

и про состояния  

и про немутабельные данные  

и тд