erhaltene Daten gleich direkt aufbereiten

[veryhot]

In der Programmierung gibt es ein Kozept, wonach man die Ausgabe schon beim Speichern von Daten erzeugt.

Es kommen also Daten via Formular beim Server an. Dieser speichert nicht nur diese Rohdaten, sondern diese auch schon in einer Form verarbeitet, wie sie dann ausgegeben werden. Man speichert dann also z b. einen html-Text, der dann bei Requests nur noch ausgelesen werden muss.

Es ist ja richtig, dass das aus Sicht der Performance toll ist, aber in jeder anderer Hinsicht halte ich diese Idee für schlecht.

Angenommen, ich habe 1.000.000 Einträge in der Datenbank (das ist echt nicht viel). Wenn ich am Design der Webseite etwas ändern möchte, müsste ich alle Rohdaten auslesen und in der veränderten Form auch gleich wieder speichern. Arbeite ich hingegen mit dem üblichen Konzept, muss ich nur etwas an der Ausgabe herumfummeln. Dieses spezielle Konzept ist also sehr unflexibel.

Auch kommen jedes mal Unmengen an Daten hinzu, wenn ich sie z b nicht nur in html-Form, sondern vielleicht auch in xml-Form, für E-Mails oder sonst wie weiterverwenden möchte. Es bedeutet also auch einen wesentlich erhöhten Speicherbedarf.

Mich würde eure Meinung dazu interessieren. Habt ihr dieses Konzept schon jemals eingesetzt? Und falls ja, wo habt ihr die Daten abgelegt? In unterschiedlichen Datenbankmanagementsystemen?

[hausl]

In der Programmierung gibt es ein Kozept, wonach man die Ausgabe schon beim Speichern von Daten erzeugt.

Sowas in der Richtung? http://php-de.github.io/jumpto/eva-prinzip/

Angenommen, ich habe 1.000.000 Einträge in der Datenbank (das ist echt nicht viel). Wenn ich am Design der Webseite etwas ändern möchte, müsste ich alle Rohdaten auslesen und in der veränderten Form auch gleich wieder speichern.

Also ich versteh ehrlich gesagt nicht was du genau meinst. Was hat das Design mit DB-Einträgen zu tun? Bzw. was verstehst du unter "einem DB-Eintrag"?

[veryhot]

Was hat das Design mit DB-Einträgen zu tun?

Ich meine eine DataView-Database. Eine Datenbank, die nicht die Rohdaten enthält, sondern die in einer Form bereits verarbeiteten Daten, die dann bei einem Request nur noch ausgelesen werden müssen, ohne noch irgendwie für die Ausgabe aufbereitet werden zu müssen.

https://de.wikipedia.org/wiki/CQRS#m...Datei:CQRS.svg

[VPh]

Ich denke du hast da etwas falsch verstanden.

Das QCS-Prinzip besagt, dass eine Methode entweder als Abfrage (query) oder als Kommando (command, modifier oder mutator) implementiert werden soll. Eine Abfrage muss hierbei Daten zurückliefern und keine Nebeneffekte auf dem beobachtbaren Zustand des Systems aufweisen, während ein Kommando beobachtbare Nebeneffekte aufweist und keine Daten zurückliefert.

Heißt für mich: Ein select soll keine Daten verändern, ein z.B. Update keine Daten zurückgeben

Keine Ahnung wo du das mit dem HTML speichern hernimmst.

[hausl]

Eine Datenbank, die nicht die Rohdaten enthält, sondern die in einer Form bereits verarbeiteten Daten,

Hast du dazu ein Beispiel? Was verstehst du unter Rohdaten und bereits verarbeitete Daten?

[rkr]

Ich würde auch gerne ein Beispiel zu diesem Thema sehen. Bislang habe ich nur WTF-Fragezeichen ueber dem Kopf. Warum sollte mir sowas nuetzen?

[Arne Drews]

Das erklärt sich doch hieraus:

Es kommen also Daten via Formular beim Server an. Dieser speichert nicht nur diese Rohdaten, sondern diese auch schon in einer Form verarbeitet, wie sie dann ausgegeben werden. Man speichert dann also z b. einen html-Text, der dann bei Requests nur noch ausgelesen werden muss.

...mit "Roh"-Daten meint er die per POST übermittelten. "Verarbeitet" heißt für ihn quasi schon als HTML verwurstet.

@veryhot: Die Frage ist ohne praktisches Beispiel aber nicht zu beantworten.
Wir wissen nicht, um was für Daten es sich handelt und wie und wann die wo ausgegeben werden sollen.

Ein Beispiel für eine sinnvolle Speicherung von HTML in einer DB, sind Shop-Systeme, die die Artikelbeschreibung in HTML dort ablegen.

Ob das allerdings was mit dem zu tun hat, was Du treibst, kann keiner von uns wissen.
Da mußt Du schon konkreter werden, wenn Du sinnvolle Antworten haben willst.

[veryhot]

Ein Beispiel für eine sinnvolle Speicherung von HTML in einer DB, sind Shop-Systeme, die die Artikelbeschreibung in HTML dort ablegen.

Ja zum Beispiel genau so etwas.

[hausl]

Ich habe den Thread jetzt nochmals gelesen, sorry, ich versteh es immer noch nicht, worauf du genau hinaus willst.

Angenommen, ich habe 1.000.000 Einträge in der Datenbank (das ist echt nicht viel). Wenn ich am Design der Webseite etwas ändern möchte, müsste ich alle Rohdaten auslesen und in der veränderten Form auch gleich wieder speichern. Arbeite ich hingegen mit dem üblichen Konzept, muss ich nur etwas an der Ausgabe herumfummeln. Dieses spezielle Konzept ist also sehr unflexibel.

Auch kommen jedes mal Unmengen an Daten hinzu, wenn ich sie z b nicht nur in html-Form, sondern vielleicht auch in xml-Form, für E-Mails oder sonst wie weiterverwenden möchte. Es bedeutet also auch einen wesentlich erhöhten Speicherbedarf.

Was stört dich dann daran, bzw. wie willst du es anders machen, irgendwie musst du deine Daten ja halten, wo wenn nicht in einer DB? Irgendwo brauchst du ja die (um bei dem Beispiel zu bleiben) Formatierungen zu dem Text, wie sonst willst du zB in einer Artikelbeschreibung ein Wort unterschrichten oder fett oder andersfarbig darstellen, also direkt dort?

Wie gesagt, ganz hab ich's noch nicht kapiert wo das hinführen soll.

[erc]

Ja zum Beispiel genau so etwas.

Nein, nicht genau so etwas. Eine Produktbeschreibung hat nix mit Rohdaten zu tun. Die Eingabe ist die Ausgabe. Anders sieht es aus wenn du die Produktbeschreibung aus einem Template erstellst und als Eingabe x Felder hast, deren Werte dann in das Template eingefügt werden. Die Frage ob man das beim Speichern macht oder bei der Ausgabe lässt sich aber nicht pauschal beantworten, da spielen zu viele Faktoren eine Rolle.
Wenn du eine Antwort willst musst du konkreter werden!

[Talker]

Ich glaub der TE fragt nach Erfahrung mit dem Konzept das er vorgestellt hat.

Also Vorteil von Artikelseite als html in der Datenbank halten (höhere Performance, mehr Speicherbedarf) gegenüber nur Artikelnr, Artikelbeschreibung in der Datenbank halten und dann vom CMS/whatever zur htmlseite zusammensetzen lassen (geringere Performance, niedrigerer Speicherbedarf).

Richtig verstanden?


Edit: schon wieder zuspät -.-