Лучшие практики для пользовательских файловых структур - PullRequest
5 голосов
/ 02 марта 2009

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

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

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

Ответы [ 7 ]

7 голосов
/ 02 марта 2009

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

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

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

5 голосов
/ 02 марта 2009

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

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

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

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

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

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

Также см. Facebook Thrift , теперь в инкубаторе Apache.

1 голос
/ 02 марта 2009

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

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

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

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

1 голос
/ 02 марта 2009

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

1 голос
/ 02 марта 2009

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

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

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

0 голосов
/ 02 марта 2009

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

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