1

我想建立一个数据库，其中包含一组音频文件（FLAC、Vorbis、MP3 等）的所有标签。我已经对提取进行了整理（这是最简单的部分），但现在我对如何正确设计包含它们的数据库有些疑问。

目前，我已将其标准化为简单的 1:m 关系：

file: filename, size, last_modified, …
tags: filename, tag, seq, value

其中文件名是file表( filename, tag, seq )的主键和表的主键tag。有些标签确实出现了不止一次；该seq列只是一个数字，可以记住它们的确切顺序。

然而，通过这样的设计，提取有关文件的有意义的信息变得非常痛苦。例如，如果我只想为每个轨道设置ARTIST, ALBUMAND TITLE字段，我已经必须加入fileandtags表三次：

SELECT filename, artist.value, album.value, title.value
FROM file
    LEFT OUTER JOIN tags artist USING ( filename )
    LEFT OUTER JOIN tags album USING ( filename )
    LEFT OUTER JOIN tags title USING ( filename );
WHERE
    artist.tag = 'ARTIST'
    AND album.tag = 'ALBUM'
    AND title.tag = 'TITLE';

毫无疑问，这不仅写起来非常麻烦，而且由于所有这些连接，速度也很慢。这只是一个简单的例子。实际上，我最终想要提出的所有查询都会将它们需要的所有标签拼凑在一起，就好像它们被存储为一个大表的列一样。

我已经考虑过不对标签进行规范化，而是将它们保留为表格的列FILE。但是标签的数量是高度可变的；一些更标准的标签，例如ARTIST并且TITLE几乎可以保证存在，一些更晦涩的标签仅在某些文件上，但我也需要使用它们。

对我来说，看起来我正在尝试以错误的方式进行操作，尤其是tags 表格是“结构化的”。有没有更好的方法来处理这种数据？供参考：我正在使用 PostgreSQL。

我从这篇文章中得知，我上面的架构是一个EAV 模型，所以看起来我要解决一个相当困难的问题……</p>

4

2 回答 2

1

但是标签的数量是高度可变的；一些更标准的标签，如 ARTIST 和 TITLE 几乎可以保证存在，一些更晦涩的标签只在一些文件上，但我也需要使用它们。

您可以为（大部分）保证标签使用单独的表格，并为可选标签使用 EAV 模型。

关系数据库旨在连接表。在您真正遇到性能问题之前，不要担心连接的性能问题。担心让您的数据关系正确。

于 2013-01-07T15:23:11.513 回答
1

我不只是坚持使用 EAV 模型并让 DBMS 整理产生的连接丛林，我发现了将所有标记作为 XML 文档存储在单个列中并在提取值时通过 XPath 查询它的建议。PostgreSQL 的HSTORE基本上遵循相同的想法。

这样，我摆脱了 EAV 结构，但还有其他缺点。HSTORE对标签值的大小有一些相当严格的限制，并且 XML 在存储和解析方面都造成了很大的开销。

最后，带有所有 s 的“原始”查询JOIN比复杂的 XML/Xpath 内容或HSTORE. 因此，接受答案的建议似乎是最好的。

于 2013-01-07T20:33:46.133 回答