Quote:
Originally Posted by At_Libitum
I can see where the idea comes from. Using one big container file with it's own internal 'filesystem' was/is still used for a lot of games. and most of these games also got released on several platforms. So in that respect the idea is not that strange. The only thing that is different here, the dynamic nature of a library compared to the static environment of game resources. You'd have to go the direction of virtual hd files or something similar and let the current rdbms use the container file to write-to/read-from instead of trying to recreate the rdbms. But...like physical hd's, virtual file systems tend to get fragmented the same way, with the same side effects. Which means, reorganization is needed, which means needing at least as much free diskspace as the size of the container file, preferable double that.
It may look like a good idea, but it has one helluva drawback. If something, how small even, breaks in the container file, it's bye-bye- library. At least in the current situation, all books stay intact. Which means you probably want to maintain some kind of parity system for repairs if worst comes to worst. In the end, the risk some mishap occurring to a virtual file system is much higher than to a physical one. Files get damaged much more often than HD's
|
Actually I am not proposing to do a one big encapsulation of the whole database, just of the items it it. So if you look at the database as a tree and the data inside final folder as a leaf, I am proposing to encapsulate that final folder (ok I will probably add some file-structure to it so for example you could store a pdf book broken by chapters and it will combine as needed, audio books could be kept in one place, or a folder for supplementary material which sometimes comes with a book).
The only thing I will have in a big file, will be the general database, so that I don't have to re-scan it again. However, even that might not be true, as I am planning for the database to be locate-able on different hard-drives, not just different folders. Therefore, each location will have a local backup database, which the main database will load from and reference to.