Question

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

此刻我已经将它标准化了作为一个简单的1：m关系：

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

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

然而，通过这样的设计提取有关的有意义的信息文件变得真正的痛苦。如果我想要只拥有ARTIST，ALBUM AND 我必须加入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';

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

我已经考虑过不对标签进行规范化并将其保留为 FILE表的列。但标签的数量变化很大;一些像ARTIST和TITLE这样的标准标签几乎可以保证目前，一些比较模糊的只是在一些文件上，但我需要和他们一起工作。

对我而言，我似乎试图以错误的方式去做，尤其是tags 表是“结构化的”。有没有更好的方法来处理这类数据？供参考：我正在使用PostgreSQL。

我从this post收集到我上面的架构是EAV model，所以看起来我很难解决这个问题......

Answer 1

但标签的数量变化很大;一些更标准的标签，如ARTIST和TITLE几乎可以保证存在，一些比较模糊的标签只在某些文件上，但我也需要使用它们。

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

关系数据库旨在连接表。在实际出现性能问题之前，请不要担心连接的性能问题。担心让数据关系正确。

Answer 2

我找到了将所有标签作为XML文档存储在单个列中并在提取值时通过XPath进行查询的建议，而不是仅仅坚持使用EAV模型并让DBMS整理出由此产生的连接丛林。 PostgreSQL的HSTORE遵循基本相同的想法。

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

最后，所有JOIN的'原始'查询比复杂的XML / Xpath内容或HSTORE所需的繁琐的字符串转义更清晰。因此，接受答案的建议似乎最好。

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

2 个答案: