EXIF メタデータをリレーショナル データベースに格納できるようにする必要があるアプリケーションに取り組んでいます。将来的には、XMP と IPTC メタデータもサポートしたいと考えていますが、現時点では EXIF に重点を置いています。
EXIF メタデータを格納するときにテーブル構造がどのように見えるべきかについて、スタック オーバーフローに関するいくつかの質問があります。しかし、それらのどれも私の懸念に実際に対処していません。私が抱えている問題は、さまざまな EXIF タグがさまざまな形式の値を持ち、それらすべてを便利に格納する 1 つの列タイプが実際には存在しないことです。
最も一般的なタイプは、分数を表す 2 つの 4 バイト整数の配列である「有理数」です。しかし、非分数の短整数と長整数、ASCII 文字列、バイト配列、および「未定義」(特定のタグのアプリオリな知識に従って解釈する必要がある 8 ビット型) もあります。便利で効率的で、ロスレス (つまり、有理数を float に変換せずに)、拡張可能で検索可能な方法で行いたいと考えています。
これまでに私が検討したことは次のとおりです。
私の現在の解決策は、すべてを文字列として保存することです。これにより、さまざまな型をすべて簡単に格納でき、検索やデバッグにも便利です。ただし、実際にデータを使用したい場合は、有理数を同等の小数に変換するために一連の文字列操作を行う必要があるため、扱いにくく非効率的です
fraction = float(value.split('/')[0]) / float(value.split('/')[1])。(私の実際のコードでは、実際にはそのような乱雑なワンライナーではありませんが、これは問題を示しています。)ファイルから各値の未加工の EXIF バイトを取得して blob 列に格納することはできますが、その場合は毎回未加工のバイトを再解釈する必要があります。これは、文字列ソリューションよりもわずかに CPU 効率が高い可能性がありますが、他のすべての点ではるかに劣っており、全体としては価値がありません。
異なる EXIF データ型ごとに異なるテーブルを持つことができます。このパターンを使用すると、複数の異なるテーブルに値を格納しながら、外部キーの関係を維持できます。ただし、これにより、特定の写真のすべての EXIF メタデータを選択するという私の最も一般的なクエリが厄介なものになります。また、他のメタデータ形式のサポートを追加すると、すぐに扱いにくくなります。
私は決してデータベースの専門家ではないので、この問題を解決できるパターンまたはマジック ユニオン スタイルの列タイプが不足していますか? それとも、上記の 3 つのオプションの中から自分の毒を選ぶのに行き詰っていますか?