滚动你自己的纯文本维基(DB内的维基)。[英] Rolling Your Own Plaintext Wiki (Wiki inside a DB)

本文是小编为大家收集整理的关于滚动你自己的纯文本维基(DB内的维基)。的处理/解决方法,可以参考本文帮助大家快速定位并解决问题,中文翻译不准确的可切换到English标签页查看源文。

问题描述

任何人都知道API(PHP可取,但我对任何语言都感兴趣)用于创建类似Wiki的数据存储?

在滚动自己的明文Wiki上有什么资源如何?其他明文Wikis如何处理文本文件的格式?

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

我正在编写一个主要是数据库驱动的Web应用程序.我希望该数据库的至少一个文本字段以Wiki式格式为单位.具体来说,该文本可以由多个用户编辑,能够回归任何版本.想想 last.fm (几乎整个网站都是严格结构的结构,由数据库除外,除了每个艺术家).

到目前为止,我将MediaWiki分开并楔入数据库的方法似乎是过分的.我认为滚动自己的明文Wiki并将此文件存储在数据库的适当文本字段中会更加容易.

推荐答案

因此,基本上这是一个"我如何在我的数据库中启动文本信息".

好吧,最简单的方法就是简单地复制数据.

简单地创建一个保存数据的"旧版本"的"版本"表,然后将其链接回主表.

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)和补丁(1)之类的东西来减轻这种情况.

例如:

diff version2.txt version1.txt > difffile

然后,您可以将该差异存储为"版本1".

为了从版本2中恢复版本1,您可以获取版本2数据,使用diff文件数据在其上运行补丁,这为您提供了V1.

如果您想从V3到V1,则需要两次(一次获得V2,然后再获得V1).

这会降低您的存储负担,但会增加您的处理(显然),因此您必须判断您想如何做到这一点.

其他推荐答案

Will的巨大答案是正确的,但我认为可以概括:您需要存储版本,然后您需要存储元数据(何时数据).

但是您的问题是关于Wiki式版本控制的资源.我没有(一个:一个: will的答案上面).但是,关于Wiki的存储,我有一个.查看 dokuwiki的比较矩阵.我知道.您在想:"我关心什么品牌的不同Wikis使用什么品牌?"因为Dokuwiki使用纯文本文件.您可以打开它们,它们确实很普通.因此,这是一种方法,他们有一些有趣的论点,即为什么DBM不是最好的选择.他们甚至没有太多的元数据:大多数内容都是通过平面文件本身完成的.

dokuwiki的目的是,这也许是一个相对简单的问题(取决于您要解决的能力:)

其他推荐答案

以下是Wikimatrix上所有12个Wiki的列表,它们用PHP编写,并使用文本文件进行存储.也许其中之一将具有您可以适应数据库的存储方法:

http://www.wikimatrix.org/search.php?sid=1760

本文地址:https://www.itbaoku.cn/post/597467.html

问题描述

Anyone know of an API (php preferable but I'd be interested in any language) for creating wiki-like data storage?

How about any resources on rolling your own plaintext wiki? How do other plaintext wikis handle the format of the text file?

I understand I can use Markdown or Textile for the formatting. But what I'm most interested in is how to approach the plaintext storage of multi-user edits.

I'm writing a web application that is primarily database driven. I want at least one text field of this database to be in a wiki-like format. Specifically, this text can be edited by multiple users with the ability to roll back to any version. Think the wiki/bio section of Last.FM (almost the entire site is strictly structured by a database except for this one section per artist).

So far, my approach of taking apart MediaWiki and wedging it into a database seems like overkill. I'm thinking it would be much easier to roll my own plaintext wiki, and store this file in the database's appropriate text field.

推荐答案

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.

其他推荐答案

Will's huge answer is right on, but can be summed up, I think: you need to store the versions, and then you need to store the metadata (who what when of the data).

But your question was about resources on Wiki-like versioning. I have none (well, one: Will's answer above). However, about the storage of Wikis, I have one. Check out the comparison matrix from DokuWiki. I know. You're thinking "what do I care what brand of DB different Wikis use?" Because DokuWiki uses plain text files. You can open them and they are indeed plain. So that's one approach, and they've got some interesting arguments as to why DBMS are not the best way to go. They don't even hold much metadata: most of the stuff is done through the flat files themselves.

The point of the DokuWiki for you is that maybe it's a relatively simple problem (depending on how well you want to solve it :)

其他推荐答案

Here's a list of all 12 wikis on WikiMatrix that are written in PHP and do their storage using text files. Perhaps one of them will have a storage method you can adapt into the database:

http://www.wikimatrix.org/search.php?sid=1760