As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened,
visit the help center作为指导。
7年前关闭。
我正在寻找有关如何使用PHP和MySQL构建Wiki的良好教程。我需要一些东西来向我展示如何构造mysql数据库以及为文本diff等实现哪些算法。到目前为止，我发现的唯一一个是：
http://www.ibm.com/developerworks/opensource/tutorials/os-php-wiki1/但这是基于cakePHP的，我必须花一个月的时间学习cakePHP才能了解他们的工作。
预先感谢您的任何提示！
假设您是出于教程的缘故进行此操作（因为那里已经有很多出色的Wiki软件），让我们看看我是否无法解决该主题的一般性概述。当然，在这个答案中，我没有时间或空间来编写整个Wiki，如果我这样做的话，您也不会学到任何东西。但是，我将尝试布局一般框图并给出数据库模式的示例。
首先，考虑一下您的Wiki需要的不同页面。不是信息页面，而是实际上您将拥有的不同功能页面。
一页用于解析请求（查找他们请求的文章并向他们发送信息）
一页用于编辑文章
一页用于登录
根据您要获得的简单程度，您仅需要三页。您的“主页”和任何其他重要页面（“联系我们”，“关于我们”，“如何使用此Wiki”等）都可以是文章，因此可以按照解析请求的方式来处理它们。拥有功能正常的Wiki之后，您可以考虑添加以下内容：
修订跟踪（每篇文章的更改日志）
文章下载器（使用PHP模块将文章输出为PDF，txt或其他格式，然后使用header()作为下载内容发送）
媒体查看器（如在Wikipedia上一样，当您单击图像时，它会将您带到一个页面，其中包含有关该图像的信息，上载者，其大小等）。
还有什么，要有创造力！ =）
由于我们还没有一个可运行的Wiki，因此要实现这些需要花费更多的时间和精力，所以让我们从基本的三页开始。这些页面中的每个页面都应具有自己的框图，或者它们必须执行的简单功能列表（具体的实现方式，我将由您自己确定）
对于文章分析脚本：
首先，它必须找到他们要查找的文章。这可能涉及在执行搜索之前解析其搜索字符串（将“ the_nile_river”转换为“ The Nile River”），或者可能需要进行一些比较才能找到最相关的帖子（请参阅“ The Nile”并重定向至“ The Nile River”）。 。 Wiki的这一部分可以无限改进，因为还没有人开发出“完美”的搜索算法。
如果找不到该文章，则您需要具有一些错误状态。给出建议的文章列表，继续搜索以在每篇文章的正文中查找其术语而不是标题，或者道歉并要求他们再次搜索。优质的Wiki将始终为他们提供创建文章的能力（如果文章不存在）（指向文章编辑页面的链接）
如果可以找到该文章，则它必须能够将该文章的内容转换为HTML。对于极其简单的文章，这可能只是使用htmlentities()将类似&的内容转换为&的问题。但是，随着文章变得越来越复杂，您可能需要一种方法来显示标题，指向其他文章的链接等。为此，您可能希望使用特殊的模板解析，以便使您的用户无法直接控制HTML。我从来没有亲自编码其中之一，但是我可以想象它有很多preg_replace()语句。
最后，您需要考虑要显示哪些页眉/边栏/页脚信息。如果登录，此信息可能会有所不同，可能包含指向相关文章的链接，并且可能具有用于编辑本文的链接。
至于编辑文章，此页面可能是最简单的。我会做以下事情：
检查他们是否已登录
如果是，请给他们一个<textarea>，其中预先填充了原始文章，但没有进行分析
如果不是，请向他们道歉并告诉他们登录。提供指向登录页面的链接
至于登录页面，如果您曾经与多个用户进行过某种编码，那么您将了解其工作原理。
检查是否设置了$_POST["username"]。如果是这样，他们已经发送了他们的登录信息。如果没有，请向他们发送登录表单。 （用户名，密码，提交）
如果已设置，则对密码进行哈希处理（加盐！），将其与数据库中的哈希进行比较，如果它们匹配，则启动会话。如果不匹配，请向他们道歉并再次发送登录表格。
就数据库的外观而言，您几乎有一个需要的表（每个人都将其放在数据库中，并且出于安全原因，没有人会将其信任到平面文件中）。
users
-----
id (int)
username (string)
hashed_password (string)
extra info (email, website, last seen, preferences, etc.)
一个包含所有用户登录信息的表。至于文章本身，您可以选择将其存储在数据库或文件中。 MediaWiki将所有内容存储在MySQL中，但是DokuWiki使用TXT文件。这在某种程度上是个人喜好问题，但是还有其他一些事情需要考虑。
MySQL行的大小是固定的。可以将这个大小设置为令人难以置信的大字符，例如16777216个字符，但是仍然有一个限制，即最大文章大小。 TXT文件可以任意增大（
http://dev.mysql.com/doc/refman/4.1/en/storage-requirements.html）
如果系统上有许多文件，则打开和读取文件的速度会变慢。防止在某些系统上而不是在其他系统上（取决于所使用的文件系统）起作用的速度降低的一个技巧是制作多个文件夹。例如，每一个以“ ab”开头的文章（“ Abdominals”，“ Absorbency”，“ Abel（圣经角色）”等）都位于一个文件夹中，而每一个以“ ac”开头的文章都位于另一个文件夹中。
理论上，由于您必须通过SQL Server进行身份验证，因此TXT文件会带来更多的安全风险。通过将TXT文件放在webroot之外并正确设置权限（700或类似权限），可以消除此安全风险
通过将其保存在数据库中，可以更轻松地存储有关文章的元数据（在文章的内容旁边，在“最后编辑”，“编辑者”，“最后搜索”等地方有单独的列。）可以存储在TXT文件中，但这要困难得多，因为您需要考虑元数据的定界符，并且必须在不损害文件其他内容的情况下对其进行编辑。
如果要将文章存储在数据库中，我建议进行类似于以下的设置：
articles
--------
id (int)
title (tinyblob)
content (mediumblob)
meta info
添加功能时，您可能也开始需要这些功能的数据库表。例如，如果您要为每个图像都有一个媒体查看器页面（而不仅仅是让文章显示图像），那么您需要考虑以下几点：
具有图像链接和图像信息的数据库
从模板中引用图像的方法
基于数据库值解析该引用的方法
为了让您考虑可能包含的某些功能以及这些功能将如何影响数据库，以下是MediaWiki的数据库：
http://upload.wikimedia.org/wikipedia/commons/4/41/Mediawiki-database-schema.png