[edit] 2004

[edit] Storing data in the filesystem

Hi,

i just found this page ad i am not sure if this is the right place to discuss my question, but probably someone will read it and redirect me:

was ever discussed not to store the articles themself into the database but in the filesystem directly and to store only additional infos like links, lastChange, ... in the database?

e.g. the article "Sweden" would be stored in

${CONFIGUREDBASE}/wiki/S/w/e/d/e/n/article

and it's history in

/whatever/wiki/S/w/e/d/e/n/article.1
/whatever/wiki/S/w/e/d/e/n/article.2
...

This would have some efforts while it's not slower then the current handling:

1. the database would be smaller
2. it would be possible to reconstruct most important parts of the database from filesystem
3. it is much easier to effectively use the hardware mirroring capabilities
4. diffs eg can be run without extracting the data from the database

Mijobe 11:33, 28 Jul 2004 (UTC)

Your idea is not new and has been shot down numerous times in the past. Moving the data from the database to the filesystem does not increase performance in any way. Diffs wouldn't be faster because now instead of extracting them from the database you have to extract them from the filesystem instead. etc. Thanks for your thoughts though. — Timwi 18:52, 29 Jul 2004 (UTC)

[edit] 2006

[edit] Table bans

I don't think its a good Idea to store ip as String, because IPv4-Adresses are just unsigned 32bit¹ Integers. The Table could be extended to block a userid by using a 1bit flag:

type ENUM ('User', 'IP')

1) 128bit for IPv6; IPv4 can get converted to IPv6 in that case

MovGP0 21:55, 26 February 2006 (UTC)