Quotirerung, statistic(), Datenbank für Inhalte

Question

Hi,

wir haben eine Studie wo wir auf Marken Quotieren müssen. In der Vergangenheit habe ich da die statistic() Funktion genutzt. Jetzt habe ich verstanden, dass die Anwendung auf eurer Seite viel Rechenleistung braucht und es unökomisch ist, Auswertungen auf den gesamten Datensatz zu machen. Stattdessen wird empfohlen mit Datenbank für Inhalte zu arbeiten, richtig?

Könnt ihr mir nur kurz Bestätigen, dass das richtig ist, bevor ich alles aufsetze und es dann nicht funktioniert.

Mein Gedanke ist Folgender:
Ich hole mit mit dbget() die Anzahl an Markenbewertungen und überschreibe anschließend mit dbset() den Wert+1. Jetzt habe ich aber gelesen, dass nur

false|string|array

Daten gespeichert werden können. Ist es auch möglich int zu speichern?

Alternativ würde ich jetzt folgendes machen und mit arrays arbeiten:

 // 
$COUNTRYID = 1;
$BRAND_CODE = value('AB01');
$VAR_NAME = 'COMPORIGIN';

// key generieren
$key = $VAR_NAME."_".$COUNTRYID."_".$BRAND_CODE;
// get array mit Markenbewertungen, für jede Berwertung speichere ich eine 1 im array
$n	=	dbGet($key);
registerVariable($n);

// Auszählung der Summe, Anzahl Markenbewertungen
$n_sum = array_sum($n);

$nMax = 100;

if ($n_sum >= $nMax) {
	redirect($RD_QuotaFull_link, 'true');
}


###############################
// Auf der letzten Fragebogenseite, wenn sicher ist, dass das Interview nicht abgebrochen wurde, würde ich das Interview zählen:

array_push($n,1);
dbset($key,$n);

Oder doch lieber mit statistic() arbeiten?

LG

Answer 1

Ja und nein.

Ineffizienz ist statistic() dann, wenn es für jeden Aufruf den kompletten Datensatz laden muss. Das haben wir inzwischen insofern optimiert als bei > 500 Datensätzen ein Caching zum Einsatz kommt und dass man statistic() sagen kann, dass es bitte alle Variablen einmal vorab laden soll (s. auch https://support.soscisurvey.de/?qa=43939/).

Für <5 statistic()-Aufrufe im Rahmen einer Quotierung kann man die Funktion also bedenkenlos einsetzen, und wenn man vorab noch alle Variablen laden lässt, ist man sicher im grünen Bereich.

Die Datenbank für Inhalte ist auch ganz nett, uns wäre im Prinzip deutlich effizienter. Aber sie hat den Nachteil, dass man sich schnell einmal verzählt. Wenn die Seite mit dem dbSet() zum Beispiel via "Seite neu laden" erneut geladen wird und man hat das nicht vorgesehen, dann hat man den Fall schnell mal doppelt gezählt.

Ich würde daher bei der Quotierung tendenziell zu statistic() raten. SoSci Survey packt schon einiges (wenn man nicht gerade einen Datensatz mit 25.000 Fällen sammelt und dort quotiert, da gabe es schon Speicherprobleme) und eine robuste Implementierung hat schon einige Vorzüge.

Auf der Wunschliste für SoSci Survey steht eine bequemere Funktion für Quotierungen. Mehr Klicken weniger Programmieren, effizienter. Aber bis diese verfügbar ist, wird es leider noch ein wenig länger dauern.

Comments

Danke für die schnelle Antwort. Wenn ich jetzt aber auf die letzte FBSeite dbset() integriere, wo keine Frage mehr angezeigt wird, die also für den Befragten gar nicht sichtbar wäre und der Respondent mit einem redirect direkt zum Panel zurückgeleitet wird, müsste das Risiko einer Doppelzählung doch gebannt sein oder?

Da es eine große internationale studie ist, kann es schon gut sein das wir mehr als 25k angefangene Interviews haben werden.

---

> müsste das Risiko einer Doppelzählung doch gebannt sein oder?

Ja, *müsste* es. Aber nur, weil mir spontan kein Szenario für eine Doppelzählung einfällt, heißt das nicht, dass es kein Restrisiko gibt. Wobei wir hier nicht von Größenordnungen sprechen, welche die Erhebung gefährden würden. Zumal man die Zahlen ja gelegentlich kontrollieren kann, wenn die Studie ohnehin über einen längeren Zeitraum läuft.