我的情况取决于情况。我正在编写一个类似于 iTunes、Windows Media Player 和 Winamp 的音乐库管理器/播放器。我已经让所有的 ID3 标签代码都在工作，现在我已经为数据库做好了准备。据我发现，读取数据库、检查文件的 MD5 哈希值并将其与存储的哈希值进行比较并在歌曲更改时更新数据库比直接读取每首歌曲的 ID3 标签要快得多。 . 话虽如此，我刚刚启动并运行了一个 sqlite 数据库。
现在我不确定是否应该将专辑封面存储在数据库或文件系统中。我的代码可以自动将专辑封面重新调整为 300x300 像素，因此所有图片的文件大小通常在 15-30 KB 左右。这对于普通大小的图像和 14.8 MB 大小的图像都是如此。所以平均而言，我需要存储 22.5 KB 大小的图片。
这是取决于情况的部分；我需要决定在包含 100 首歌曲和 20,000 首歌曲的音乐库中保持高效。假设所有歌曲都有专辑封面，哪种方法更好：使用子目录的 sqlite 数据库或 NTFS 文件系统以加快加载时间
通常，数据库在存储 BLOB 方面并不是那么出色，但您已经在显着减小 BLOB 的大小，从而减少问题。
另外，请记住，为每首歌曲存储一个 blob 可能会完全浪费空间，因为您很可能处于多首歌曲共享同一个 blob 的情况。
由于图像尺寸较小，我会将它们存储在数据库中并调整架构以确保您不会在其中存储具有相同图像的多个 blob。这也使得确保数据一致变得更加容易，因为您没有将部分数据放在一个地方（数据库）和文件系统上的一些其他数据，用户可能会意外删除它。
一旦您谈论更大的 blob，您可能应该将它们存储在磁盘上而不是数据库中。
当您将图像放入包含其他歌曲数据的同一张表中时，所有对歌曲数据的查询也必须从磁盘加载一些图像数据。
如果将图像放入与主歌曲表具有 1:1 关系的另一个表中，则可以避免这种影响。如果您将该表放入一个单独的数据库中，您可以将图像数据进一步分离ATTACH到主数据库中；这甚至允许您以不同的方式配置缓存。这与存储在磁盘上的图像应该没有速度差异。
如果您经常需要将图像导出到文件（以便在外部程序中编辑或显示），那么首先将图像存储在文件系统中可能会更容易。
此外，将图像作为文件将使增量备份更容易（如果这是一个问题）。