On Tue, Apr 23, 2013 at 10:28:35AM -0400, Richard Hipp scratched on the wall:
> Or, if you really want file-system semantics on top of your database (and > this is a reasonably idea, actually) you could write a wrapper library that > implemented file-system semantics on top of SQLite. As a side note, almost every video game console developer out there has some type of "filesystem in a file" library for dumping models, textures, animation, and level data into large chunks that can be streamed off optical drives. Optical systems really, really suck at seeks, so you tend to batch all the required data into a single mass, and the stream the whole thing off the disc when (for example) someone loads a new level. You really don't want to get the on-disc filesystem involved in loads if you can avoid it. Of course, since the data is read-only and the main goal is to avoid seeks, an SQLite solution would be a Very Bad Idea. Rather, it is common to base the embedded filesystem off an archive format, like tar. Using IFF files was also popular back on the cartridge days. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
