From what I've seen of other wiki-like software there's two common choices: use a database or a flat file system with a file per page.
A flat file system seems to have the advantage that you can mess with the files with an external editor or reader.
On the other hand with a database back-end it seems easier to store metadata/relational information.
Since the infodump project that I plan to use the personal wiki with will potentially run thousands of pages, a flat file system might be awkward to work with. I'm not worried about name collisions, since each page would have a unique identifier (otherwise they wouldn't fit in a wiki framework), but somethings like properly escaping page names into file names could be a hassle. (Of course, in the amount of time I spent thinking about this I could probably have banged out the code to escape the names properly. But that would be more code to maintain and debug later.)
Actually, I'm jumping ahead here. Basically, since there may be thousands of pages, storing all the page data and meta data in memory at once would be somewhat silly. So the rest can be written to secondary storage (with possible caching of individual pages).
The only thing that needs to be stored per page would be the raw page data. I think at a minimum this includes the original data as entered by the user originally. (As compared with storing a transformed, viewable version that gets translated back into the original mark up. It pisses me off when trying to edit a entry doesn't reveal the original code I used to create the entry, like on some message boards.) Additionally, this might include storage of relational data (forward and backward links) and the transformed viewable information.
Storing the raw page data in a flat file system would be feasible, but most techniques I can think for getting this to work would require either a heck of a lot of reparsing at run time (running potentially quadratic or higher time when doing data export). A annotated version might require a convoluted file format.
Actually, at this point I'm still trying to figure out why some wiki projects regard a flat file system as a feature. Maybe it will come to me later.
Another option is just to work with the data all in memory and rely on the .NET serialziation facilities to read and write the whole mess all at once. But this also seems bad with respect to the thousands of pages in the project thing.
Eh. But don't listen to me, I don't know what I'm talking about.
