Я использую их следующим образом:
Простой текст
Если эта категория включает несколько более сложные форматы, такие как YAML или файлы свойств, то это лучший вариант для всего, что вы ожидаете от людей, которые будут читать и редактировать вручную. Еще одним огромным преимуществом является простота его изменения с помощью небольшого скрипта (например, sed).
Ничто не сравнится с простотой и удобством использования. Когда команде поддержки нужно что-то настроить на удаленном компьютере (например, решить проблему клиента) или ИТ-отделу необходимо перенастроить группу серверов, на которых работает ваше программное обеспечение, они будут благодарны вам за выбор этого формата. Это также избавит вас от написания какого-то одноразового программного обеспечения, которое делает это для них.
XML
Я согласен с @Ingo здесь - в отличие от обычного текста XML труднее обрабатывать с помощью сценариев, и кошмарно редактировать вручную imo.
Тем не менее, если у вас есть данные с какой-то сложной структурой, в которой YAML становится не поддающимся расшифровке, и все же хотите, чтобы они были удобочитаемыми и редактируемыми, то XML, вероятно, является лучшим выбором.
Реляционная база данных
Отличный выбор для случаев, когда у вас есть много данных (которые могут сделать простой текст и XML громоздкими), которые вы все еще можете разрешить сторонним редакторам редактировать вручную - с помощью команд SQL и даже графического интерфейса.
Еще одним преимуществом является то, что ваш код, который управляет содержимым, очень удобочитаем. @ Ричард-Харрисон дал хороший список других преимуществ в своем превосходном ответе.
База данных NoSQL
Одним из преимуществ СУРБД является масштабируемость за счет распространения, что, вероятно, не очень важно для вашего вопроса. Преимущества, которые, вероятно, более актуальны, - это простота хранилища значений ключей и гибкость отсутствия схемы (это слово?). Когда вы обнаружите, что нарушаете реляционную парадигму: просто храните двоичные объекты в базе данных, обращайтесь к ним по ключу и обрабатывайте их с помощью кода, затем рассмотрите этот вариант. Некоторые варианты (например, CouchDB) очень переносимы, имеют небольшую площадь и могут также масштабироваться, поэтому они предлагают хорошую нереляционную альтернативу MySQL и SQLite.
двоичный
Преимущество двоичного кода в том, что он быстрый и компактный. Если единственное, что нужно для чтения и изменения вашего файла - это программа, а данные не соответствуют реляционной парадигме или скорости, это действительно важно, тогда это может быть хорошим выбором. Вероятно, лучше всего подходит для медиа-файлов.
Я должен отметить, что мне еще не приходилось сталкиваться со случаем, когда в какой-то момент простой доступ к программным данным не требовался по причинам, которые не учитывались при первоначальном проектировании. В настоящее время я лично выбираю базу данных для чего-то другого, кроме файлов, которые имеют стандартные форматы и должны быть закодированы / декодированы другим программным обеспечением (например, аудио, видео).
Примечание: существует распространенное заблуждение, что двоичный файл непрозрачен и, следовательно, как-то более безопасен. Без дополнительной защиты это не так - если кто-то хочет взломать ваше программное обеспечение, то простое хранение ваших конфигураций или чего-то еще в двоичном виде не остановит их.
Сжатый Архив
Не совсем альтернатива вышесказанному, а скорее дополнительная мера.
Выгодно, когда вам нужно передавать данные по сети, или когда вы храните много-много данных и хотите сэкономить место. Обратите внимание, что в наши дни обычно достаточно места для хранения, поэтому рассмотрите вашу целевую платформу.
Сегодня очень быстро справляется практически с чем угодно (закон Мура в действии, детка), поэтому единственная причина, по которой он не используется, заключается в том, что он добавляет сложности вашему коду. Не много сложностей, но все же нарушение принципа KISS. Особенно обременительно для файлов конфигурации, которые необходимо редактировать вручную или с помощью сценариев - и если вам действительно нужно сэкономить там место, то вам, вероятно, следует использовать опцию базы данных.