Question

给定一组具有关联元数据的文件，存储此元数据的推荐方法是什么？

某些文件格式支持在内部存储元数据（EXIF，ID3等），但并非所有文件格式都支持此功能，那么更常见的选项是什么？

一些元数据几乎肯定是唯一的（标题/描述/等），而有些则会在不同程度上重复（类别/标签/等）。
如果需要不同类型的属性，则对元数据进行分组也可能很有用。

理想情况下，解决方案应涵盖概念，而不是特定的语言实现。

Answer 1

在数据库中存储元数据有一些优点，但数据库的主要问题是元数据不直接连接到您的数据。如果metada保持数据 - 如目录中的特殊文件或类似的东西，它会更强大。

某些文件系统提供可用于元数据的特殊功能 - 如NTFS Alternate streams。不幸的是，这只能在特殊情况下用于元数据存储，因为在将数据复制到不支持它的存储系统时，这些流很容易丢失。我相信linux文件系统也有类似的存储机制。

无论如何，最常见的解决方案是：

单独隐藏文件（每个目录）保存元数据
某些应用程序使用特殊隐藏目录和元数据（如subversion，cvs等）。
或数据库（各种类型） - 在大多数情况下，此数据库也可用于缓存目的

IMO没有通用的解决方案。我会选择在隐藏文件中存储元数据（健壮性），并使用数据库进行快速访问和缓存。

Answer 2

我认为“解决方案”在很大程度上取决于您将使用元数据做什么。

例如，我们存储的几乎所有元数据（科学数据的多个数据集）都被砍掉并存储在数据库中。这允许我们创建数据集以保留文件之间的公共元数据（如您所说，类别和标签），同时我们有文件特定的结构（标题，开始/停止时间，最小/最大值等）。虽然我们可以保留这些隐藏文件，我们通过Web服务进行大量搜索并打开外部消费者的界面。

如果您要存储不会被搜索的元数据，则每个“真实”文件的隐藏文件或专用.xml文件不是一个糟糕的路径。它几乎可以读取，可以轻松转换为不同的格式，如果您决定更改存储机制，也不会丢失。

元数据应该对您有所帮助，而不是阻碍您。我已经看到（并且已经成为其中一部分）系统，其中元数据存储变得比存储实际数据更加繁重，并且成为一种负担。请记住你正在尝试用它做什么，不要用“if ifs”来扩展自己。

Answer 3

一个选项可能是关系数据库，结构如下：

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 4

纯文本比其他任何东西都有明显的优势。像

这样的东西

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

Picasa的Picasa.ini文件就是这类元数据的一个很好的例子。此外，XML可能值得考虑，而不是发明自己的格式。有很多现成的DOM处理器可以处理这种格式。

然后，如果文件数量和它们之间的关系很大，数据库可能会更好。

Answer 5

我基本上会创建一个包含此信息的元数据DB：

RESOURCE_TABLE 的
RESOURCE_ID
RESOURCE_TYPE（文件夹，doctype，web链接，其他）
RESOURCE_URL（任何URL）

NOTES_TABLE 的
NOTE_ID
RESOURCE_NO
RESOURCE_NOTE（长文本）

TAGS_TABLE 的
TAG_ID
RESOURCE_NO
TAG_TEXT

然后我会使用note字段文本注释到文件/文件夹/资源。选择是否使用1：1或1：N。

标签字段我将用于存储任意数量的可搜索参数，例如YEAR，PROJECT和其他将描述和分组内容的值。

然后，您可以为所有者，利益相关者和其他组织信息等添加表格。

存储与单个文件关联的元数据的方法？

5 个答案: