> Базы точно так же оперируют страницами с данными, записями было б слишком дорого.

Базы оперируют блоками ("страницами с данными") только для чтения/записи на носители (читают/пишут один блок за раз, а не построчно). Но внутри блоков они оперируют записями. Транзакции и блокировки в обычных нормальных реляционных БД имеют своей минимальной единицей манипулирования как раз строку (а не блок). Причем некоторые (опять же, нормальные) БД еще являются и версионными (а не строгими чистыми блокировочными) - одна строка может иметь несколько версий для разных транзакций, в зависимости от уровней изоляции этих транзакций. К примеру (для Оракла и его дефолтного уровня изоляции транзакций) - написАл ты очень сложный запрос связав несколько огромных таблиц. Выполняется этот запрос долго, к примеру, 3 минуты. С момента начала выполнения запроса все данные в таблицах должны быть (для запроса) согласованными, иначе ты получишь неверный результат, ибо в течение этих трех минут еще куча других транзакций может закоммитить кучу изменений (и ты бы в начале выполнения запроса читал старые данные, а во второй-третьей минуте - новые свежие данные). Т.е. читать нужно только данные, зафиксированные на момент начала выполнения оператора SELECT (повторюсь, при дефолтном уровне изоляции транзакций в Оракле). В древних БД-блокировочниках для такой согласованности требовалось бы блокировать целиком все таблицы, входящие в запрос (т.е. 3 минуты никто ничего не пишет в эти таблицы). В БД-версионниках никто ничего не блокирует, SELECT выполняется (в случае необходимости) над старыми версиями строки, если она успела измениться и закоммититься другой транзакцией после начала работы селекта. Правда Оракл немного неполноценный, можно получить исключение snapshot too old, но все же. Делать подобные механизмы БД опираясь на представленный в статье функционал файловой системы - как-то по-детски, от непонимания внутренних алгоритмов работы БД и уровней изоляции транзакций. Вам там ссылку оставили, про эти сами уровни, читайте.