ACID в бд тонкости терминологии

Acid это просто требования к транзакциям которые должна гарантировать субд?

Да.

C -тут же решает разработчик а не субд

см. Констрейнты

I -тоже решает разработчик,

Английскую wiki открой, там лучше написано:

Transactions are often executed concurrently (e.g., multiple transactions reading and writing to a table at the same time). Isolation ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially.

Если ты начал чтение данных до того как в базу внесли изменения то даже если в параллельной сессии часть данных удалят тебя это не должно затронуть.
Например так работает частичная загрузка данных. В драйверах реляционных баз обычно есть параметр featch size, он задает сколько данных нужно передать от СУБД клиенту за раз, например результат может быть на миллиард строк, а клиента интересуют первые 10, в общем не гигабайт же отдавать. И вот тут и нужна Isolation, мы начали вытягивать данные, в этот момент кто-то поменял содержимое таблиц, но СУБД продолжает поставлять данные такими какие они были в момент нашего запроса.

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

Получается acid это требования в транзакциям или свойства транзакций причём A и D реализует субд автоматически

Что значит «автоматически» в твоём понимании?

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

А вот в моем понимании Согласованность(C) и Изолированность(I) не лежит только на СУБД, а зависит от разработчика. Разработчик может реализовать неправильную бизнес логику и база будет в несогласованном состоянии. Изолированность(I) тоже может не выполнится. Суть его изначально такая: на результат транзакции не должны влиять другие транзакции. Неправильно выбрали уровень изоляции и это требование не выполнилось.

C -тут же решает разработчик а не субд

см. Констрейнты

Про ограничения разработчик может забыть или вообще напортачить с бизнес-логикой и в результате база будет в несогласованном состоянии. Я к тому, что Согласованность(C) выполняется СУБД только если разработчик реализовал верно бизнес-логику.

Английскую wiki открой, там лучше написано

Изолированность(I) может быть нарушена если выбран неверный уровень изоляции и тогда это требование в СУБД не выполняется: другие транзакции повлияли на результат текущей транзакции(а этого не должно было быть следуя бизнес-логике).

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

Тут СУБД гарантирует согласованность связанных данных, что ключ не будет ссылаться на пустоту. Что если есть какая-то запись в таблице то и определенные колонки не будут пустые. Т.е. это можно сказать контракт над данными, который дает какие-то гарантии по их согласованности.

С БД часто работает не одна конкретная CRUD, а куча программ и несколько источников данных (в реальных компаниях это так).

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

А вот в моем понимании Согласованность(C) и Изолированность(I) не лежит только на СУБД, а зависит от разработчика.

Этож сколько работы нужно проделать чтоб написать корректный ACID. Я лучше вольюсь готовой СУБД.

Из википедии: Согласованность является более широким понятием. Например, в банковской системе может существовать требование равенства суммы, списываемой с одного счёта, сумме, зачисляемой на другой. Это бизнес-правило и оно не может быть гарантировано только проверками целостности, его должны соблюсти программисты при написании кода транзакций. Если какая-либо транзакция произведёт списание, но не произведёт зачисления, то система останется в некорректном состоянии и свойство согласованности будет нарушено.

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

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

I -тоже решает разработчик, никакие другие транзакции не должны влиять на результат текущей транзакции.

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

Получается acid это требования в транзакциям

Acid - это требования к информационной системе, в частном случае - субд.

А вот в моем понимании

С этим на филфак.

свойство согласованности будет нарушено

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

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

А в MySQL на уровне изоляции read uncommitted свойство (требование) isolation нарушено? На этом уровне же можно читать грязные данные и по сути изоляции никакой нет?

Если выставить transaction-isolation в read uncommitted то да

InnoDB offers all four transaction isolation levels described by the SQL:1992 standard: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, and SERIALIZABLE.

source. Там глава про изоляцию сразу начинается с такой фразы:

the isolation level is the setting that fine-tunes the balance between performance and reliability, consistency, and reproducibility

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

В итоге получается что acid просто требования к транзакциям которые субд рекомендуется выполнять

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

(их выполнение) зависят не только от субд но и от разработчика?

Я тебя не понял. Тебе нужен асид? Вот есть субд, которые дают тебе какой-никакой асид на халяву. Юзай. Зачем ты хочешь прищемить яйца дверью и пытаешься как-то извернуться, чтобы асид просрать? У тебя какая цель?

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

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

Кто понимает транзакции и изоляцию (то есть осмыслил хотя бы на базовом уровне) никогда ACID всерьез обсуждать не будет. Это просто жвачка для тимлид-быдла на собеседованиях, которые спрашивать спрашивают, но сами не понимают.

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

Если на собесе у тебя спрашивают про ACID - имей в виду, они ничего не понимают ни в конкурентном исполнении ни в транзакциях ни в чем.

Если СУБД поддерживает ACID, значит она дает готовый инструмент разработчику для непротиворечивого манипулирования данными. Воспользуется ли разработчик этим инструментом гаммотно - другой вопрос.

ACID - бессмысленный набор

для непротиворечивого манипулирования

непонятно, что ты имелось в виду.

Если СУБД поддерживает ACID, значит она дает готовый инструмент разработчику для непротиворечивого манипулирования данными

нет, не значит.

непонятно, что ты имелось в виду.

Тоже, что и последние 40 лет под этим подразумевается. На множестве данных задается семейство предикатов. Манипуляция с данными непротиворечива, если истинность заданных предикатов не меняется по ее окончании.

ACID - бессмысленный набор

нет, не значит.

Может тебе книжки почитать какие-нибуть?

Может тебе книжки почитать какие-нибуть?

Почитать тебе, так как ты безграмотен совершенно, а гонору много.

ACID - это бессмысленный собачий бред.

Тоже, что и последние 40 лет под этим подразумевается

«Последние 40 лет», C - в ней, бессмысленная буква. Consistency - это бессмысленный термин, который люди хоть минимально понимающие в СУБД стараются не использовать («последние 40 лет»), в контексте где нужна однозначность.

Манипуляция с данными непротиворечива

Это бред какой-то. Если бы сказал «consistency with» что-то конкретное, я тебе зачел это за попытку.

Видимо, ты за пределами одной единственной транзакции, которая инвариант на выходе [не]нарушила ничего больше не знаешь. То есть, по большому счету, не знаешь ничего о транзакция.

И еще «книжки» читать советуешь. Неуч, ЧСВ поубавь.