High-Performance-wiki-Schema

Question

Ich bin mit MS SQL Server 2005.

Was ist das beste Schema für ein Wiki-ähnliches System? wo Benutzer bearbeiten / eine Vorlage überarbeiten und das System verfolgt diese Einreichungen.

Lassen Sie uns sagen wir ein einfaches Wiki-basiertes System tun. Wird den Überblick über jede Revision sowie Ansichten und aktuelle Aktivität jeder Revision. In anderen Bildschirmen wird das System Liste „Letzte Veröffentlichungen“ und „Meist gesehen“, und die Suche nach Titel.

Mein aktuelles Schema (und ich weiß, seine schlecht) ist eine einzelne Tabelle. Als ich die „Neuesten Veröffentlichungen“ Ich sortiere nach „LatestActivity“ sehen muß, Gruppe von „Document“, nehmen Sie dann die ersten N Datensätze. Ich gehe davon aus viel Gruppierung (vor allem auf nvarchar Gruppierung) ist eine schlechte Nachricht. Ich habe auch das gleiche für die am häufigsten betrachteten Auflistung sortieren: Ansichten, Gruppen mit Namen, erste N Aufzeichnungen nehmen. Die meiste Zeit werde ich auch „‚% QUERY-HERE%‘WHERE Document LIKE“ tun ein werden.

Mein aktuelles Schema ist "Version 1", siehe unten: alt text http://www.anaimi.com/junk/schemaquestion.png

Ich nehme an, dies nicht akzeptabel ist. Also ich versuche, mit einem anderen / mehr performanten Design zu entwickeln. Wie funktioniert Version 2 Sound für Sie? In zwei Version habe ich den Vorteil der Gruppierung auf WikiHeadId, die eine Zahl ist, -. Ich gehe davon aus Gruppierung über eine Zahl als nvarchar besser ist

oder der Extremfall, die Version 3 ist, wo ich keine Gruppierung tun, aber einige Nachteile, wie das Duplizieren Werte hat, diese Werte im Code beibehalten, etc.

oder gibt es ein besseres / bekanntes Schema für solche Systeme?

Danke.

(von ServerFault bewegt - ich denke, es ist eine Entwicklung Frage mehr als eine IT-Frage)

Answer 1

Als erstes (und aus Neugier) wie funktioniert das aktuelle Schema angeben, was die aktuelle Version ist? mehrere ‚WikiDocument‘ Einträge mit dem gleichen Document Haben Sie gerade haben?

Ich bin auch nicht klar, warum Sie bei einer Version Ebene eine ‚LastActivity‘ benötigen. Ich sehe nicht, wie ‚LastActivity‘ passt mit dem Konzept einer ‚Version‘ - in die meisten Wikis, die ‚Versionen‘ sind einmal: Wenn Sie eine Version ändern, dann bist du Erstellen eines neue Version, so das Konzept eines auf der Version Typen Wert aktualisierte letzten bedeutungslos ist -. es Datecreated 'wirklich ist nur

Wirklich, das 'natürliche' Schema für Ihr Design ist # 2. Persönlich bin ich ein bisschen ein Fan der alten DB Axiom ‚normalisieren, bis es weh tut, dann denormalize bis es funktioniert.‘ # 2 ist ein sauberer, schöner Entwurf (einfach, ohne Doppel), und wenn Sie keinen dringenden Grund haben, auf Version 3 bis denormalize, würde ich nicht stören.

Letztlich kommt es auf diese: Sorgen Sie sich über ‚performanter‘ -Design, weil Sie Performance-Probleme beobachtet haben, oder weil Sie hypothetisch können einige haben? Es gibt keinen wirklichen Grund # 2 sollte auch nicht durchführen. Gruppierung ist nicht unbedingt eine schlechte Nachricht in SQL Server - in der Tat, wenn es eine entsprechende abdeckenden Index für die Abfrage, kann es sehr gut durchführen, weil es nur auf ein bestimmtes Niveau im Index navigieren können die gruppierten Werte zu finden, verwenden Sie die restlichen Spalten des Index auf MIN / MAX / was auch immer zu verwenden. Gruppierung von NVARCHAR ist nicht besonders schlimm - wenn es nicht zu beobachten ist, ein Problem zu sein, ärgern Sie sich nicht darüber, wenn auch (nicht binär) Sortierungen kann es ein wenig schwierig machen - aber in der Version 2, wo Sie brauchen, um GROUP BY Sie können es durch WikiHeadId tun, nicht wahr?

Eine Sache, die das Leben leichter machen können, wenn Sie eine Menge von Operationen auf die aktuelle Version zu tun (wie ich nehme an, Sie würden), ein FK zurück aus dem Kopfende des Tisches, um den Körper Tabelle hinzuzufügen, die aktuelle Version anzeigt. Wenn Sie die aktuelle Versionen anzeigen möchten mit der höchsten Anzahl von Treffern, die mit # 2, wie es jetzt steht es könnte sein:

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

oder alternativ

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

beide sind eklig. Wenn der WikiHead einen Zeiger auf die aktuelle Version hält, es ist nur

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

oder was auch immer, die eine nützliche Denormalisierung sein können, nur weil es Ihnen das Leben leichter macht, nicht für die Leistung.

Answer 2

Überprüfen Sie diese aus.

Es ist das Datenbankschema für mediawiki , was wikipedia basiert.

Es sieht ziemlich gut dokumentiert und wäre eine interessante Lektüre für Sie sein.

Von diesem .