Должен ли я использовать sqlite или NTFS для хранения изображений

Мой сценарий зависит от ситуации. Я пишу органайзер/проигрыватель музыкальной библиотеки, который будет похож на iTunes, Windows Media Player и Winamp. У меня уже есть весь код тега ID3, и теперь я готов к работе с базой данных. К моему открытию, намного быстрее читать базу данных, проверять хэш MD5 файла и сравнивать его с сохраненным, а также обновлять базу данных, если песня изменилась, чем просто читать непосредственно из тегов ID3 ​​каждой песни при загрузке. . Итак, как говорится, я только что запустил базу данных sqlite.

Теперь я не уверен, должен ли я хранить обложку альбома в базе данных или в файловой системе. У меня есть код, который автоматически изменяет размер обложки альбома до 300x300 пикселей, поэтому размер файла для всех изображений обычно составляет около 15-30 КБ. Это верно для изображений нормального размера и изображений размером 14,8 МБ. Таким образом, в среднем мне нужно хранить изображения размером 22,5 КБ.

Вот ситуационно-зависимая пьеса; Мне нужно решение, чтобы быть эффективным с музыкальной библиотекой из 100 песен, а также 20 000 песен. Предполагая, что все песни имеют обложку альбома, какой метод будет лучше: база данных sqlite или файловая система NTFS с использованием подкаталогов для более быстрой загрузки


database sqlite ntfs
person user1766329    schedule 22.10.2012    source источник
comment
Хорошо, еще одна вещь, которую следует учитывать, — это время чтения. Буду читать только картинки. Было бы лучше прочитать образ из базы данных или из файловой системы NTFS? Будет ли иметь значение, если при выборе базы данных или файловой системы будет 5000 изображений вместо 5 изображений?   -  person user1766329    schedule 31.10.2012

Ответы (2)


arrow_upward
0
arrow_downward

В общем, базы данных не так уж хороши для хранения больших двоичных объектов, но вы уже значительно уменьшаете размер больших двоичных объектов, что делает это меньшей проблемой.

Кроме того, имейте в виду, что хранение большого двоичного объекта для каждой песни может быть пустой тратой места, поскольку вы, скорее всего, окажетесь в ситуации, когда несколько песен используют один и тот же двоичный объект.

Из-за небольшого размера изображений я бы сохранил их в базе данных, а также отрегулировал схему, чтобы убедиться, что вы не храните в них несколько больших двоичных объектов с одним и тем же изображением. Это также значительно упрощает обеспечение согласованности данных, поскольку у вас нет части данных в одном месте (базе данных) и некоторых других данных в файловой системе, где пользователь может их случайно удалить.

Когда вы говорите о значительно больших BLOB-объектах, вам, вероятно, следует хранить их на диске, а не в базе данных.

person Timo Geusch    schedule 22.10.2012

arrow_upward
0
arrow_downward

Когда вы помещаете изображения в ту же таблицу, которая содержит другие данные песни, все запросы к данным песни также должны загружать некоторые данные изображения с диска.

Вы можете избежать этого эффекта, если поместите изображения в другую таблицу, которая имеет соотношение 1:1 с вашей основной таблицей песен. Вы можете еще больше разделить данные изображения, если поместите эту таблицу в отдельную базу данных, которую вы ATTACH основная база данных; это даже позволяет вам по-разному настраивать кеши. Это не должно иметь разницы в скорости с изображениями, хранящимися на диске.

Если вам регулярно нужно экспортировать изображения в файл (для редактирования или отображения во внешних программах), может быть проще хранить изображения в файловой системе в первую очередь.
Кроме того, наличие изображений в виде файлов приведет к добавочному резервному копированию. легче (если это вас беспокоит).

person CL.    schedule 22.10.2012