Pull to refresh

Comments 9

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

Теоретически, это любые новостные онлайн-медиа


Почему новостные? Это вообще любое веб приложение с формой для редактирования данных.
А вот эта функция — не чистая, но идемпотентная (прошу не делать выводов о том, как я пишу код, по этим кускам):
def insert_data(insert_query: str, db_connection: DbConnectionType) -> int:
db_connection.execute(insert_query)
return True

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


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

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


Когда пользователи обновляют лишь некие свои приватные данные.

Когда пользователи вообще не обновляют данные, а только дополняют новыми (append).

Когда бизнес-логика не определяет необходимость некоего порядка выполнения транзакций.

В этих случаях вы, вообще говоря, хотите консистентности от БД. Вы не хотите линейной истории, потому что вам не важен порядок транзакций, и в ряде случаев можно говорить о eventual consistency, если потеря данных допустима.


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

UFO just landed and posted this here
Ну так это уже и есть перекладывания ACID на уровень приложения.
Ничего не мешает, и подобное давно используется на практике. Гуглить в сторону Insert-Only Database, Temporal Database, Event Sourcing, а там уже от конкретных требований дальше видно будет.
активное использование constraints от БД означает перекладывание ответственности за данные (а также частичное перекладывание бизнес-логики, если мы говорим о таком constraint, как “CHECK”) с приложения на БД

Как будто что-то плохое
Сейчас модно ругать использование базы данных в качестве базы данных, привыкайте.
Хорошо сказано) Плюсанул если б мог)
Спасибо за статью. Я хоть и не разработчик, но почерпнул для себя много полезного.
Sign up to leave a comment.

Articles