设计用于存储音频文件标签的数据库答案

【问题标题】：Designing a database for storing tags of audio files设计用于存储音频文件标签的数据库
【发布时间】：2012-12-20 18:59:46
【问题描述】：

我想建立一个数据库，其中包含音频集合的所有标签文件（FLAC、Vorbis、MP3 等）。我已经整理好提取了（那是容易的部分），但现在我对如何正确设计包含它们的数据库。

目前我已将其标准化为这样作为一个简单的 1:m 关系：

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

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

但是，通过这样的设计，可以提取有关文件成为真正的痛苦。如果我例如只想拥有ARTIST、ALBUM 和每个轨道的TITLE 字段我已经必须加入file 和tags 表三次：

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。

我从this post 得知，我上面的架构是EAV model，所以看起来我要解决一个相当棘手的问题……

【问题讨论】：

标签： postgresql database-design normalization

【解决方案1】：

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

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

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

【讨论】：

显然，大量的连接确实没有我担心的那么慢，尤其是在一些战略性放置的部分索引中。因此，我将尝试将尽可能多的已知标签放入“真实”表中，并为其余部分保留 EAV，这应该在易用性和灵活性之间做出最佳权衡。

【解决方案2】：

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

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

最后，带有所有 JOINs 的“原始”查询比复杂的 XML/Xpath 内容或 HSTORE 所需的繁琐字符串转义要清晰得多。因此，接受答案的建议似乎是最好的。

【讨论】：