Альтернатива ZIP как формат файла проекта. SQLite или другое?

Question

Мое Java-приложение в настоящее время использует ZIP в качестве формата файла проекта. Файлы проекта содержат несколько файлов XML и множество графических и звуковых файлов.

Файлы проекта становятся довольно большими, и, поскольку я не могу найти способ с классами java.util.zip записывать в ZIP-файл без его повторного создания, мои сохранения файлов становятся очень медленными. Так, например, если я просто хочу обновить один файл XML, мне нужно переписать весь ZIP.

Есть ли какая-нибудь другая библиотека Java ZIP, которая позволит мне выполнять произвольную запись в файл ZIP?

Я знаю, что переключение на что-то вроде SQLite решает проблему случайной записи. Будет ли уместным использовать SQLite для написания XML, звука и изображений в качестве больших двоичных объектов?

Полагаю, я мог бы придумать свой собственный формат файла и использовать RandomAccessFile, но тогда мне пришлось бы писать много бухгалтерии.

Обновление ...

Мой формат файла очень похож на Office Open XML . Это ZIP-файл, содержащий XML и другие ресурсы.

Кто-то, должно быть, решил проблему случайных записей для обновления ZIP-файла. Кто-нибудь знает как?

Answer 1

Существуют так называемые однофайловые виртуальные файловые системы, которые позволяют создавать файловые контейнеры и предоставлять файловую систему, такую ​​как структура и API. Один из примеров - SolFS (у него ядро ​​с C-записью и JNI-оберткой) и некоторые другие решения на C- и Delphi (я не помню их имен на данный момент). Я предполагаю, что существуют аналогичные нативные Java-решения.

Answer 2

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

Теперь у вас есть 2 варианта:

• Поскольку нестатические файлы, вероятно, не слишком большие (xml-файлы, вероятно, меньше, чем изображения + звуки), вы можете придерживаться своего текущего решения (zip-файл) и просто поддерживать 2 zipфайлы, из которых только один (меньший с изменяемыми файлами) может / будет перезаписан.

• Вы можете использовать базу данных в памяти (например, hsqldb) длясохраняйте изменяемые файлы и сохраняйте их (передавая из базы данных в файл на диске), когда ваше приложение закрывается или эта операция явно необходима.

Answer 3

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

Если вы решите использовать SQLite, также рассмотрите возможность преобразования некоторыхсхем XML в одну или несколько таблиц SQL вместо хранения больших документов XML в виде больших двоичных объектов.

Answer 4

Прежде чем предложить другой ответ в соответствии с использованием правильно структурированных JAR-файлов, я должен спросить - , почему нужно ли инкапсулировать в один файл? Как вы распространяете программу пользователям для запуска?

Answer 5

sqlite не всегда быстрый (по крайней мере, по моему опыту).Я бы посоветовал отдельно сжать файлы XML - вы все равно получите приличное сжатие и просто используете файловую систему для их сохранения.Вы можете поэкспериментировать с btrfs или просто пойти с ext4.Если вы не работаете в Linux, тогда это все равно должно работать нормально, но это может быть не так быстро, пока все не будет кэшировано в памяти.

идея заключается в том, что если у вас нет избыточности между XML-файлы, тогда вы не получите , что значительно сэкономит, сжав их в один "сплошной" архив.