On Tue, October 18, 2011 2:28 pm, Bowerbird@aol.com wrote:
what you should have done instead is to write a program that can be dropped into a folder _with_ the files for a single book, which then _administers_ the transactions involving those files.
since most of the files are small, changes are not a big deal... besides, the fact is that most of the files will never be changed. even ones that _are_ changed will only undergo a few iterations. so there is nothing that's going to overwhelm the file-system...
I agree with BowerBird here. We programmers have a tendency to over-complicate things, and reinvent wheels when the old ones are working just fine. Sometimes it's a result of trying to use the tools we're most familiar with, trying to learn new tools that we find interesting, or just an expression of the NIH syndrome (Not Invented Here). My rule of thumb is to use the simplest tool that is appropriate to the job. In this case we appear to have a simple repository of texts, with perhaps some tracking of differences. We would also need a simple network interface that allowed CRUD on the files (Create, Read, Update, Delete). No cross-table joins, complex data structures, or fancy reporting. It seems to me that using the file system as the repository with a simple revision control system (RCS, CVS, etc.) managing access is completely adequate to the job. This has the added advantage of making it simpler for any sort of web server to serve the files for read-only access without having to have database access middleware. Now I'm not prepared to say that Mr. Frank was wrong in how he set up his site; heck, I can't even say that I know /how/ he set things up. He may have had requirements that were totally different than what I envision. But if I were setting up a site to simply allow read/write access to files while tracking changes, I'd use CVS and the file system unless other requirements forced me to reconsider.