Методы для хранения метаданных, связанных с отдельными файлами?

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

FILE
f_id
f_location
f_title
f_description

ATTRIBUTE
a_id
a_label

VALUE
v_id
v_label

METADATA
md_file
md_attribute
md_value

Эта реализация имеет некоторую уникальную информацию (заголовок/описание), но прежде всего предназначена для повторяющихся групп данных.

Для некоторых требований другое меньше универсальных таблиц может быть более полезным.

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

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

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

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

Некоторые файловые системы предлагают специальную функциональность, которая может использоваться для метаданных - как потоки Альтернативы NTFS. К сожалению, это может использоваться для устройства хранения данных метаданных в особых случаях только, потому что те потоки могут быть легко потеряны при копировании данных в систему хранения, которая не поддерживает его. Я полагаю, что файловые системы Linux имеют также подобный механизм хранения.

Так или иначе наиболее распространенные решения:

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

IMO там не является никаким решением общего назначения. Я выбрал бы устройство хранения данных метаданных в скрытом файле (устойчивость) с использованием базы данных для быстрого доступа и кэширования.

Простой текст имеет некоторые очевидные преимущества перед чем-либо еще. Что-то как

FileName = 'ferrari.gif'
Title = 'My brand new car'
Tags = 'cars', 'cool'
Related = 'michaelknight.mp3'

Файлы Picasa.ini Picasa являются хорошим примером для этого вида метаданных. Кроме того, вместо того, чтобы изобрести Ваш собственный формат, XML мог бы быть достойным рассмотрения. Существует много легко доступных процессоров DOM для контакта с этим форматом.

С другой стороны, если сумма файлов и отношений между ними огромна, базы данных могут быть лучше.

Я думаю, что "решение" во многом зависит от того, что вы собираетесь делать с метаданными.

Например, почти все метаданные, которые мы храним (многочисленные наборы научных данных), измельчены и хранятся в базе данных. Это позволяет нам создавать наборы данных для сохранения общих метаданных между файлами (как вы говорите, категории и теги), в то время как у нас есть структуры, специфичные для файлов (название, время начала/остановки, мин/макс значения и т.д.) Хотя мы могли бы хранить их в скрытых файлах, мы делаем много поиска и открываем наш интерфейс для внешних потребителей через веб-сервисы.

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

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