Zugriff auf CMS_VAR im Output teil

[ctschorsch]

Hallo zusammen,

ich darf nach längerer Zeit wieder ein Contenido Projekt anpacken und einiges ergänzen. Jetzt habe ich folgendes Problem:


Ein Webseitenbesucher kann auf der Webseite verschiedene Checkboxoptionen auswählen. Sehr gerne würde ich jetzt in einer CMS_VALUE Variable mitzählen wie oft eine bestimmte Option ausgewählt wurde. Leider ist ja der direkte Zugriff auf CMS_VAR nicht möglich im Outputteil und in der Datenbank sind die Variablen sehr umständlich gespeichert.

Hat jemand eine Idee wie es am einfachsten umzusetzen ist ?

Gruss
Georg

[Oldperl]

Hallo Georg,

warum nimmst du nicht eine einfache Textdatei und zählst dort deine Zähler hoch?

Gruß aus Franken

Ortwin

[ctschorsch]

das wäre zu einfach

nein, natürlich hast du recht, sehr gute idee sogar.
bleibt aber die frage ob es über die datenbank irgendwie geht

Danke
Gruss
Georg

[Oldperl]

das wäre zu einfach

Hmm ja, das dachte ich mir...

bleibt aber die frage ob es über die datenbank irgendwie geht

Definitiv, am einfachsten über eine Mandanten-Propertie. Dafür gibt es Funktionen sowohl zum Setzen als auch zum Lesen.
Ich denke aber das es mit einer Datei einfacher und performanter geht. Für solche "Merker" versuche ich DB-Zugriffe zu vermeiden, da sich dort allein schon der Verbindungsaufbau zur DB nicht rechnet.

Gruß aus Franken

Ortwin

[kummer]

Definitiv, am einfachsten über eine Mandanten-Propertie. Dafür gibt es Funktionen sowohl zum Setzen als auch zum Lesen.

Diese sind zum Zählen einigermassen schlecht geeignet, da diese nicht typengerecht sind. Es handelt sich dabei um ein Quasi-EAV. Bloss, dass alle Werte als Typ Text gespeichert sind. Grundsätzlich möglich, jedoch aus meiner Sicht wenig praktikabel.

Ich denke aber das es mit einer Datei einfacher und performanter geht. Für solche "Merker" versuche ich DB-Zugriffe zu vermeiden, da sich dort allein schon der Verbindungsaufbau zur DB nicht rechnet.

Die Datenbankverbindung steht zu diesem Zeitpunkt ja schon. Typischerweise sogar mehrfach. Also mindestens eine offene Verbindung steht sicher. Im Modulbereich über die globale Variable $db. Wenn die Verbindung steht, läuft ein Update in deutlich weniger als 1 ms ab. Das Dateisystem ist in der Tat sehr schnell; diese zusätzliche Leistungseinbusse tritt jedoch nur bei einer Interaktion auf und darf als marginal angesehen werden. Gegen das Dateisystem spricht die Art und Weise, wie ein Zugriff für ein sicheres Zählen vorgenommen werden müsste. Also sperren, auslesen, hochzählen, schreiben und anschliessend wieder sperren. Und das auch gleich noch mehrfach. Man sollte dabei nicht vergessen, dass mehrere Anwender gleichzeitig einen Schreibzugriff vornehmen könnten. Und dazu ist eine Sperre erforderlich.

Die einfachste Lösung dürfte deshalb die DB sein. Also eine Tabelle mit Bezug zum Artikel (idartlang), zur Checkbox (je nachdem als Relation oder auch als Varchar) sowie ein Integer, der die Anzahl Klicks repräsentiert. Also zum Beispiel so:

Code: Alles auswählen

CREATE TABLE  `mytable` (
`idartlang` INT UNSIGNED NOT NULL ,
`id` VARCHAR( 255 ) NOT NULL ,
`checks` INT UNSIGNED NOT NULL DEFAULT  '0',
PRIMARY KEY (  `idartlang` ,  `id` )
) ENGINE = MYISAM ;

Dann lässt sich das Hochzählen mit einem einfachen Update vornehmen. Angenommen die idartlang ist 12 und die Checkbox-ID ist myCheckBox, dann sieht das Update wie folgt aus:

Code: Alles auswählen

update mytable set checks = checks + 1 where idartlang = 12 and id = 'myCheckBox';

Und dabei bestehen dann auch keine Probleme beim gleichzeitigen Zugriff. Kein Sperren erforderlich. Bei mir lokal dauert diese Abfrage 0.3 ms. Das entspricht bei Conenido einem Overhead von geschätzten 0.05 %. Dürfte also kein Problem sein.

Wenn man bereit ist, die con_art_lang in eine innoDB-Tabelle umzustellen (das hat ansonsten keine negativen Konsequenzen), dann kann man auch eine automatische Löschweitergabe zu diesen Informationen vornehmen.

[Oldperl]

Hmmm

Natürlich kann man nun (wieder mal) aus einer Mücke einen Elefanten machen.
Der Kollege wollte einen einfachen Mehrfachzähler. Dazu bietet sich immer eine Zählerdatei an.

Gegen das Dateisystem spricht die Art und Weise, wie ein Zugriff für ein sicheres Zählen vorgenommen werden müsste. Also sperren, auslesen, hochzählen, schreiben und anschliessend wieder sperren. Und das auch gleich noch mehrfach.

Ganz im Gegenteil, da ich hier nur einfache einstellige Zähler habe, kann ich diese problemlos in einer Datei unterbringen, zumal offensichtlich deren Anzahl bekannt ist.
Und auch in der DB müßte ich entsprechend Massnahmen für ein "sicheres Zählen" vorhalten.

Aber wie auch immer, mag es Jeder machen wie er will, ich hab anderes zu tun als deswegen eine Grundsatzdiskussion vom Zaun zu brechen.

Gruß aus Franken

Ortwin

[kummer]

Man mag über einiges unterschiedlicher Meinung sein. Klar. Aber sperren musst du in der DB gar nichts. Genau dazu ist sie da. Im Dateisystem hingegen hat du keine Transaktionssicherheit. Du musst also den Wert auslesen, dann um eins erhöhen und anschliessend wieder speichern. Wenn bei zwei gleichzeitigen Zugriffen die Datei geöffnet wird, erhalten beide Requests denselben Wert und speichern folglich auch wieder denselben. Dann ist der Wert jedoch nur um eins hochgezählt worden, anstatt um zwei, wie es richtig wäre. Bei der vorgeschlagenen Variante mit einem Update ist das nicht der Fall, da dieser Abfrage als Einzeltransaktion abgesetzt wird und eine Interferenz mit einem anderen simultanen Zugriff ausgeschlossen ist.

Dann zur Frage der Einfachheit. Wenn man es in der DB macht, genügt für das ganze eine einzige Zeile; die Verbindung zur DB steht längst (Contenido hat zu diesem Zeitpunkt bereits mehrere Dutzend Abfragen abgesetzt). Bei der Variante Dateisystem musst du die Datei zunächst verriegeln, dann öffnen, den Wert auslesen, um eins erhöhen, speichern und die Verriegelung wieder frei geben. Das sind dann mindestens 7 Zeilen. Sind nicht alle Zähler in der gleichen Datei ist das dann für jede selektierte Checkbox zu wiederholen. Beim Update kannst du alle betroffenen Zähler gleichzeitig erhöhen (vgl. Beispiel). Bei aller Leistung, die ein Dateisystem aufweist, ist das bereits bei nur einer Checkbox langsamer und verschlechtert sich mit jeder weiteren.

Code: Alles auswählen

update mytable set checks = checks + 1 where idartlang = 12 and id in ('myCheckBox', 'myOhterCheckBox', 'andEvenAThirdOne');

Soweit ich das sehe, wurde nachgefragt, wie er es am einfachsten lösen könne. Eine Zeile dürfte die einfachste Variante repräsentieren. Denn bei aller Einfachheit soll das Resultat ja zutreffend sein, nehme ich mindestens mal an. Ausserdem ist anzunehmen, dass diese Daten ja dann auch noch irgendwo angezeigt werden sollen. Womöglich mit Bezug zum Artikel. Dann wird es im Dateisystem immer komplizierter.

Wer sich von hinten rum durch's Knie bohrt, darf sich dann nicht wundern, wenn die Systemleistung nachlässt und die Resultate unerwartet ausfallen.

Und auch in der DB müßte ich entsprechend Massnahmen für ein "sicheres Zählen" vorhalten.

Tja, dieser Meinung darf man durchaus sein. Ein Blick in die Dokumentation (http://dev.mysql.com/doc/refman/5.0/en/update.html) verrät dir vielleicht beim aufmerksamen lesen, dass das nicht zutreffend ist.

[ctschorsch]

Tach zusammen,

hui, da hab ich ja ne Diskussion losgebrochen das tut mir leid. Vielen Dank auf jeden Fall für die hilfreichen Tips.
Ich werde wohl die Variante von kummer nutzen, da ich das Problem mit dem gleichzeitigen Zugriff schon für problematisch halte und ich da bei Datenbanken ein besseres Gefühl habe.
Ich hab verdrängt das ich nicht nur auf die Contenidotabellen zugreifen kann, sonder beliebige eigene machen kann )

Danke an alle für das abnehmen des Bretts von meinem Kopf

Gruss aus dem sonnigen Aachen
Georg

[Oldperl]

Hallo Georg,

na dann ist das Problem ja gelöst.

Gruß aus Franken

Ortwin

[kummer]

hui, da hab ich ja ne Diskussion losgebrochen das tut mir leid.

Kein Problem. Das braucht dir nicht leid zu tun. Immerhin nimmt ja freiwillig an einer solchen Diskussion teil.

[ctschorsch]

Ah, eine Sache hab ich noch


die Sache mit der innoDB Was genau ist das ? Und was bedeuted es für mich ?
Kann ich mir das so vorstellen, das wenn ich den Artikel mit der idartlang x lösche auch die counter die sich auf idartlang x beziehen gelöscht werden ?
Das wäre kuuuuuuuuuuuuhl

Gruss
Georg

[kummer]

Das ist ganz genau so. Dazu ist allerdings die Abbildung einer referenziellen Integrität mit Löschweitergabe erforderlich. Und die gibts bei MyISAM-Tabellen (Normaleinstellung) nicht, bei innoDB-Tabellen schon. Das Vorgehen ist relativ einfach:

1. Zunächst wie immer einen Dump der Datenbank erstellen. Die Umstellung von myISAM auf innoDB sollte zwar nicht stören. Aber man weiss ja nie und will auf der sicheren Seite sein.
2. Dann in phpMyAdmin einsteigen und die Tabellle con_art_lang auswählen und in den Tabs 'Operation' wählen. Bei mir ist es Englisch. Wie's deutsch heisst, weiss ich offen gestanden nicht. Es müsste das dritte Tab von rechts sein.
3. Dort kannst du nun die Storage engine auf innoDB umstellen.
4. Bei der neuen Tabelle wählst du bereits beim Anlegen innoDB.
5. In der neuen Tabelle hast du ja auch ein Feld mit der Bezeichnung idartlang. Dieses muss vom gleichen Typ sein, wie idartlang der Tabelle con_art_lang und das Feld muss einen Index aufweisen.
6. Bei der Strukturansicht der neuen Tabelle müsstest du nun einen Link finden, der bei mir (englisch) 'relation view' heisst. Dort klicken und anschliessend den Bezug zum Feld idartlang der Tabelle con_art_lang erzeugen. In der zweiten Spalte unter der Spaltenbezeichnung 'ON DELETE' wählst du aus dem Dropdown-Feld die Option 'CASCADE'.
7. Von jetzt an werden die Einträge automatisch gelöscht, wenn die entsprechenden Einträge in der con_art_lang gelöscht werden. Durch die referentielle Integrität ist auch ausgeschlossen, dass du eine Speicherung für eine idartlang vornimmst, die es gar nicht gibt.

Nachtrag: Ich bin mir fast sicher, all das würde im Dateisystem noch viel viel besser gehen... Und einfacher noch dazu. Aber das ist wissen, das der Allgemeinheit nicht zugänglich ist.

[Oldperl]

Nachtrag: Ich bin mir fast sicher, all das würde im Dateisystem noch viel viel besser gehen...

Nein, nein, das kann MySQL in seinem "virtuellen" Speicher selbstverfreilich viel besser.

Gruß aus Franken

Ortwin

[kummer]

Nein, nein, das kann MySQL in seinem "virtuellen" Speicher selbstverfreilich viel besser.

Das sind dann eben Themen, die du vielleicht einmal bei MySQL anbringen kannst. Die können offenbar von Contenido noch so einiges lernen, wie es scheint. Vielleicht haben sie für dich ein offenes Ohr. Wobei ich annehmen muss, dass der Umgang von MySQL mit den Ressourcen nicht wirklich bedeutend schlechter ist als der von Contenido. Aber was weiss ich schon...

Es würde sich übrigens lohnen, einmal ein Profiling zu machen, damit man nicht darüber spekulieren muss, wo wieviel Leistung auf der Strecke bleibt. Es lohnt sich nämlich nicht, dort zu sparen, wo der Überhang gering ist. Man muss die grossen Lecks stopfen. Und wer sich auf die Suche macht, wird schnell fündig werden. Dort gibt es dann wirklich was einzusparen.

[ctschorsch]

Hey,

danke kummer, das scheint ja nicht so schwierig zu sein. dann instaliere ich mal myphpadmin, bin bisher mit der mysql-console gut zurecht gekommen, aber da find ich die dinge bestimmt nicht so schnell

Gruss
Georg