The problem with using database blobs for load/save is that you usually need a full database client in the application. SQlite advertises that use case, but it is complete overkill. You never need to run any sort of complex SQL query on an image file format for instance. Using XML+ZIP in this day and age is also a strange decision, but at least that way the data is inspectable with unzip, a text editor and an image viewer (assuming they use a standard image format to store the raw pixel data).

▲

TeMPOraL 43 minutes ago | parent [-]

> You never need to run any sort of complex SQL query on an image file format for instance.

Sure you will. Plenty of features that don't exist, or are implemented badly, because you can't easily do it.

Quick mental translation table: if you think "iterate over every ..." or a `for` loop, that's your SELECT query. If you think about `if` conditions, that's the parts that go after FROM clause.

	▲	zelphirkalt 6 minutes ago \| parent \| next [-]
		SQLite is fast, but it won't be faster than a hot loop in C. Having the loop construct dictated by the file format seems bad. For images it seems more reasonable to have them in-memory, except for huge image edge cases.
	▲	x3ro 36 minutes ago \| parent \| prev [-]
		In order to have any advantage from this, you would have the added complexity of splitting your file format into tables that can be queried in a useful manner. However, for an image file format, you most likely need to hold the entire definition in memory at all times anyway. Assuming that’s the case, doesn’t XPath get you there most of the way (assuming XML), with _way_ less complexity?