I'm running a site that is going to need a way to keep track of updates. It's currently using no database for updaptes. They're simply kept in files in one directory. Symlinks are made from a category directory (such as "General.cat") to the actual file. Then I also have a directory for staff, which contains one directory per user (so /updates/staff/jquser/ would contain symlinks for jquser that point to the actual files in /updates/).

I recently started using dbm for some other work I was doing: storing staff passwords, email addresses, and other configuration. It's now easier to just open the dbm database and have all the values there to access. However, I wonder how I might apply this to my problem.

While I don't have many updates now (<30), I intend for there to be a good deal of them. Some not too large - a paragraph or so - others full editorial-sized posts. I know DBM has a limit to the number of bytes (1000, IIRC) it can hold, so storing an entire post would not be effecient. Also, I want to have as much static content as possible: serve just the HTML files for the posts and not make a Perl script read the post and print it every time someone views it.

So here's my dilemma: do I use DBM, first of all, or is there a better Perl-based DB to use? I don't have MySQL or any other DB program installed on my server, and even so, I've never used any other DB than dbm. I don't have the knowhow to interface with any other DB (at least yet), so hopefully it can be some fairly simple solution. If I use DBM, I have one of two options: have one fairly large DB file to hold all relevant information about the updates: who posted it, the subject, and the day/time posted (for archival purposes, it would be accessed fairly often to print out a list of recent updates by some user, in some category, or just most recent posts). The other option would be to have a few databases: one for "all updates," one per category, and one per staff member. When viewing the archives for posts by jquser, it would only need to open jquser's DB, and thus wouldn't have to sift through anyone else's posts.

I'm kind of leaning towards the second option because it would result in quicker access time for any given archive section. No need to sift through 150 posts to see the most recent 25 posts by jquser. However, in this case, there would be at least three times the disk space used; for each update, the info gets posted into the "all updates" db, the db for the specific category, and the db for jquser. Though there shouldn't be all that much in each DB - URL of the file (only one file, no symlinks in this case), day/time posted, posted by whom, their email address, subject, etc.

Pretty long-winded, but I hope someone out there has more experience with this kind of thing and can help me out.

Thanks!