«О бухгалтерии. Часть 13. Алгоритмы.»

­­­­­­­­­Обещанное про противоречие в понятии "транзакция". Было написано:
"Транзакция - это последовательность операций, которая ОБЯЗАТЕЛЬНО должна завершиться..."
Кто кому где должен. Если операции как-то особенно должны выполниться по смыслу задачи, то это дело самой задачи (ЕЁ алгоритма решения), а не универсального независимого от конкретных задач движка базы данных, в котором "поддерживаются транзакции".
То есть свою задачу организовать операции так, чтобы они не разрушали данные, мы надеемся переложить на инструмент, авось он "поддержит".
Лучше всего придумать такой алгоритм, чтобы было поменьше потенциальных ситуаций разрушения данных.
Помощь в этой работе даёт сама возможность таких ситуаций.  В самом деле, класссическая "двойная запись", с которой мы начали рассказы, придумана именно как противодействие простым понятным ситуациям: что-то не записали; записанное разрушено. 
Притом придумано конкретное решение. А запишем в два места, с возможностью контроля, не разрушено ли кое-что из записанного.
Тут у нас в связи с появлением компьютера(?) стали появляться какие-то непростые непонятные ситуации потери целостности базы данных, умные понятия, да и сами Базы Данных. Новая сущность появилась со времён Паччоли, "Базы Данных", или СУБД. (Мне сказали, что это название устарело. Ещё лучше, уже и новое название, а то и развитие сущности. Плодятся сущности, не относящиеся к задачам, как грибы:)

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

РЕАЛЬНЫЕ новые сложности могут быть прежде всего количественные. Например, сбор данных с многих кассовых аппаратов; продажа билетов на транспорт; денежные переводы; доставка в разные места многих товаров... Или вообще что-то не бухгалтерское.
Я сторонник такого подхода: сосредоточиваемся на самой задаче, а она хоть и не решаема EXCELем, но в принципе проста и локальна. (Уж если мы ПОНЯЛИ, почему именно она не решается EXCELем). Соответственно, пишем конкретную программу (очень конкретную, небольшую по принципу построения, а чаще и по обьему), которая именно эту конкретную задачу решает. Пишем сами, а не "берём" то или то.

Возвращаясь к теме предыдущего рассказа, всё-таки можно "взять" готовое. Что именно в какой задаче точно, проверенно работает, это тема нашего отдельного семинара "в реале", построенного как обмен опытом разработчиков. Делать "как все" или согласно рекламе точно не стоит. То есть ЕСЛИ готовое ТОЧНО годится, берем его. Если же что-то где-то слышали, лучше - пишем программу сами.

При этом, если ближе к технике, есть смысл записывать данные не в "базу", а в файлы, поддерживаемые языком программирования и операционкой. Соотносить же их с "базами" будем только при надобности нефиксированных запросов, на другом структурном уровне.

При этом помним, что "базы данных" на самом деле, если их открыть в двоичном редакторе, это такие же файлы, разве что, может быть, сделанные вполне профессионально. Нагнали пургу, что они что-то сверхьестественное. Видим файл, в котором таблица (даже видны данные), а в начале видим дескриптор (даже видны имена столбцов). Это хотя бы можно починить руками! Ещё того хуже, видим файл, в котором запакованы данные сразу нескольких таблиц, ну хоть дескрипторы можно увидеть, а данные - никак. (Этот случай - наиболее типичный). Что здесь хуже, что лучше, из одних только этих наблюдений заключить невозможно. Есть форматы файлов БД, где каждая таблица в отдельном файле, и можно прочитать глазами и починить руками (DBF PRG). Но при этом файлы часто сами разрушаются. Есть очень похожие с виду форматы, где ничего никогда не разрушается, и работает в сто раз быстрее тех (DAT Clarion DOS). Есть файлы MDB из ACCESS, в которых с виду ничего не разберёшь (в одном файле физическая + логическая база данных из многих таблиц), но вроде как их и чинить незачем, потому что тоже не разрушаются. А что там насчёт файлов MS SQL Server, я и не знаю:) сам не проверял - это вы мне расскажете, а я буду на вас смотреть и прикидывать, верить или нет :)

Всё зависит от профессионализма разработчиков программы. Ну так на то и вы тоже программисты...

Вот кстати насчёт понимания транзакций как локального механизма, про который писали в предыдущей главе. Хорошо, но на самом нижнем уровне данные всё равно записываются в файл ОС. Как правило, это древний  файл C, в котором запись возможна лишь в конец, притом конец определяется символом "конец файла". Кусочки файла размещены в разных местах носителя, где именно кусочки расположены - это записано в дескрипторах. (Не считая экзотики вроде дисковых массивов, и то, как правило, лишь обещанной:).
И теперь имеем ситуацию, когда символ конца файла не записан. Или записан, а дескриптор (он тоже в нескольких местах дублирован и журналирован) - дескриптор где-то :) корректно не обновлён. Вот где нам помогли бы транзакции :).
Но как правило, не разрушается. Так устроен сам диск.

Вот наша задача, как разработчиков, свести ненадёжность нашей базы данных до ненадёжности файловой системы ОС. То есть чтобы сверх принципиальных несовершенств ОС от нас новых чтобы не поступало.

Примерно то же самое происходит с управлением памятью. Можно исхитриться, где-то как-то разыскав подходящий язык програмирования и 64-битную машину с линейной адресацией, поддерживаемой и языком программироования,и ОС, иметь в программе массив размером сто тысяч на сто тысяч чисел с плавающей точкой или безразмерный, и адресоваться свободно как A[i,j]. При этом рассчитывая на механизмы виртуальной памяти и кэширования, поддерживаемые ОС.
А можно чуть-чуть подумать, и обойтись "окном" 10 на 10, которое будет "ездить" по нашему собственному файлу, где хранится эта матрица, без всяких глюков оси...

При этом во встраиваемых системах может быть 8-битный процессор с 32К памяти, без умножения. Может быть, даже, специализированный процессор.

Продолжение следует. В продолжении - технические частности обмена данными между программами; техника работы в ситуации "сам не проверял", но оно на нём написано.