[dokuwiki] Re: dokuwiki using mysql and Re: proposals

Hi Chaps,

Just thought I would add the following point with regards to
database performance. In the cases where pages are
constructed dynamically but are in fact largely unchanging
then we'd use the cache in the same way that the flat
file system is at the moment. Subsequent accesses to the
page would go to the cache and the db performance is
irrelevant.

Although the database would be good for indexing and
text searching, it isn't the only method. Indexes could
be created on the flat files and stored in its own file(s).
A search script would then use this/these index files(s)
to return search results. Obviously, a database does
a lot of this work for you but it's not impossible with
flat files.

I personally prefer the flat file system and it was one of
the major plus points whilst evaluating the many wikis
out there.

Many thanks guys for being here to support this great
product!

Cheers,
Lee


On 7/29/05, Mario Emmenlauer <marioemmenlauer@xxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Hi,
> 
> Harry Fuecks wrote:
> > I think Andi has made exactly the right decision to store content in
> > flat files. Aside from obvious reasons like it's easy to administer
> > flat files from the command line, when it comes to storing content,
> > placing documents in a database is like fitting a round peg into a
> > square hole.
> 
> You have some good points there. I am already very much relieved that
> this didn't start a 'should have db/shouldnt have db'-war on the list,
> so some scepticism is the least I expected.
> 
> It's quite important to me to note:
> *If* dokuwiki should support db, it should come at no cost for users
> and for devels. (meaning: should not make any more work whatsoever for
> developers, and should not decrease performance etc. when using the
> file-based version.)
> 
> But, to the best of my knowledge, that's possible.
> As you cited, as much as a filesystem is a database, as much is a
> database a file system:-). If all file accessing functions (read,
> write, fileexists and filedate) have equivalent db counterparts, all
> other dokuwiki functions can stay as they are. These four functions are
> quite simple to implement for filesystems as well as db access, so
> future improvements are unlikely. Therefore it should also be unlikely
> that any devel has to make changes to db support (or should even notice
> it's there) in the future. (I would offer keeping an eye on security.)
> 
> For the performance-part, my patches would only add some additional
> condition checks (sort of: if ($conf['usemysql']) do ...) on every
> file access, so performance decrease of the file-based version should
> be negligible.
> 
> This way, db access doesn't use it's full potential, since all I use
> is translating file access to table access. But that way dokuwiki
> can get it both (db and files). And actually, even by using the full
> db potential not too much speed could be gained, as long as the wiki
> doesn't grow over several hundreds or thousands of pages (in which
> case it would be up to the database implementation to be still fast:-)
> 
> > From my point of view the only reason why people are asking for MySQL
> > is because they're running on a shared host with limited access /
> > permissions to the file system and / or no shell access (or perhaps
> > not enough experience with Bash). While I can understand the problem
> 
> At least many of them, I guess! My reason is integrating backup
> strategies for a cms, forum and a wiki. Since the first two are sql-
> based, it would get messy to make sql dumps _and_ run tar every night.
> 
> But still: DokuWiki is (one of?) the best wiki(s) currently out there,
> with mediawiki having really messy php code and wikka being still
> immature (even though promising!) in some features. It would be quite
> sad if everyone with a flat php/mysql-webspace could't use it.
> 
> Anyone interested in the current state of development is very welcome
> to take a look at
>         http://dokuwiki.marssoft.de
> and email me in case of found errors/misbehavour.
> I haven't had time to do any testing, so don't expect everything to
> work right away, but most stuff should be fine by now.
> 
> Cheers,
>    Mario
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFC6YG2dr6lwuqb+oIRAnufAJ9AT3RXXuV4z72pqgZ+2DPe9ya1YQCdHO9K
> d3Qivmqsoo8iuyf67UE9Hf4=
> =kfrR
> -----END PGP SIGNATURE-----
> --
> DokuWiki mailing list - more info at
> http://wiki.splitbrain.org/wiki:mailinglist
> 


-- 
__________________________________________________________
See Lee's and Ania's latest photos: http://www.byphotos.com/album/1166401
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts: