ist es denn vorgesehen das solche bugs behoben werden?
Nein, nie. Ist generell nicht vorgesehen, dass Bugs behoben werden. Eine etwaige Lösung ist ggf. nur Ergebnis einer zufälligen Mutierung des Codes...
Scherz beiseite: Sagen wir mal so, so wie es jetzt ist, ist es bei 100 Einträgen und mit (als Beispiel) 5 zusätzlichen Feldern für Informationen erträglich, danach wird es anstrengend.
Hintergrund:
Der vorhandene Ansatz ist eine geniale Idee und ermöglicht es sogar, Zusatzinformationen aus Text- und XML-Dateien zur verfügung zu stellen und (für diesen Bereich) ohne mySQL auszukommen.
Leider fummelt sich der Webserver dabei zu Tode, da zunächst alle Daten in ein Array geladen werden, dann (bei Verwendung der Suche) darin gesucht und anschließend das Array sortiert wird. Danach zählt er die Array-Position hoch, um zu den Einträgen zu kommen, die auf der aktuellen Seite angezeigt werden sollen...
Das Laden der Daten in das Array funktioniert unter Verwendung der Plugins so:
1. SQL-Abfrage gegen die DB liefert alle Frontend-User-Accounts
2. Pro Account werden nun auf Dateiebene die Plugin-Verzeichnisse auf vorhandene .php-Dateien gescannt und diese ggf. included
3. Enthält die Plugin-Datei eine entsprechende Prozedur, die Daten zum Array beisteuern dürfte, wird diese ausgeführt
4. Sind die Daten, die die Prozedur beisteuert, in der DB gespeichert, wird ein SQL-Statement gegen die DB gesendet
Beispiel:
2000 Frontend-User-Accounts
10 zusätzliche Felder
25 Zeilen/Seite
Suche nach "e"
Zeige Seite 12 an
Pro Account scan durch 10 Verzeichnisse, nacheinander include von 10 Dateien, ausführen von 10 Prozeduren, damit 10 Abfragen gegen die DB. Suchen im Array, Sortieren des Ergebnis, durch das Array zählen, bis wir bei Seite 12 sind, 25 Zeilen ausgeben.
D.h. für die Anzeige der 25 Einträge auf Seite 12, die ein "e" enthalten, werden 20000 + 1 Abfragen gegen die Datenbank gesandt, ein Array mit 10 + 4 Spalten und 2000 Zeilen (28000 Zellen) gefüllt, zeilenweise durchsucht, die verbleibenden Zeilen sortiert und bis zum 276. Datensatz (11 * 25 + 1) hochgezählt. Und dann werden 25 Zeilen mit den Daten aus 4 Spalten ausgegeben...
Wenn man auf das Feature der direkten Verwendung von Text- und XML-Datenquellen verzichten könnte (d.h. nur Datenbank-Zugriffe, z.B. in dem man die Text- bzw. XML-Daten einfach in einem separaten Schritt in der Datenbank einträgt), dürfte man einen Weg finden, um pro Account nur eine Abfrage gegen die DB zu senden (das wären dann nur 2000+1). Wenn man auf das Feature verzichten könnte, dass die Zusatz-Daten in einer separaten DB liegen, könnte man einen Weg finden, nur eine Abfrage gegen die DB zu senden.
Wenn man auf das Feature verzichten kann, mySQL nicht verwenden zu müssen, kann man mit LIMIT direkt die Daten für eine bestimmte Seite ermitteln. Dies gilt natürlich nur, wenn ich nicht in den Zusatzdaten suchen möchte oder die Zusatzdaten in der gleichen DB liegen.
Die Frage ist also, auf welche Möglichkeiten die Allgemeinheit eher verzichten kann - hier muss man IMHO insbesondere die Unternehmens-Brille aufsetzen, da diese u.U. Oracle-Server oder SQLServer statt mySQL einsetzen möchten, dort Zusatzdaten aus anderen Systemen geliefert werden und diese anderen Systemen "nur" das "non-plus-ultra" des flexiblen Datenaustauschs, nämlich XML zur Verfügung stellen (es seine auch Webdienste genannt).
Persönlich werde ich in der nächsten Newsletter-Überarbeitung (da besteht das Problem aufgrund der Code-Verwandschaft ebenfalls) wieder zurück in die mySQL-DB gehen. Punkt.
Gruß
HerrB