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

Question

Учитывая коллекцию файлов, которые будут иметь связанные метаданные, какие рекомендуемые методы для хранения этих метаданных?

Некоторые форматы файлов поддерживают хранение метаданных внутри (EXIF, ID3 и т. Д.), Но не все форматы файлов поддерживают это, так что же более общие параметры?

Некоторые из метаданных почти наверняка будут уникальными (названия/описания/и т. Д.), В то время как некоторые будут повторяться в разной степени (категории/теги/и т. Д.).
Также может быть полезно группировать метаданные, если требуются разные типы атрибутов.

В идеале решения должны охватывать концепции, а не конкретные языковые реализации.

Answer 1

Одним из вариантов может быть реляционная база данных, структурированы следующим образом:

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 

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

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

---

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Во всяком случае, наиболее распространенные решения:

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

ИМО нет общего решения цели. Я бы выбрал хранение метаданных в скрытом файле (надежность) с использованием базы данных для быстрого доступа и кеширования.

Answer 4

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

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

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

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

Answer 5

Я бы в принципе сделать БД метаданных, который провел эту информацию:

RESOURCE_TABLE
RESOURCE_ID
RESOURCE_TYPE (папка, доктайп, веб-ссылки, другие)
RESOURCE_URL (любой URL)

NOTES_TABLE
NOTE_ID
RESOURCE_NO
RESOURCE_NOTE (длинный текст)

TAGS_TABLE
tag_id
RESOURCE_NO
TAG_TEXT

Тогда я хотел бы использовать текстовые заметки примечание поля в файл/папку/ресурса. Выберите, если вы используете для этого 1: 1 или 1: N.

В поле тегов я хотел бы использовать любое количество параметров для поиска, таких как YEAR, PROJECT и другие значения, которые будут описывать и группировать ваш контент.

Затем можно добавлять таблицы для владельца, заинтересованных сторон, и другая информация организации и т.д.