> Что-то я не понимаю с чего вы считаете будто бы считать бинарные
> блобы из SQLite эффективнее чем чем читать их как файлы стандартными
> средствами Ос?Потому что я не считаю так. Речь ведь не о том, чтобы просто считать бинарные блобы, речь о приложении, которое работает с данными в файле. А работа с файлом может включать в себя не только последовательное чтение. Вот как ты будешь читать из файла? То есть, во-первых, ты будешь читать из файлА или из файлОВ? Наверное, всё же первое? Один файл и там поток сэмплов, так? Тогда, если тебе нужен блоб оттуда, что ты делаешь? lseek+read, так? В идеале хотелось бы так, потому как этот метод вряд ли чем-либо порвать удастся.
Но теперь прикинь, пользователь тыкает в интерфейсе и говорит "вот сюда я хочу вставить кусок звука". Что происходит на диске в ответ? А там паника, потому как стандартные средства фс не умеют расширять файл вставляя в середину кусок. Значит что надо делать? Вариант номер раз -- не сохранять почём зря, в надежде что приложение не упадёт, и электрик рубильником свет во всём доме не вырубит, и что промежуточный достигнутый пользователем результат не будет потерян. Вариант номер два -- читать с диска и перезаписывать полфайла. Вариант номер три -- разбить единый поток на маленькие блобы, и если что-то вставляется в середину, реально дописывать это в конец файла. Но тут тебе уже надо хранить в каком-то виде отображение времени от начала записи в смещение на диске. И это значит, что ты начал переизобретать базу данных и создавать её наколенную реализацию. И получится ли у тебя быстрее чем у sqlite -- это большой вопрос.
Эффективное же хранилище на жёстком диске, может открыть простор для того, чтобы а) сохранять промежуточный результат после каждого изменения, б) не хранить в памяти ВСЁ, хранить всё на диске, читая оттуда по мере необходимости, а это значит, что можно вместо сотен мегабайт или гигабайт ОЗУ под данные жрать ну, десятки мегабайт, наверное. Оу, это будет медленнее, чем всё хранить непосредственно в адресном пространстве процесса, но ровно до тех пор, пока у ОС достаточно оперативки: как только оперативка кончится, ОС начнёт свопить, и вот тут твоя производительность пойдёт лесом, в то время как вообще-то, если заточить приложение на хранение данных на диске, с чтением в память только нужного, то можно даже при нехватке оперативки под все данные, работать пускай не быстро, но и не запредельно тормозно. При этом, ежели у ОС достаточно свободной памяти, она закеширует содержимое диска, и будет не настолько уж и медленнее. Но сделать так, чтобы это "не настолько уж и медленнее" обеспечивало бы пристойную скорость работы на всём спектре железа которое используется под persistent storage и на всех ОС, на которых работает приложение -- это задача не для слабонервных, это задача для разработчиков бд.
