2009-03-04 10 views
6

Qualcuno sa di un'API (php preferibile, ma sarei interessato a qualsiasi lingua) per la creazione di archiviazione di dati simile a un wiki?Rolling Your Own Wiki in testo semplice (Wiki all'interno di un DB)

Che ne dici di qualsiasi risorsa sul tuo wiki in testo normale? Come fanno gli altri wiki in testo normale a gestire il formato del file di testo?

Capisco che posso usare Markdown o Textile per la formattazione. Ma quello che mi interessa di più è come avvicinarmi all'archivio in chiaro delle modifiche multiutente.

Sto scrivendo un'applicazione Web principalmente basata su database. Voglio che almeno un campo di testo di questo database sia in un formato simile a un wiki. In particolare, questo testo può essere modificato da più utenti con la possibilità di eseguire il rollback a qualsiasi versione. Pensa alla sezione wiki/bio di Last.FM (quasi l'intero sito è strettamente strutturato da un database ad eccezione di questa sezione per artista).

Finora, il mio approccio di smontare MediaWiki e incunearlo in un database sembra eccessivo. Sto pensando che sarebbe molto più facile stampare il mio wiki in chiaro e archiviare questo file nel campo di testo appropriato del database.

+0

Se sei in grado di aggiungere nuove tabelle nel database o qualcosa del genere? Non sto seguendo perché vuoi creare un wiki "in chiaro" all'interno di un database. Forse non sto capendo la tua terminologia. –

+0

Vorrei l'equivalente di una singola pagina wiki memorizzata in un singolo campo di testo nel mio database – ack

+0

Ìt non è chiaro se la risposta alla tua domanda è, "MySql ha un tipo di testo per grandi cose" o se stai chiedendo qualcosa di più complesso sul controllo delle versioni ecc. –

risposta

15

Quindi, in pratica si tratta di un "come si visualizzano le informazioni di testo nel mio DB".

Bene, il modo più semplice è semplicemente copiare i dati.

Semplicemente, creare una tabella "versione" che contiene "vecchie versioni" dei dati e collegarla alla tabella principale.

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 
} 

Ogni volta che si aggiorna il documento originale, si copia il valore di testo vecchio in questa tabella, copiare la data di utente e il cambiamento e urtare la versione.

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; 

Si può anche fare questo in un trigger se il DB supporta quelli.

I guasti con questo metodo sono una copia completa dei dati (quindi se si dispone di un documento di grandi dimensioni, la versione rimane grande). Puoi attenuarlo usando qualcosa come diff (1) e patch (1).

Ad esempio:

diff version2.txt version1.txt > difffile 

Quindi è possibile memorizzare che difffile come "versione 1".

Per recuperare la versione 1 dalla versione 2, si acquisiscono i dati della versione 2, si esegue la patch su di esso utilizzando i dati del file diff e ciò fornisce v1.

Se si desidera passare da v3 a v1, è necessario farlo due volte (una volta per ottenere v2, e quindi di nuovo per ottenere v1).

Questo riduce il carico di archiviazione, ma aumenta l'elaborazione (ovviamente), quindi dovrete giudicare come volete farlo.

+0

bel approccio, vedrò questo! – ack

+0

Meravigliosamente semplice ed efficiente rispetto a mediawiki http://upload.wikimedia.org/wikipedia/commons/4/41/Mediawiki-database-schema.png – Cherian

+0

btw hai bisogno di change_date date e change_user_id integer fa riferimento agli utenti (id) in la tabella dei documenti? non può essere dedotto dalla tabella delle versioni? – Cherian

0

Ecco un elenco di tutti i 12 wiki su WikiMatrix scritti in PHP e che si archiviano utilizzando i file di testo. Forse uno di loro avrà un metodo di archiviazione è possibile adattare nel database:

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

0

Sembra che si sono essenzialmente solo in cerca di controllo della versione. In tal caso, potresti voler esaminare un algoritmo diff.

Questa è la pagina Wikipedia Diff.

Ho fatto una ricerca su google php diff veloce, ma in realtà nulla si è distinto come esempio decente, dal momento che ho solo conoscenze di base di PHP.

2

La risposta enorme di Will è giusta, ma può essere riassunta, penso: è necessario archiviare le versioni e quindi è necessario memorizzare i metadati (chi che cosa quando dei dati).

Ma la tua domanda riguardava le risorse su versioni di tipo Wiki. Non ne ho (beh, uno: Will's answer above). Tuttavia, riguardo l'archiviazione di Wikis, ne ho uno. Controlla the comparison matrix from DokuWiki. Lo so. Stai pensando "cosa mi importa di quale marca di DB usano i diversi wiki?" Perché DokuWiki usa solo file di testo. Puoi aprirli e sono davvero semplici. Quindi questo è un approccio, e hanno alcuni argomenti interessanti sul motivo per cui i DBMS non sono il modo migliore per andare. Non contengono nemmeno molti metadati: la maggior parte delle cose avviene attraverso i file flat stessi.

Il punto del DokuWiki per voi è che forse è un problema relativamente semplice (a seconda di quanto bene si vuole risolverlo :)