Could DokuWiki use a database instead of text files?

It would be possible, but there was a reason for not doing it. DokuWiki was designed to hold documentation of all kinds. So what do you do when your database or your web server is down and the documentation to bring it up again is only accessible through this web server or database? Yikes! So DokuWiki stores all this vital information as plain text which is always readable, even if you only have some tape backups left of your beloved server .

Read on for some more reasons of not using a database.

Let's dispel the assumption that a Database Management System (DBMS) is the ideal repository for wiki information. That isn't to say a DBMS is the wrong choice, just to say that it's not the only choice and that using the file system in the way that DokuWiki does is in no way a bad choice for a wiki.

Before reading on, remember the characteristics of wiki data:

• read often, updated less often
• mixed and unstructured text content

A file system is an extremely efficient place for storing data. That's where a DBMS is likely to put its data. For simple retrieval a file system should beat the pants off a DBMS. Its quite likely a well constructed DBMS application will cache the results of its common queries in the file system for faster retrieval!

Additionally all modern file systems cache frequently accessed files in memory. Reading this data will not even hit the disks anymore.

Much of a DokuWiki's work is simple retrieval - get a file and show its contents possibly with some processing. This is very well suited to a file system. Databases excel when dealing with highly structured data and also where small pieces of that data are updated frequently. Wikis aren't like that.

Searching a wiki or more properly, indexing a wiki to enable quick searching is an area where DBMS technology can assist a wiki. DokuWiki implements its own indexing by creating a list of every “word” of three or more letters in the wiki. Partial searching is slower than it would be with a DB and it is more difficult to handle “advanced searches”, however for whole word searching it is a viable solution (i.e. the results are presented in a reasonable time when compared to other activities on the wiki). For a public wiki it's arguable that Google provides a better indexing service than any internal search could.

A DBMS can make it easier to cross the single server threshold. At its simplest, the DBMS is placed on one box and the web server / application component on another. It's arguable that DokuWiki could accomplish something similar by using NFS mounts to allow multiple locally remote (i.e. LAN connected) servers to access the wiki data directory tree.

For very large installations where the data will have to reside on multiple servers, instead of solving replication/synchronization issues the application can hand them off to a suitable DBMS.

Filesystem storage has other advantages as well. Because there is only one service (Webserver) instead of two (DBMS + Webserver) that has to be run on the server, installing the wiki is easier, the server requirements are lower and the fault tolerance is higher.

Backing up and restoring your data or moving the wiki to a different server is just a matter of copying files. Having your wiki data available in the file system makes it also easier to read or manipulate it with other tools or scripts.

See also:

• PMWiki documentation on flat file advantages

Even though DokuWiki does not use a database, you can access data stored in a database.

• DokuWiki has built-in support for accessing user authentication information in a database. See authentication backends.
• The data plugin adds structured data to your pages leveraging a SQLite database
• Check out plugins tagged with database for plugins to access database contents