Your points are good and valid. When I listed advantages in using a DB I was really thinking about my case: an heterogeneous and large portal. When you have to manage only a Wiki server, the file system strategy is surely a good solution because of its simplicity. But when you are dealing with hundreds of applications running on clusters, the administration is much easier if you have less elements to manage. In this case, the DB backup and recovery is done for the entire enterprise. You don't have to use different methods of recovery and monitoring for the applications "Wiki" and "Customer Relationship" (for example). The simplification even shortens the learning curve of operations personel.
I agree with you that we have always to look forward to simplicity, and don't use a resource just because it's cool. "Everything should be made as simple as possible, but not one bit simpler." -- Albert Einstein Stutz On 1/18/07, Murray Altheim <[EMAIL PROTECTED]> wrote:
Flavio Stutz wrote: > We have some advantages in using a DB based Wiki: Flavio, I won't argue that there aren't some advantages provided by using a database; there certainly are, but there are also disadvantages. But amongst your list I didn't see that a justification for a database as actually an improvement, ala: > - backup capabilities provided by database server; If the wiki using any of the file providers is on a server being backed up, its files will be backed up as well. One advantage is that the backup content is readily available (as files) whereas a backed up database must be restored en toto in order to access a single file. > - possibility to install Wiki server on cluster; With a file-based provider this is still possible; one just points the jspwiki.fileSystemProvider.pageDir property at a shared location. But this brings up a very real problem with clustered wikis: if there are more than one WikiEngine writing to either the file provider or a database provider, the WikiEngine doesn't have any mechanism to deal with that, i.e., if there are three machines in the cluster there are three WikiEngine instances all writing to the same provider. This problem is basically the same with either a file provider or a database provider. > - search and indexing provided by database server; Search and indexing are provided in JSPWiki by JSPWiki, not the backend provider. If the database server is providing indexing, that would be redundant to (and unsupported by) that already in JSPWiki (Lucene). > - the use of server disks are dangerous because when it's > full the server may go down (need monitoring); If one's disks are filling up the database solution is even worse because when the system fails it will likely corrupt the database, whereas with a file provider only the last file written (the one that hits the limit) wouldn't get written. But if one's server disk is filling up, that's a much bigger problem than any wiki should have to deal with, and I've never heard of this problem when using a hosted solution (i.e., it should NEVER happen on a professionally- run server). Database solutions are also more complicated to configure and install, to migrate between versions (or even databases), more difficult to debug, and also increase the size of the JSPWiki distribution (as was just posted, Hibernate is 8MB). But that said, databases *may* provide higher performance under some high-volume circumstances (though I've not seen this actually demonstrated) and can be a better solution when trying to integrate with existing content (though that kind of thing may be better handled by a real content management system), and if a metadata solution for JSPWiki is established, would be likely better hosted as part of the individual page record. That is certainly how I'm handling metadata in my own database solution, XNodeProvider, which is an XML database back-ended by Berkeley DB JE. This will be released along with Ceryle sometime fairly soon. Though I don't currently have any plans to extricate it from within Ceryle, if someone wanted to do that work I'd be *completely* supportive. I am looking for collaborators, any experienced Java programmers who want to take on any of the various plans at http://altheim.4java.ca/ceryle/wiki/Wiki.jsp?page=Ideas [every time I post a wiki URL I'm reminded that the short view constructor doesn't yet work reliably... *sigh*] If you want to take a look at XNode, tomorrow I'll try to remember to post the entire Ceryle javadoc API online (I just removed it when switching ISPs since the one there was obsolete). So if I do remember, it will be at: http://www.altheim.com/ceryle/api/ probably within 24-36 hours from now. One might note that Berkeley DB is now owned by Oracle. I'm hoping that means they'll *improve* it as opposed to what Novell did with SuSE linux after they bought it. Murray ........................................................................... Murray Altheim <[EMAIL PROTECTED]> === = = http://www.altheim.com/murray/ = = === SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = = In the evening The rice leaves in the garden Rustle in the autumn wind That blows through my reed hut. -- Minamoto no Tsunenobu _______________________________________________ Jspwiki-users mailing list [email protected] http://ecyrd.com/cgi-bin/mailman/listinfo/jspwiki-users
_______________________________________________ Jspwiki-users mailing list [email protected] http://ecyrd.com/cgi-bin/mailman/listinfo/jspwiki-users
