我正在研究需要将EXIF元数据存储在关系数据库中的应用程序。将来我也想支持XMP和IPTC元数据，但目前我的工作重点放在EXIF上。用于在数据库中存储EXIF元数据的格式
有关Stack Overflow的几个问题，这些问题涉及存储EXIF元数据时表结构的外观。但是，他们没有一个真正解决我的问题。我遇到的问题是，不同的EXIF标签具有不同格式的值，并且实际上没有一种列方式可以方便地存储它们。
最常见的类型是一个“有理性的”，它是一个代表一个小数的两个四字节整数的数组。但也有非小数短和长整数，ASCII字符串，字节数组和“未定义”（8位类型，必须根据特定标记的先验知识来解释）。我想支持所有这些类型，我希望以一种方便，高效，无损（即无需将有理数转换为浮点数），可扩展和可搜索的方式来实现。
这里是我到目前为止认为：
我目前的解决方案是将一切作为一个字符串。这使得存储所有不同类型变得非常容易，而且便于搜索和调试。然而，这种方法笨重且效率低下，因为当我想要实际使用这些数据时，我必须进行一些字符串操作来将有理数值转换为它们的小数部分，例如，
fraction = float(value.split('/')[0])/float(value.split('/')[1])。 （在我的真实代码中，这实际上并不是一团乱麻，但是这证明了这个问题。）我可以从文件中获取每个值的原始EXIF字节并将它们存储在blob列中，但那么我必须每次重新解释原始字节。这可能比字符串解决方案的CPU效率略高一些，但是从其他方面来看，情况要差得多 - 总体而言，这并不值得。
我可以为每个不同的EXIF数据类型有不同的表。使用this pattern我可以维护我的外键关系，同时将我的值存储在几个不同的表中。但是，这将使我最常见的查询，即选择给定照片的所有EXIF元数据，这是一种讨厌。当我添加对其他元数据格式的支持时，它也会很快变得笨拙。
我不是一个数据库专家的任何手段，所以有一些模式或魔术联盟式的列类型我错过了，可以使这个问题消失吗？或者我坚持从上述三个选项中挑选我的毒药？
不，没有魔法。 –