Какой формат файла вы используете для своего приложения и почему?

Question

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

• Создание больших файлов с нуля неэффективно
• xml слишком многословен
• BLOB-объекты не очень подходят

Так как ты это делаешь?

Answer 1

ИЛИ Картографирование с использованием одного из нескольких готовых решений.

Answer 2

Это зависит от ваших требований. Будете ли вы честно использовать XML или блобы SQL для изображений или аудио высокого разрешения?

Я перечитал еще раз ваш вопрос: если у вас есть несколько произвольных объектов, которые вы хотите сохранить в образе файла, способ их ввода / вывода - это копирование и перемещение. Отпечаток может получить помощь от GC. Копия действительно проста и в основном зависит от процедуры перемещения.

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

Также будет необходимо пометить удаленные объекты, если только вы никогда ничего не удалите.

Answer 3

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

Для структурированных текстовых данных я бы использовал s-выражения (т.е. LAML ) или для сокращения скобок LAML, реализованных с использованием выражений i.

Answer 4

Вам необходимо сопоставление O / R или база данных объектов, например db4o.

Если речь идет о наборе относительно автономных объектов, также возможно сохранить каждый из них в своем собственном файле и записывать только тогда, когда объект загрязнен. Но очевидно, что в более сложных случаях может потребоваться много работы, чтобы сохранить ссылки и избежать неинтуитивных структур каталогов, и это действительно то, что средства отображения O / R и объектные базы данных приносят в таблицу.

Что касается слишком многословного XML, то его часто можно решить с помощью сжатия (например, xml в zip).

Answer 5

Вы можете попробовать сериализацию в XAML, а не в XML. Это может создавать файлы меньшего размера и намного быстрее для чтения и записи (сериализации / десериализации).

Очевидно, что это зависит от XAML.

Answer 6

Я использую YAML для небольших и средних файлов, их очень легко анализировать и сохранять. JSON - достойная альтернатива.

Answer 7

"Создание больших файлов с нуля неэффективно" Что? Мало что так быстро, как файловый ввод / вывод. Приведите пример или данные, подтверждающие ваше утверждение о том, что файловый ввод / вывод неэффективен.

Большинство систем OO могут сериализовать или преобразовывать объект в файл. Это самый быстрый ввод-вывод.

Кроме того, большинство ОО-систем могут преобразовывать объекты в стандартные представления, такие как XML, JSON или YAML.

JSON / YAML менее многословен и намного проще анализировать, чем XML.

Answer 8

Мы используем в основном двоичные данные. Если только он не должен быть удобочитаемым человеком (например, настройки и пользовательские настройки).

Если вы думаете, что xml слишком многословен, взгляните на JSON. Я думаю, что это очень хорошая альтернатива.