The reason I want to keep metadata at the end of the file is that if I do open the file up in a text editor, the metadata is at the end. The first thing I see is the narrative page content, and I can edit that easily. If that is the only thing I am changing, then I don't even have to scroll down to the metadata section. Other relevant metadata value, namely, the mtime, will get changed by the operating system.
One disadvantage of keeping the metadata in the same file is that I can't tie the metadata to a hash, or can't change just the metadata without changing the text as well. So, if I have to change any of the metadata, I have to rewrite the entire file even if I am not changing any of the file text. An alternative would be to store the metadata in a DBM-type hash... but that is more than the "simplest thing that could work."
There is the issue of speed, but it seems to me that this could scale very well. Even though my personal blog/wiki will likely not exceed a few thousand (or a few tens of thousand) pages in a life-time, I can't see this slowing down. As long as I have the name of a page, I have its location, and I am going (or rather, having the operating system go to it) directly. Should work for any number of files.
Thoughts?
In reply to Re^4: Moving from SQL to flat-files
by punkish
in thread Moving from SQL to flat-files
by punkish
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |