Erik Moeller wrote:
Timwi-
Please do take a look at the Wookee parser module that Tarquin pointed to.
It uses a syntax very similar to Wikipedia's.
http://wiki.beyondunreal.com/wiki/Wookee
Aw! You're taking all the fun out!
How about I write my own first, and if you don't like it, we can still
change it to Wookee?
Yes, point
taken, but I don't expect the switch to happen soon :-) In
fact, I don't really /expect/ the switch to happen at all, I regard it
all as an experiment. Even if Wikipedia won't ever use my software, it
was still a lot of fun and very educational to write it.
Sure. And if it's a decent wiki, you can add it to
http://c2.com/cgi/wiki?WikiEngines
and hope that people use it for other purposes.
Whoa. I didn't know there were so many Wiki engines already. Does none
of them meet your needs better than Phase-3? (I guess not, because
otherwise you probably would have switched, no?)
I think
it's better to store them in a database.
I never understood this approach.
I suppose you're thinking there's an increased risk of data corruption
because the database is all one file, and you're thinking if one bit of
the file gets corrupted, it's all gone.
Not necessarily. But if the database file is corrupted, the database may
no longer process the table correctly, in which case the binary data would
have to be hand-extracted to rescue it.
But if the directory structure gets corrupted, the file system may no
longer process the directory correctly, in which case the binary data
would have to be hand-extracted to resue it.
If you see the database as another
layer on top of the file system, and argue that the same risks apply to
the DB as to the filesystem, then you have doubled your risks by adding a
DB layer.
So far I was only talking about the effects of a failure, not the causes
of them. It is not a given that the possible causes or their probability
are doubled by adding a DB layer.
The most likely cause is a hardware failure. Quite obviously, the
probability of this happening does not increase with the addition of a
DB layer, nor does the amount of damage it can do.
Another possible cause is a bug in the software. Of course, the extra DB
layer adds the risk of there being a bug in the RDBMS, but since the
whole database is just one file, it reduces the risk of a bug in the
OS's file system somewhat.
The
"reduced performance" argument is something I don't know anything
about; it is possible that this is a good argument, but I'm not convinced.
Well, then test it. Throw some 10 megabyte files into the database and
compare the reading performance with multiple threads to direct Apache
server access.
I've thought about something. In order to change one image into another,
in the DB you just use one REPLACE query. With a DB/file system hybrid
as you are suggesting, you would have to
1) write the new version of the image to a new file
2) change the filename in the database
3) delete the old file
But yeah, I'll test this somehow (I'm not a real expert at performance
testing either...)
Now to your
question, "What exactly is the disadvantage of just storing
a pointer to the local filesystem in the DB?" - The disadvantage is that
it is more difficult to maintain a consistent state, i.e. a database
without "dead links" and a file system free of orphans.
Sure, but given that you only have to deal with create, move, delete
implementation complexity is minimal, and the associated risks should be
low.
That list is not quite complete - I have listed other uses that you seem
to have ignored. Taking a backup (of a consistent state) would be
difficult. Splitting the database into several (clustering) would be
difficult. It would make replication difficult. Of course these are all
administrative issue that the user never comes in contact with ...
In addition, I *like* being able to just zip the
entire image
directory instead of having to extract the files from a MySQL table.
That is, of course, one possible advantage, but I'm not quite convinced
this possibility/feature is so widely and often needed.
Check out perldoc perltoot for details.
Thank you.
Greetings,
Timwi