mraklbrwВыходит такой вариант:
Можно создать несколько файлов-соответствующих категориям, в каждом файле будут храниться картинки, относящиеся к этой категории.
Когда пользователь в приложении выбирает определённую категорию, файл фоново считывается и потом нужные картинки из него загружаются очень быстро (т.к. из ОЗУ).
И, получается, что в один момент времени, когда пользователь работает с однйо определённой категорией, в ОЗУ будет подгружено максимум 50 Мб.

Хм... почему 50 Мб? Непонятно.

Приложение должно быть кросплатформенным, поэтому нужно как-то и для Windows, и для Androdi чтобы был сходный механизм хранения и доступа.
Дада. Максимализм во всем - это хорошо. Все люди должны быть одинакового роста. А тем кто выше можно
подпилить череп сверху

Вот познавательная статья https://habr.com/company/surfingbird/blog/306252/

Roman Mejtes http://hex.pp.ua/object-id.php
файл можно открывать не только по имени, по и по ID,
в Ext3 у файла есть сови идентификаторы, не помню уже как они называются :( ноды или как то так.
Не знаю, будет ли такой подход быстрее :) но поробовать можно, удачи :)
Непонятно какой процент прироста мы получим?
Вангую что он лежит в диапазоне от 1% до 0.001%

Dima T,

Эксперимент предельно понятен.

Но из него сделаны неверные выводы. Правильнее сказать что он не симулирует нагрузку кеша картинок.

вадя,

На данном кейсе dbms будет работать медленнее чем локальная файловая система. Особенно когда картинка лежит в blob сегменте таблицы.