1

オーディオ ファイル (FLAC、Vorbis、MP3 など) のコレクションのすべてのタグを含むデータベースを構築したいと考えています。私はすでに抽出を整理しました (それは簡単な部分でした) が、それらを含むデータベースを適切に設計する方法について疑問を持っています。

現時点では、単純な 1:m の関係として次のように正規化しています。

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

filenameはテーブルfileの主キーであり、テーブル( filename, tag, seq )の主キーですtag。一部のタグは複数回表示されます。列は、seqそれらの正確な順序を覚えている単なる数字です。

ただし、このような設計では、ファイルに関する意味のある情報を抽出するのが非常に困難になります。たとえば、各トラックのARTIST, ALBUMAND フィールドだけを使用したい場合は、 andテーブルを 3 回結合する必要があります。TITLEfiletags

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

EAV モデルに固執して、結果として生じる結合のジャングルを DBMS に整理させる代わりに、すべてのタグを 1 つの列に XML ドキュメントとして格納し、値を抽出するときに XPath を介してクエリを実行するという提案を見つけました。PostgreSQL のHSTOREは、基本的に同じ考え方に従います。

このようにして、EAV 構造を取り除きますが、他にも欠点があります。HSTOREには、タグ値の大きさにかなり厳しい制限があり、XML は保存と解析の両方でかなりのオーバーヘッドを引き起こします。

最後に、すべての を含む「元の」クエリJOINは、複雑な XML/Xpath のものや、 に必要な面倒な文字列エスケープよりもはるかに明確ですHSTORE。したがって、受け入れられた回答からの提案が最善のようです。

于 2013-01-07T20:33:46.133 に答える
1

ただし、タグの数は非常に多様です。ARTIST や TITLE などのより標準的なタグのいくつかは、ほぼ確実に存在することが保証されています。よりあいまいなもののいくつかは、一部のファイルにしかありませんが、それらも使用する必要があります。

(ほとんどの場合) 保証されたタグ用に別のテーブルを用意し、オプションのタグ用に EAV モデルを使用することができます。

リレーショナル データベースは、テーブルを結合するように設計されています。実際にパフォーマンスの問題が発生するまでは、結合のパフォーマンスの問題について心配する必要はありません。データの関係を正しくすることを心配してください。

于 2013-01-07T15:23:11.513 に答える