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

Question

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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 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 для этого.

Поле тегов, которое я хотел бы использовать для хранения любого количества доступных для поиска параметров, таких как ГОД, ПРОЕКТ и другие значения, которые будут описывать и группировать ваш контент.

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