Datenbank oder HTML-Struktur?

[TS]

Hello,

ich überlege schon länger, welches Datenmodell nebst Darstellung für den Aufbau einer größeren Fachinformationsseite besser ist. Es gibt immer ca. 15 bis 20 Hauptkapitel mit jeweils ca. 10-20 Unterkapiteln, die dann jeweils bis zu 50 Diskussionspunkte (Beispiele mit Frage- und Antwortmöglichkeiten) haben können.

#Möglichkeiten:

• Datenbank (+ HTML für die Darstellung)
• reine HTML-Struktur
• gemischte Bauweise

Da die mögliche Schachtelungstiefe bei Frage-Antwort-Strängen ähnlich wie hier im Forum nicht unbedingt vorher bekannt ist und verschiedenste Objekte vorkommen können, dünkt mir, dass man mittels HTML-DOM-Parser vermutlich schneller zum Ziel kommt, als wenn man erst ein Datenmodell für die Datenbank aufbaut, dass dann ggf. auch ständig erweitert/umgebaut werden muss und für das man dann ohnehin HTML-Objekte für die Darstellung bauen muss.

#Vor- und Nachteile (Thesen):

• Beim Lösungsansatz mit reinem HTML hat man keine sofortige Trennung zwischen Markup und Inhalt
• Bei der Datenbanklösung lassen sich Rechtestrukturen leichter abbilden
• Bei der HTML-Lösung lassen sich unvorhergesehene Schachtelungen /Hierarchien) von Objekttypen leichter lösen (einfach ins DOM der jeweiligen Seite einhängen)
• Indizierung/Sortierung ist bei der DBMS-Lösung leichter
• Die Suche nach Inhalten kann bei der DBMS-Lösung schneller sein, muss aber nicht, da man sowieso meistens eine Volltextsuche benötigt

#Guter Rat ist gefragt:
Das Ganze ist, wie Ihr seht, noch unausgegoren. Ich suche daher Anregungen, auf was man noch alles achten müsste, um eine Entscheidung treffen zu können.

Liebe Grüße
Tom S.

[Regina Schaukrug]

Also... ist es für Deine Seminare? Da ist eine Datenbank eher nicht nötig, ggf. zu sperrig und der Transfer auf einen anderen Rechner möglicherweise zu arbeitsaufwendig.

Ich hab auf dem Trainerrechner (Laptop) eine Variante meiner Code-Seite. Ich habe da im Prinzip nur den serverseitigen Cache rausgenommen.

Aus meiner Sicht ein Vorteil: Kapitel [, Subkapitel [, Subkapitel]] sind schlicht und einfach Verzeichnisse.

Vorteil ist, dass ich eigene oder ggf. die Ressourcen aus Fachbüchern (Skripte und andere Textdateien, aber auch binäres Zeug für den Download durch die Teilnehmer - z.B. PDFs) einfach in ein Verzeichnis aufnehme (oder halt ein Verzeichnis lösche...). Eine Rechteverwaltung gibt es da freilich gar nicht erst, aber selbst das könnte man per Meta-Datei recht einfach regeln.

Die Hierarchie regelt sich durch die Verzeichnisstruktur, der Text-Content kommt aus 2 Metadateien die entweder in Markdown (also wie hier im Forum) oder JSON notiert sind, das Menü (bei mir das Dateilisting) kann aus der Verzeichnisstruktur errichtet werden. Die Suche geht mit dem Linux-eigenem grep. Das ist, zumindest in dem angedachtem Bereich schnell genug.

Das Sortieren regelt übrigens der Apache. Könnte man aber auch mit clientseitigem JS machen.

[Regina Schaukrug]

		<Directory …>
      …
			IndexOptions Charset=UTF-8 HTMLTable FancyIndexing IgnoreCase VersionSort SuppressHTMLPreamble SuppressRules TrackModified SuppressDescription XHTML FoldersFirst
			HeaderName /autoindex-files/header.html
			ReadmeName /autoindex-files/footer.html
			IndexIgnoreReset ON
			IndexIgnore  *.deleted *~ .description.md .description.json

		</Directory>

Die unter HeaderName und ReadmeName genannten Dateien dürfen nicht auf ".php" enden (das gab einen 500er). Aber: Zumindest wenn PHP als Modul läuft wirft der Apache die unter HeaderName und ReadmeName genannten Dateien trotz der Endung ".html" dem PHP zum Abarbeiten in den Schoß.

Warnung:

Das ist (wohl, habs nicht gefunden) nicht dokumentiert, kann demnach quasi jederzeit entfallen.

[TS]

Hello,

Also... ist es für Deine Seminare?

Dafür würde ich es später bestimmt auch einsetzen wollen.
Im Moment bastele ich an einer Ortsdarstellung, die alle Feitzeitaktivitäten, alle Einkaufsquellen, usw. abbilden soll.

Da ist schwer eine polymorphe Struktur zu erkennen, denn jeder hat andere Wünsche in den Unterkategorien.

Wesentlich für mich wäre, dass man bei der reinen HTML-Variante mittels CK-Editor o.ä. den Nutzern Module zur Verfügung stellen kann, die sie selber leicht erwaitern können und sie trotzdem per PHP-DOM-Parser auf unerwünschte Manipulation prüfen kann.

Bei einem DBMS sind die Strukturen dann entweder sehr steif, oder man verzettelt sich leicht von Höckchen auf Stöckchen.

Liebe Grüße
Tom S.

[Gunnar Bittersmann]

@@TS

Wesentlich für mich wäre, dass man bei der reinen HTML-Variante mittels CK-Editor o.ä. den Nutzern Module zur Verfügung stellen kann, die sie selber leicht erwaitern können

Es sollte auch nicht schwerfallen, für Redakteure^[1] ein UI zu bauen, mit dem sie die strukturierten Daten bearbeiten können, die dann als JSON(-LD) gespeichert werden.

Bei einem DBMS sind die Strukturen dann entweder sehr steif

Bei JSON(-LD) sind die Strukturen sehr flexibel.

LLAP 🖖

---

1. Mit „Nutzer“ sind i.d.R. die Endnutzer der Webseiten gemeint. ↩︎

[TS]

Hello,

Stimmt, die Redakteure unter den Nutzern sind gemeint ;-)

Liebe Grüße
Tom S.

[Gunnar Bittersmann]

@@TS

#Möglichkeiten:

• Datenbank (+ HTML für die Darstellung)
• reine HTML-Struktur
• gemischte Bauweise

Mit „Datenbank“ meinst du ein DBMS? Dann habe ich noch eine Möglichkeit anzubieten:

• strukturierte Daten als JSON(-LD).

  Daraus wird über Templates serverseitig HTLM oder clientseitig das DOM generiert.

  Wenn die Daten strukturiert beim Client sind, ist auch Filterung oder Sortierung blitzschnell – wohl schneller als eine Anfrage an den Server.

LLAP 🖖

[pl]

hello,

wie wärs mit einem austauschbaren Layer für die Datenhaltung? Der Anwendung ist es doch egal wo die Daten herkommen. Überlege Dir eine zweckmäßige Datenstruktur mit welcher die Anwendung arbeitet. So hat jede Seite einen eindeutigen URL und Eigenschaften wie body, title, descr usw. Hierarchien können über eine Eigenschaft parent erzeugt werden. Und eine weitere Eigenschaft hängt ein Forum unten an die betreffende Seite.

Also egal aus welcher Datenquelle, die Struktur ist immer dieselbe und besteht im Wesentlichen nur aus Schlüssel=Wert Paaren.

MfG

[fr@gma]

Ich würde auch über XML nachdenken, wäre für mich hier die bevorzugte Wahl.

[Gunnar Bittersmann]

@@fr@gma

Ich würde auch über XML nachdenken, wäre für mich hier die bevorzugte Wahl.

Der Vorteil von XML gegenüber JSON(-LD) wäre welcher?

Mal abgesehen davon, dass man XML per XSLT in HTML transformieren kann? Was aber auch nicht wirklich ein Vorteil ist, da XSLT auch nicht wirklich einfacher zu handhaben ist als mit Templates und ein bisschen PHP bzw. JavaScript aus JSON das HTML/DOM zu generieren.

Ein kleiner Nachteil wäre die etwas sperrige Syntax von XML.

LLAP 🖖

[pl]

Ich würde auch über XML nachdenken, wäre für mich hier die bevorzugte Wahl.

Nun, 20 Hauptkapitel mit 20 Unterkapiteln, das ergibt 400 HTML Seiten. Und diese 400 Seiten in einer XML Datei zu speichern, darüber lohnt es sich nicht wirklich nachzudenkn.

Wobei das durchaus geht, 400 Seiten in einer Datei zu speichern aber ganz bestimmt ist das keine XML Datei. Und auch kein JSON.

MfG