Ad alte prestazioni wiki-schema

Question

Sto utilizzando MS SQL Server 2005.

Qual è il miglior schema per un sistema Wiki-come? dove gli utenti modificare / rivedere una presentazione e il sistema tiene traccia di queste osservazioni.

Diciamo che stiamo facendo un semplice sistema wiki-based. Non mancherà di tenere traccia di ogni revisione, più punti di vista e le attività più recenti di ogni revisione. In altre schermate, il sistema elencherà "Ultimi Inseriti" e "I più visti", più ricerca per titolo.

Il mio schema corrente (e so che la sua cattiva) sta usando una singola tabella. Quando ho bisogno di vedere le "Ultime Presentato" Io ordina per "LatestActivity", gruppo da "DocumentTitle", quindi prendere primi dischi N. Presumo un sacco di raggruppamento (in particolare raggruppamento su nvarchar) è una cattiva notizia. Messa in vendita di più vista anche io faccio lo stesso: ordina per vista, gruppo per nome, prendere primi dischi N. La maggior parte del tempo, sarò anche facendo un "WHERE DocumentName LIKE '% query QUI%'".

Il mio schema corrente è "Version 1", vedi sotto: alt text http://www.anaimi.com/junk/schemaquestion.png

Suppongo che questo non è accettabile. Così sto cercando di trovare con un altro disegno / più performante. Come fa Versione 2 suono a voi? Nella versione a due ho il vantaggio di raggruppamento su WikiHeadId che è un numero -. Sto assumendo che raggruppa più di un certo numero è meglio di nvarchar

O il caso estremo che è la versione 3, in cui non lo farò raggruppamento, ma ha diversi svantaggi come la duplicazione di valori, il mantenimento di questi valori nel codice, ecc.

o c'è una migliore / schema noto per tali sistemi?

Grazie.

(spostato da ServerFault - penso che sia una domanda di sviluppo più di una questione IT)

Answer 1

In primo luogo (e per curiosità) in che modo lo schema corrente indicare ciò che la versione corrente è? Non basta avere più voci 'WikiDocument' con lo stesso DocumentTitle?

Non ho anche chiaro sul perché avete bisogno di un 'LastActivity' ad un livello di versione. Io non vedo come 'LastActivity' si adatta con il concetto di 'Version' - in più wiki, le 'versioni' sono write-once: se si modifica una versione, allora sei la creazione di un nuovo versione, in modo che il concetto di un ultimo aggiornato valore del tipo della versione è priva di significato -. E 'davvero solo 'DateCreated'

In realtà, lo schema di 'naturale' per il vostro disegno è # 2. Personalmente, io sono un po 'di un fan della vecchia DB assioma di 'normalizzare fino a soffrire, allora denormalizzare finché non funziona'. # 2 è un pulito, più bello di progettazione (semplice, senza duplicazione), e se non hai motivo urgente per denormalizzare alla versione 3, non mi preoccuperei.

In definitiva, si tratta di questo: ti preoccupi design 'più performante' perché hai potuto notare i problemi di prestazioni, o perché si ipoteticamente potrebbe avere un po '? Non c'è alcun motivo reale # 2 non dovrebbe funzionare bene. Il raggruppamento non è necessariamente una cattiva notizia in SQL Server - in realtà, se c'è un indice di copertura adeguato per la query, si può eseguire molto bene perché può semplicemente passare a un livello particolare nell'indice per trovare i valori raggruppati, quindi utilizzare le restanti colonne dell'indice da utilizzare per MIN / MAX / qualcosa. Il raggruppamento per NVARCHAR non è particolarmente grave - se non è osservata ad essere un problema, non preoccupatevi su di esso, anche se (non binari) collations può rendere un po 'difficile - ma in versione 2, in cui è necessario GROUP bY è possibile farlo da WikiHeadId, giusto?

Una cosa che può rendere la vita più facile, se si fa un sacco di operazioni sulla versione corrente (come si farebbe supporre), per aggiungere un FK dal tavolo testa alla tabella di corpo, che indica la versione corrente. Se si desidera visualizzare le le attuali versioni con il più alto numero di visite, con 2 # Così com'è ora potrebbe essere:

SELECT TOP ...
FROM WikiHead
INNER JOIN 
  (SELECT WikiHeadId, MAX(WikiBodyVersion) /* or LastUpdated? */ AS Latest 
   FROM WikiBody GROUP BY WikiHeadId) AS LatestVersions
INNER JOIN WikiBody ON 
  (Latest.WikiHeadId = WikiBody.WikiHeadId)
  AND (WikiBody.WikiBodyVersion = LatestVersions.Latest)
ORDER BY 
  Views DESC

oppure

...
INNER JOIN WikiBody ON 
  (WikiHead.WikiHeadId = WikiBody.WikiHeadId)
  AND (WikiBody.WikiBodyVersion = 
    (SELECT MAX(WikiBodyVersion) FROM WikiBody WHERE WikiBody.WikiHeadId = WikiHead.WikiHeadId)
...

entrambi i quali sono icky. Se il WikiHead mantiene un puntatore alla versione attuale, è solo

...    
INNER JOIN WikiBody ON 
  (WikiHead.WikiHeadId = WikiBody.WikiHeadId)
  AND (WikiHead.Latest = WikiBody.WikiBodyVersion)
...

o qualsiasi altra cosa, che può essere un utile denormalizzazione solo perché rende la vita più facile, non per le prestazioni.

Answer 2

questo fuori.

E 'lo schema del database per MediaWiki , ciò che Wikipedia si basa su.

Sembra piuttosto ben documentato e sarebbe una lettura interessante per voi.

Da questo .