Am 21.10.2011 um 15:52 schrieb Lee Passey:
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. Lee, I agree completely, that one should use the simplest tool. Yet, what does the simplest tool mean. For me, it means that the user/client of the system only sees and gets what they need. The complexity of the "back bone" is of no interest to them. It just works. A revision control system could work. You mention, also tracking differences. Well, if you just look at the individual tasks this kind of simplistic approach will suffice, but once you try to bring very thing together from the scans over OCR to proofing, and finally produce the ebook, you a have a pretty mix of scripts for handling things which cause problem when scaling or changes in the system is needed.
Also, RVS/CRUD system are not for the casual user. How do the users easily access the different version, branches or even find these. Sure you can offer up scripts to make it easy to understand, yet the task in general can be done in a database system, which already knows the structure of things and can automatically offer up the information and files needed. Please, understand the database system has to be designed for administering the task. That is not only handling the work of those that do proofing, production of ebooks, but also, those that must administer the sites offering up the files and books. regards Keith.