oleg_ru

изменив одно из значений в нем, для сохранения изменений мы должны перезаписать весь файл целиком.

С файлами работает файловая система, и именно она определяет что именно и где будет перезаписано при изменении данных.
Если вы отредактировали одно значение - изменившиеся данные запишутся в другое место.
Объем записи данных будет несколько больше того что вы отредактировали - это зависит от размера кластера.

Если мы имеем таблицу settings в базе данных и меняем одну строку в ней, физически перезапишется только эта строка или вся эта таблица?

Перезапишется только эта строка.
Остальные строки останутся неизменными.
Даже если вы удалите строку - она просто помечается на удаление, но строки что за ней никак не сдвинутся и не перезапишутся

Все зависит от размера этого файла, и главное, нужны ли вам атомарные транзакции (это нужно для многопользовательского доступа на запись и чтение), так как при их использовании накладные расходы на запись в базе данных ЗНАЧИТЕЛЬНО увеличиваются, и возможно до 4-8килобайт (1 экстент файловой системы) эффективнее хранить и перезаписывать файл в чистом виде без базы данных (правда придется следить за блокировками самому).

Если у вас только чтение - то без каких либо вариантов работа со своим файлом (не обязательно json, интереснее хранить в виде php кода, чтобы сохранить данные в этом виде пользуйтесь var_dump/var_export, это самый быстрый и эффективный по загрузке процессора). даже сотня килобайт в своем файле может оказаться эффективнее хранения словарей в базе данных, тем более он отлично будет закеширован на уровне OS.

Неудобство хранения словарей в файле - это не единообразный метод работы с данными, если часть данных у вас в БД а часть в файлах, вам придется поддерживать оба способа а не только один.

Если мы имеем таблицу settings в базе данных и меняем одну строку в ней, физически перезапишется только эта строка или вся эта таблица?

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

мы должны перезаписать весь файл целиком

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

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

Однако, с практической точки зрения, важно смотреть не на износ, а на быстродействие. СУБД, например, хранит числа в двоичном представлении, в то время как JSON, XML и прочая требуют преобразования чисел в строки и наоборот при каждой записи и чтении, что естественно, создает дополнительные тормоза и обогрев атмосферы.

Проектировать ПО с учетом возможного износа накопителей данных - это уже попытка учесть эффекты третьего порядка (первый порядок - ПО работает с ошибками, второй порядок - работает правильно но медленно, третий - работает быстро и правильно, но создает косвенные затраты на оборудование), что имеет мало практического смысла.

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