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

Question

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

Например, если вы создали свою собственную программу для каких-либо целей, оставляете ли вы сохраненные данные в виде обычного текста, сериализуете ли их, кодируете ли в xml и зачем вы это делаете?

Есть ли какие-то секреты, которые я упустил?

Answer 1

Как правило, выбирайте самую простую вещь, которая может сработать, по крайней мере на первых порах.Рассмотрим, например, UNIX, где большинство файлов конфигурации представляют собой не что иное, как поля, разделенные пробелами, или поля, разделенные другим символом (например, /etc/passwd, который использует разделители ":", поскольку поле GCOS может содержать пробелы.)

Если вашим данным требуется гораздо больше структуры, спросите себя: "Какие инструменты я могу легко использовать?" Например, в Python и Ruby есть JSON и YAML.

XML в основном полезен, если у вас уже есть много материалов на основе XML ИЛИ вы планируете преобразовать XML в отображаемую форму в браузере.В противном случае, это обычно очень тяжеловесно (размер кода, сложность) для того, что вы от этого получаете.

Answer 2

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

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

Я использую много разных форматов, в зависимости от ситуации, например:

• обычный текстовый файл (с разделителями) для хранения наборов данных для анализа в Matlab и R.
• двоичные файлы - для хранения структур фиксированного размера (при динамическом размере произвольный доступ становится затруднительным без поддержания отдельного массива смещений для элементов).Одним из положительных моментов является производительность и экономичность пространства (почему большинство баз данных хранят данные в двоичном формате?), но людям с этим работать не очень удобно.Помни о конце света.
• XML - обычно для данных конфигурации или данных, которые я хочу предоставить приложениям других пользователей (вместе с XSD).Другая сторона может написать хорошее преобразование XSLT или использовать данные другим способом (конечно, они могли бы сделать то же самое с обычным текстом или двоичными данными, учитывая описание формата)

Answer 3

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

Еще один приятный момент - это буферы протокола Google (http://code.google.com/p/protobuf).Там вы пишете общее определение сообщения, а компилятор буфера протокола генерирует объекты для заполнения, сериализации и десериализации данных за вас.Обычно формат является двоичным, но вы можете использовать их класс TextFormat и для написания обычного текста, подобного JSON.Самое приятное в protobufs то, что код управления версиями генерируется для вас.В версии 2 вашего формата файла все, что вам нужно сделать, это добавить поля в файл определения .proto.Новая версия может считывать старый формат файла и просто оставляет новые поля пустыми.Это не совсем то, для чего были разработаны protobufs, но они создают простой и эффективный двоичный формат файла для пользовательских сообщений, и код генерируется для вас.

Также смотрите раздел Facebook Бережливость, сейчас находится в инкубаторе Apache.

Answer 4

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

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

На данный момент потребовалась бы необычная ситуация, чтобы заставить меня выбрать что-то отличное от одного из этих двух вариантов.

Answer 5

+1 для XML.Имеет небольшие накладные расходы, но прост в анализе, чтении и отладке.Может быть строгим, если вы используете схему.Легко трансформируется с помощью XSLT и очень портативен (по проводам или просто на флешке:)

Answer 6

Это действительно зависит от конкретной ситуации.Вам нужно было бы рассмотреть свои варианты в сравнении с ответами на различные вопросы:

• Сколько данных вам нужно сохранить?Вам нужна оптимизация для компактного представления?
• Критична ли производительность операций чтения / записи?Вам нужна оптимизация для доступа к диску и сериализации и десериализации с низкой отдачей?
• Вам нужен произвольный доступ к файлу?Нужно ли вам оптимизировать структуру для поиска в данных?
• Будут ли эти данные использоваться в разных системах, возможно, с разными кодировками символов?Вам нужна оптимизация для обеспечения мобильности?

Характер самих данных будет оказывать влияние.Это плоская структура списка?Это дерево?Это циклический граф?Являются ли записи фиксированной или переменной ширины?

Как только ответы на эти вопросы будут известны, вы сможете выбрать один из своих вариантов, максимально упростив его.Часто популярные параметры (XML, CSV, YAML) подходят для ваших целей.Если нет, то вам придется разработать свое собственное форматирование и собственные процедуры записи и чтения.

Answer 7

Существует так много возможностей, но наиболее прагматичным должен быть XML

• Существуют приличные библиотеки XML практически для каждой платформы разработки
• Большинство платформ допускают сериализацию графа объектов с помощью пары строк кода, поэтому реализация XML безболезненна
• Большинство платформ имеют встроенное в память и / или потоковое устройство чтения, так что вы можете обрабатывать действительно большие файлы без чрезмерного использования памяти
• Большинство платформ предоставляют преобразователь XSLT, поэтому вы можете перемещать файлы из одного формата в другой, даже из XML в не XML
• Для XML также существует расширение индексации для обработки действительно больших файлов
• В XML есть XSD-файлы для проверки формата, прежде чем вы попытаетесь его прочитать
• XML способен представлять любой простой или сложный объект
• Если вас беспокоит размер файла, просто заархивируйте окончательный XML-файл.Этот метод используется в Microsoft Office и т. Д
• XML по-прежнему доступен для чтения человеком
• XML - это общепринятый стандарт