Имеется программа, работающая с числовой и текстовой информацией. Сохранение/загрузка идет через сериализацию. Все прекрасно работает, но появилась мысль добавить бантики в виде различных картинок и, возможно, другой мультимедийной инфы. Понятно, что грузить все это с основной информацией через сериализацию - мягко говоря, крайне неэффективно. Хотелось бы основную инфу грузить при открытии файла, а картиночки - по мере необходимости. Подозрительно посмотрел в сторону структурированных хранилищ, которые позволяют это делать, но по некоторым соображениям не хотелось бы их использовать. Базы данных не подходят совершенно. Кто нибудь занимался подобным извратом? Подскажите! Не могу сообразить, как реализовать.

Основные требования:
1. Все данные хранятся в одном файле (весьма желательно, если только возможно)
2. Основная информация грузится/сохраняется вся и сразу (через сериализацию)
3. Бантики извлекаются/сохраняются по мере необходимости.

Надеюсь, не слишком сумбурно получилось, голова совсем не соображает.  

дак чего паришься? Ты разбей на 2 раздела файл. 1 - это собственно инфа, 2- всякая шелуха. В начале файла укажи сколько байт информации и шелухи. При сериализации вторую чатсть просто куском вгоняй. А вдобавок имей метод, который работает только со второй частью, этот метод вызывай когда надо. Ну вообщем покумекай на эту тему  

Проблема в том, что обе части будут изменяться в размерах (по мере добавления/удаления информации). И если первый кусок (основную информацию) можно рассматривать как единое целое, то для второй части требуется быстрый и удобный доступ к каждому отдельному элементу, а также минимизировать количество операций чтения/записи - собственно, это моя основная задача. А у меня, в каком бы направлении не думал, все мысли возвращаются к внутрифайловой FAT  . Чем не изврат? Хотя... Если подумать... Может...  
Да нет, изврат это!!!

Сначала оцени объем бантиков. Если не очень большой (< 100 mb) смело грузи куском в оперативку и там извращайся как хочешь. Если больше - то же самое, только не в обычную память, а в файл-мэппинг. Если совсем много (так что все целиком грузить не хочется) - подумай все же о двух файлах. Главное четко сознавать: либо ты работаешь с файлом как с документом, т.е. грузишь и сохраняешь его целиком, либо как с базой данных. Причем первое совсем не подразумевает того, что ты будешь формировать готовые объекты (что может быть долго) - можно просто загружать "сырые" куски по-быстрому, и по мере надобности с ними ковыряться. Главное - чтобы в памяти (или в своп-файле) было все, что нужно для записи файла-документа с нуля. Сериализацию лучше реализовать так, чтобы коду было по барабану, откуда читать\писать - из файла или из памяти - лучше всего для этого потоки стандартной библиотеки подходят. Другими словами, отделить открытие\закрытие файла от самого чтения\записи.

Достаточно трудно: зависит от того, что пользователь туда напихает. Так что от нулевого до сотен мегабайт.

Думаю. С двумя файлами гораздо легче. Но есть риск, что нерадивый пользователь скопирует куда-нибудь один и забудет про другой.

Интересная мысль. Earnest, спасибо за наводки, буду думать.