滚动您自己的明文 Wiki（数据库内的 Wiki）

发布于 2024-07-15 02:30:49 字数 522 浏览 12 评论 0原文

有人知道用于创建类似 wiki 的数据存储的 API（最好是 PHP，但我对任何语言都感兴趣）？

关于滚动您自己的纯文本 wiki 的任何资源怎么样？其他纯文本 wiki 如何处理文本文件的格式？

我知道我可以使用 Markdown 或 Textile 进行格式化。但我最感兴趣的是如何处理多用户编辑的明文存储。

我正在编写一个主要由数据库驱动的 Web 应用程序。我希望该数据库的至少一个文本字段采用类似 wiki 的格式。具体来说，该文本可以由多个用户编辑，并且能够回滚到任何版本。想想 Last.FM 的 wiki/bio 部分（几乎整个网站都具有严格的结构）通过数据库（每个艺术家的这一部分除外）。

到目前为止，我将 MediaWiki 拆开并将其插入数据库的方法似乎有点矫枉过正。我认为推出我自己的纯文本 wiki 并将此文件存储在数据库的相应文本字段中会更容易。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

一抹苦笑 2024-07-22 02:30:49

所以，基本上这是“如何在数据库中版本化文本信息”。

嗯，最简单的方法就是复制数据。

简而言之，创建一个保存数据“旧版本”的“版本”表，并将其链接回主表。

create table docs {
    id integer primary key not null,
    version integer not null,
    create_date date,
    change_date date,
    create_user_id integer not null references users(id),
    change_user_id integer references users(id),
    text_data text
}

create table versions {
    id integer primary key not null,
    doc_id integer not null references docs(id),
    version integer,
    change_date date,
    change_user integer not null references users(id),
    text_data text
}

每当您更新原始文档时，您都会将旧文本值复制到此表中，复制用户并更改日期并更改版本。

select version, change_date, change_user, text_data 
    into l_version, l_change_data, l_change_user, l_text_data 
from docs where id = l_doc_id;

insert into versions values (newid, l_doc_id, l_version, 
    l_change_date, l_change_user, l_text_data);

update docs set version = version + 1, change_date = now, 
    change_user = cur_user, text_data = l_new_text where id = l_doc_id;

如果您的数据库支持这些，您甚至可以在触发器中执行此操作。

此方法的缺点是它是数据的完整副本（因此，如果您有一个大文档，则版本会保持很大）。您可以通过使用 diff(1) 和 patch(1) 之类的东西来缓解这种情况。

例如：

diff version2.txt version1.txt > difffile

然后您可以将该 diff 文件存储为“版本 1”。

为了从版本 2 恢复版本 1，您需要获取版本 2 数据，使用 diff 文件数据对其运行补丁，这样您就可以得到 v1.1 版本。

如果要从 v3 转到 v1，则需要执行两次（一次获取 v2，然后再次获取 v1）。

这会减轻您的存储负担，但会增加您的处理能力（显然），因此您必须判断要如何执行此操作。

So, basically this is a "how do I version text information in my DB".

Well, the simplest way is simply copying the data.

Simply, create a "version" table that holds "old versions" of the data, and link it back to your main table.

create table docs {
    id integer primary key not null,
    version integer not null,
    create_date date,
    change_date date,
    create_user_id integer not null references users(id),
    change_user_id integer references users(id),
    text_data text
}

create table versions {
    id integer primary key not null,
    doc_id integer not null references docs(id),
    version integer,
    change_date date,
    change_user integer not null references users(id),
    text_data text
}

Whenever you update your original document, you copy the old text value in to this table, copy the user and change date and bump the version.

select version, change_date, change_user, text_data 
    into l_version, l_change_data, l_change_user, l_text_data 
from docs where id = l_doc_id;

insert into versions values (newid, l_doc_id, l_version, 
    l_change_date, l_change_user, l_text_data);

update docs set version = version + 1, change_date = now, 
    change_user = cur_user, text_data = l_new_text where id = l_doc_id;

You could even do this in a trigger if your DB supports those.

Faults with this method are that its a full copy of the data (so if you have a large document, the version stay large). You can mitigate that by using something like diff(1) and patch(1).

For example:

diff version2.txt version1.txt > difffile

Then you can store that difffile as "version 1".

In order to recover version 1 from version 2, you grab the version 2 data, run patch on it using the diff file data, and that gives you v1.

If you want to go from v3 to v1, you need to do this twice (once to get v2, and then again to get v1).

This lowers your storage burden, but increases your processing (obviously), so you'll have to judge how you want to do this.

回复收藏 0 原文

夏末 2024-07-22 02:30:49

威尔的巨大答案是正确的，但我认为可以总结一下：您需要存储版本，然后您需要存储元数据（谁在什么时候存储数据）。

但你的问题是关于类似 Wiki 版本控制的资源。我没有（好吧，一个：威尔的回答上面）。不过，关于Wiki的存储，我有一个。查看来自 DokuWiki 的比较矩阵。我知道。您在想“我关心不同 Wiki 使用什么品牌的 DB？” 因为 DokuWiki 使用纯文本文件。你可以打开它们，它们确实很简单。所以这是一种方法，他们有一些有趣的论据来解释为什么 DBMS 不是最好的方法。它们甚至不保存太多元数据：大部分内容都是通过平面文件本身完成的。

DokuWiki 对您的意义在于，也许这是一个相对简单的问题（取决于您想要解决它的程度:)

回复收藏 0 原文