Comments 9
Когда пользователи будут пребывать на одной и той же веб-странице или окне приложения несколько секунд или даже минут, и поэтому они так или иначе будут видеть устаревшие данные.
Теоретически, это любые новостные онлайн-медиа
Почему новостные? Это вообще любое веб приложение с формой для редактирования данных.
А вот эта функция — не чистая, но идемпотентная (прошу не делать выводов о том, как я пишу код, по этим кускам):
def insert_data(insert_query: str, db_connection: DbConnectionType) -> int: db_connection.execute(insert_query) return True
В общем случае эта функция не идемпотентная, т.к. при ряде запросов на добавление строк они могут начать дублироваться. Например, если вы используете автоинкремент для колонки первичного ключа.
Когда пользователи будут пребывать на одной и той же веб-странице или окне приложения несколько секунд или даже минут, и поэтому они так или иначе будут видеть устаревшие данные.
Пользователи иногда умеют рефрешить страницу и делиться ссылками, при этом они ожидают, что со страницы ничего не будет пропадать, а только добавляться новые новости/статьи. Так что тут пример более узкий — это лента фейсбука/вк, когда пользователь заранее не знает, что там будет, и готов к тому, что она поменяется после рефреша.
Когда пользователи обновляют лишь некие свои приватные данные.
Когда пользователи вообще не обновляют данные, а только дополняют новыми (append).
Когда бизнес-логика не определяет необходимость некоего порядка выполнения транзакций.
В этих случаях вы, вообще говоря, хотите консистентности от БД. Вы не хотите линейной истории, потому что вам не важен порядок транзакций, и в ряде случаев можно говорить о eventual consistency, если потеря данных допустима.
Я бы сказал так: вы можете достаточно смело отказаться от консистентности в том случае, когда пользователь системы не может доподлинно проверить её поведение. Например, счётчик лайков для видеоролика на ютубе: лайк каждого из пользователей анонимен, видят все только сумму, и знают про антифрод, который эти лайки может срезать.
активное использование constraints от БД означает перекладывание ответственности за данные (а также частичное перекладывание бизнес-логики, если мы говорим о таком constraint, как “CHECK”) с приложения на БД
Как будто что-то плохое
Как бы я сейчас объяснил молодому себе… зачем существуют требования ACID для баз данных?