假设你这样做是为了教程（因为已经有很多很棒的wiki软件了），让我们看看我是否不能处理这个主题的一般概述。当然，我没有时间或空间在这个答案中编写一个完整的wiki，如果我这样做了，你也不会学到任何东西。但我将尝试列出一般的框图，并给出一个数据库模式的示例。

首先，考虑一下你的维基需要哪些不同的页面。不是信息页面，而是您将拥有的不同功能页面。

• One page for parsing requests (find the article they requested and send them the information)
• One page for editing articles
• One page for logging in

根据你想得到的简单或复杂程度，这是你只需要的三页。你的“主页”和任何其他重要的页面（“联系我们”、“关于我们”和“如何使用这个维基”等）都可以是文章，所以它们的处理方式与你解析请求的方式相同。有了功能性wiki后，您可以考虑添加以下内容：

• Revision tracking (log of changes to each article)
• Article downloader (use PHP modules to output the article to a PDF, txt, or some other format and send it as a download using header())
• Media viewer (as on wikipedia, when you click an image it takes you to a page with information about that image, who uploaded it, how big it is, etc.)
• Anything else, be creative! =)

由于我们还没有一个正常运行的wiki，所以实现这些需要额外的时间和精力，所以让我们从基本的三个页面开始。这些页面中的每一个都应该有自己的框图，或者它们必须执行的简单功能列表（具体实现方式我将留给您来确定）

对于文章解析脚本：

• First it has to find the article they re looking for. This could involve parsing their search string (converting "the_nile_river" to "The Nile River") before performing the search or it may require some comparing to find the most related post (seeing "The Nile" and redirecting to "The Nile River"). This part of the wiki you can improve upon infinitely, as no one has developed a "perfect" search algorithm yet.
• If the article can not be found, then you need to have some error state. Either give a list of suggested articles, continue the search looking for their terms in the body of each article instead of the title, or just apologize and ask that they search again. A good wiki will always offer them the ability to create the article if it doesn t exist (a link to the article editing page)
• If the article can be found, it needs to be able to translate the contents of the article to HTML. For extremely simple articles, this could just be a matter of using htmlentities() to convert things like & to &. As your articles get more complicated, though, you may want a way to display headers, links to other articles, etc. For this you would probably want to use special template parsing so as to give your users no direct control over the HTML. I ve never personally coded one of these, but I can imagine it has a lot of preg_replace() statements.
• Finally, you need to consider what header/sidebar/footer information to display. This information will probably be different if they re logged in, it may contain links to related articles, and it may have links to edit this article.

至于编辑文章，这个页面可能是最简单的。我会做以下事情：

• Check to see if they re logged in
• If yes, give them a <textarea> which is pre-populated with the original article sans parsing
• If no, apologize and tell them to log in. Provide a link to the login page

至于登录页面，如果你曾经与多个用户一起编写过一些代码，那么你就会明白这应该如何工作。

• Check if $_POST["username"] is set. If so, they ve sent their login information. If not, send them the login form. (username, password, submit)
• If it is set, hash the password (with a salt!), compare to the hash in the database, and if they match- start a session. If they don t match, apologize and send them the login form again.

就数据库的外观而言，您几乎需要一个单表（出于安全原因，每个人都会将其放在数据库中，没有人会将其信任为平面文件）。

users
-----
id (int)
username (string)
hashed_password (string)
extra info (email, website, last seen, preferences, etc.)

一个包含任何登录用户信息的表。至于文章本身，您可以选择将它们存储在数据库或文件中。MediaWiki将所有内容存储在MySQL中，但是DokuWiki使用TXT文件。这在一定程度上是一个偏好问题，但还有其他一些事情需要考虑。

• MySQL rows have a set size. This size can be set to something incredibly large like 16777216 characters, but there is still a limit, meaning a maximum article size. TXT files can grow arbitrarily large (http://dev.mysql.com/doc/refman/4.1/en/storage-requirements.html)
• Opening and reading files can go slower if there are many files on the system. A trick to prevent this slow-down that works on some systems and not others (depending on the file system in use) is to make multiple folders. For instance, every article that starts with "ab" ("Abdominals", "Absorbency", "Abel (Bible Character)", etc.) would be in one folder, and every article that starts with "ac" would be in another.
• TXT files theoretically pose slightly more of a security risk since you have to authenticate with an SQL server. This security risk can be nullified by putting the TXT files outside of the webroot and setting the permissions correctly (700 or similar)
• By keeping it in a database it s much easier to store meta-data about the article (right beside the article s content, have a separate column for "last edited", "edited by", "last searched", etc. This kind of data can be stored in a TXT file, but it s much harder since you d need to consider a delimiter for meta-data and you d have to edit it without harming the other contents of the file.

如果您要将文章存储在数据库中，我建议您进行类似于以下设置的设置：

articles
--------
id (int)
title (tinyblob)
content (mediumblob)
meta info

当您添加功能时，您可能也开始需要这些功能的数据库表。例如，如果你要为每幅图片都有一个媒体查看器页面（而不仅仅是让文章显示图片），那么你需要考虑以下几点：

• Database with link to image and information about image
• Method of referencing the image from within the template
• Method of parsing that reference based on the database values

为了让您思考可能包含的一些功能，以及这些功能将如何影响您的数据库，以下是MediaWiki的数据库：

http://upload.wikimedia.org/wikipedia/commons/4/41/Mediawiki-database-schema.png