In folgendem Beitrag kann man über Probleme lesen, wenn zuviele Fragen in einem Survey sind:
[url] forums.limesurvey.org/forum/german-forum...zu-viele-teil-fragen [/url]
Solche Probleme kenn ich nun auch und möchte gerne wissen, ob sich hier technisch seit vor drei Jahren etwas getan hat.
Weiß das jemand?
Kennt jemand das Ausmaß an Änderungen, welches benötigt wird, dieses Problem zu lösen?

WilliPuhdlich wrote: Solche Probleme kenn ich nun auch und möchte gerne wissen, ob sich hier technisch seit vor drei Jahren etwas getan hat.
Weiß das jemand?
 

Da hat sich technisch nichts verändert. Eine grundlegende Änderung der Datenbankstrukturen wäre notwendig, um  diese Limits dauerhaft zu verhindern. Derzeit gibt es keinen Hinweis auf Verbesserung in den nächsten zwei Jahren. Und die Probleme sind ja nicht erst seit gestern bekannt.

Ich verstehe ja nicht viel davon, aber wo wäre das Problem das Flatdatabase design beizubehalten und einfach eine zweite Tabelle aufzumachen, die halt per SAVEDID oder so miteinander verbunden wird? Bin kein Experte, kann eventuelle Probleme schlecht einschätzen, aber ich vermute mal, das würde schon mal 99% der Probleme "zuviele Fragen" lösen. Dann kann man sich später immer noch Gedanken über ein grundsätzlich anderes Datenbanksystem gedanken machen (was dann manchmal halt lange Exportzeiten zur Folge hat, wie ich es von anderen Systemen kenne).

Hallo,
als hätte Willi meine Gedanken gelsen.
Gerade in der letzten Nacht habe ich mich entschlossen, hierzu einmal die Datenbankstruktur eines anderen Tools darzustellen.
Ich glaube, dass hier für jede Mehrfachnennung eine eigene Subtabelle angelegt wird, die nur vier Spalten hat, nämlich
StudienID, ID (bei uns {SAVEDID}), lfd, gewähltes Item

Egal, wieviele Teilfragen es gibt, es bleibt bei diesen 4 Spalten - die Tabelle wird nur länger, während in LS ja pro Teilfrage eine Spalte verbraucht wird.

Wie gesagt, ich werde einmal genauer gucken, wobei ich mich gerade etwas aus dem Fenster gelehnt habe.
Ich weiß nämlich gar nicht, ob ich noch einen entsprechenden Export habe.
Schauen wir einmal 

Bis dann
Joffm

P.S.
Es gab ja auch schon einmal eine längere Diskussion darüber, die dann aber wohl irgendwie endete.
Was die Besserung angeht: Ein winzig kleines Stück haben wir ja in Version 4.x.
Die Internationalisierung ist in eigene Tabellen ausgelagert.
Damit haben die Tabellen _questions, _answers, usw. nicht mehr für jede Sprache einen neuen Datensatz,sondern nun sind sämtliche sprachabhängigen Texte in zusätzliche Tabellen _I10ns ausgelagert.
 

hi Willi, Jelo, Holch, Joffm,

vielen Dank für den Thread - das hoert sich sehr interessant an;

hab den Thread kurz gelesen; forums.limesurvey.org/forum/german-forum...zu-viele-teil-fragen

nooch sind meine Fragebögen nicht so aufwändig - aber ich find das Thema interessant.

,,,,glaube, dass hier für jede Mehrfachnennung eine eigene Subtabelle angelegt wird, die nur vier Spalten hat, nämlich
StudienID, ID (bei uns {SAVEDID}), lfd, gewähltes Item
Egal, wieviele Teilfragen es gibt, es bleibt bei diesen 4 Spalten - die Tabelle wird nur länger, während in LS ja pro Teilfrage eine Spalte verbraucht wird.
Wie gesagt, ich werde einmal genauer gucken, wobei ich mich gerade etwas aus dem Fenster gelehnt habe.
Ich weiß nämlich gar nicht, ob ich noch einen entsprechenden Export habe.
Schauen wir einmal

bin sehr gespannt.

VG Tanger

holch wrote: Ich verstehe ja nicht viel davon, aber wo wäre das Problem das Flatdatabase design beizubehalten und einfach eine zweite Tabelle aufzumachen, die halt per SAVEDID oder so miteinander verbunden wird? Bin kein Experte, kann eventuelle Probleme schlecht einschätzen, aber ich vermute mal, das würde schon mal 99% der Probleme "zuviele Fragen" lösen. Dann kann man sich später immer noch Gedanken über ein grundsätzlich anderes Datenbanksystem gedanken machen (was dann manchmal halt lange Exportzeiten zur Folge hat, wie ich es von anderen Systemen kenne).

Das Verbinden (über die End-URL) ist die einzige Möglichkeit, das Problem derzeit zu umgehen. Wenn man aber wirklich lange Umfragen hat, dann endet man mit 5 oder mehr Teil-Umfragen, die alle mit (gleichen) Umfrageteilnehmern und Tokens gefüllt werden wollen. Das erhöht den administrativen Aufwand.

dann endet man mit 5 oder mehr Teil-Umfragen

OK, ich kann ja verstehen, dass man bei einer Datebanktabelle relativ schnell an die Grenzen kommt. Aber 5 oder mehr??? Das heisst du has 5000+ Fragen/Teilfragen? Da muss man sich eher überlegen wer so etwas ausfüllen soll. Klar, wenn eine Frage 5000 Teilfragen hat kommt man da auch hin, aber wie realistisch ist das?

Das Problem bei der Verkettung durch die EndURL ist ja ein anders: Man kann nicht mehr per Expression Manager auf die Tokentabelle oder auf Fragen aus vorhergehenden Umfragen zugreifen und Relevanzgleichungen ausnutzen.

Meine Frage ging ja in eine andere Richtung: Wenn man die Grenze überschreitet dann legt Limesurvey einfach eine weitere Tabelle an. Die kann man ja innerhalb Limesurveys verknüpfen und dann könnte man auch entsprechend Expression manager wieder nutzen.

Wir haben doch als Daumenregel 1570 Spalten by MyISAM.
Und das ist ganz schön viel. 
Es sei denn, man benutzt viele, viele Matrix(Zahlen)-Fragen. Nehmen wir einmal - sehr hochgegriffen - 12 Antwortoptionen in der x-Achse.
Dann hätte man 125 Teilfragen in der y-Achse.
Klar, dass dies nicht realistisch ist für einen Fragebogen.
Jetzt kann jemand sagen "Ja, aber ich habe 10 Gruppen und stelle jeder Gruppe nur 10 Fragen". Dann erreiche ich dieses Limit.
Richtig, nur dann sage ich "Die Programmierung ist schlecht überlegt". In einem solchen Fall kann man dann "micro-tayloring" einsetzen; also genau diese 10 Fragen anlegen und die Texte per Expression Manager einblenden je nach Gruppe,

Oder bei @holchs 5000 Teilfragen. Irgendwo gibt es hier ein Beispiel, indem wir alle PLZ Deutschlands mittels "autocomplete" verwurstet haben. Das sind mehr als 9000.
Das geht, wenn man dann einen adäquaten Fragetyp nimmt. 

Ich hatte ja schon angekündigt, einmal zu untersuchen, wie ein anderes Tool dies löst. 
Dazu ist zu sagen dass dieses Tool für ein Marktforschungsinstitut in der billigsten Version (2 admins, ich weiß nicht wieviele Interviews pro Jahr) um die 5000 Euro kostet.
Kommt auch noch.
Übrigens habe ich bei dieser Untersuchung einen Fragebogen erwischt, der wirklich katastrophal programmiert war. Das beschreibe ich dann später einmal.

Und jetzt kommt noch der Spruch zum Abend:
Wie wäre es, einfach einmal Maria Widenius anzuschreiben, dass sie ihren Vater so lange nervt, bis er ein paar Spalten mehr einbaut.

Für diejenigen, die es nicht wissen:
Micael "Monty" Widenius ist der Hauptautor von MySQL und jetzt MariaDB.
Und MySQL kommt nicht vom schönen englischen Wort "my".
Monty hat seine Werke nach seinen beiden Töchtern benannt: My und Maria.

Joffm
 

Für diejenigen, die es nicht wissen:
Micael "Monty" Widenius ist der Hauptautor von MySQL und jetzt MariaDB.
Und MySQL kommt nicht vom schönen englischen Wort "my".
Monty hat seine Werke nach seinen beiden Töchtern benannt: My und Maria.

Das wusste ich wirklich nicht...

holch wrote:

dann endet man mit 5 oder mehr Teil-Umfragen

OK, ich kann ja verstehen, dass man bei einer Datebanktabelle relativ schnell an die Grenzen kommt. Aber 5 oder mehr??? Das heisst du has 5000+ Fragen/Teilfragen? Da muss man sich eher überlegen wer so etwas ausfüllen soll. Klar, wenn eine Frage 5000 Teilfragen hat kommt man da auch hin, aber wie realistisch ist das?
[...]

Na, ich halte das für realistisch:
Man nehme eine Frage, die wie die anderen auch, hübsch daher kommen soll, eine Listbox mit N Antwortmöglichkeiten und Kommentarfeld, wobei je nach Auswahl der Antwort geht eine zusätzliche Box auf: Mal ein Datumsfeld, mal ein weiteres Kommentarfeld, dann eine Eingabemöglichkeit für Ganzzahlen, dann eines mit einer besonderen Plausibilitätsprüfung usw. - denken wir uns schlicht, es könnten N möglicherweise eingeblendete Zusatzfragen sein. Dann belegt eine ganze Frage schwupps N+1 Spalten. Bei maximal 980 experimentell als Maximum an Export-Antworten ermittelten Spalten wäre ich bei maximal 980/(N+1) möglichen Fragen. Nehmen wir mal N=9, dann enden wir bei 98 Fragen - das ist ja nicht viel!

Joffm wrote: Wir haben doch als Daumenregel 1570 Spalten by MyISAM.
[...]
Und jetzt kommt noch der Spruch zum Abend:
Wie wäre es, einfach einmal Maria Widenius anzuschreiben, dass sie ihren Vater so lange nervt, bis er ein paar Spalten mehr einbaut.
[...]
Joffm
 

Das will ja nicht wirklich jemand, denn der Datensatz will auf einmal eingelesen und verarbeitet werden - da geht dann die Responsiveness flöten.
Aus meiner Sicht müsste die Struktur der Datenbank an dieser Stelle umgestellt werden - WENN man überhaupt tätig werden wollte.

98 Frage nicht viel? OK, wir haben da offensichtlich andere Definitionen von "nicht viel" wenn es um Umfragen geht.

also meine zielgruppen sind im Allgemeinen nicht bereit 98 Fragen auszufüllen. Aber insgesagt stimme ich zu.

Ich kam vor ein paar Jahren mal mit einer Befragung mit um die 5 "Fragen" an die Grenzen Limesurveys.