Nirgendwo lernt man mehr über Datenbankdesign, Entwicklung und Performance wie bei der Arbeit mit großen Datensätzen. Nichts bietet höhere Lernkurven und größeres Frustrationspotential :-) Ein großes Thema ist immer wieder die Sortierung dieser Daten. Ich möchte hier auf einen Sonderfall eingehen, die zufällige Sortierung. Gerade wenn mehrere Skripte oder Prozesse gleichzeitig auf einer Datenbasis arbeiten, möchte man oft, dass diese zufällig Daten auslesen und z.B. aktualisieren.

Normalerweise bietet MySQL die Funktion

um die ausgelesene Ergebnismenge per Zufall zu sortieren. Gerne arbeitet man hier auch noch mit LIMIT. MySQL erstellt hierfür intern eine temporäre Tabelle und einen Indexes mit Zufallszahlen, um dann danach zu sortieren. Auch bei angegebenem LIMIT wendet MySQL dies auf die kompletten Daten an, der Rest wird dann einfach verworfen. Das macht generell ja auch Sinn, da man die Zufallswerte aus der gesamten Tabelle erhalten möchte. Das Problem: Je nach Prozessorpower ab einer fünfstelligen Datenmenge LAAAAANGSAM........

Eine Lösung, mit der ich noch bis vor kurzem gearbeitet hatte, war die per OFFSET in Kombination mit LIMIT, die ich hier gefunden habe:

Ich arbeite mit AdoDB, also denkt Euch Euren Datenbanklayer, wichtig sind hier der SQL und PHP-Code. Also, was habe ich gemacht:

1. Gezählt, wie viele Daten insgesamt in der DB sind
2. Zufallswert bestimmt, der zwischen 1 und der Gesamtmenge der Daten liegt
3. Gewünschte Anzahl Daten ausgelesen, mit der Zufallszahl als "Startwert" (Offset). Mehr zu LIMIT und OFFSET hier.

Vor kurzem ist auch dieses Vorgehen an seine Grenzen gestoßen. Und zwar, weil ich von einem anderen Server auf die Datenbank zugegriffen habe. Die Abfrage selbst war zwar nach wie vor performant, es wurden aber irgendwie riesige Datenmengen übertragen. Nach einiger Recherche fand ich heraus, dass bei obrigem Vorgehen trotzdem ALLE DATEN bis zum Offset ausgelesen werden und diese dann nachträglich abgeschnitten, siehe auch hier.

Aber die Lösung lag sehr nahe, gefunden bei akinas.com, wenn auch etwas umständlich. Hier meine Lösung, die (bis dato, man weiß ja nie ;-)) super funtkioniert:

Bei der WHERE-Bedingung scheinen die Daten echt gefiltert zu werden. Thats's it!

Bei der Arbeit mit Typo3 kommt häufig auch der Crawler zum Einsatz. Vor allem beim Caching großer Webpräsenzen ist er eine große Hilfe. Denn es ist gerade hinsichtlich des Zusammenhangs Ladezeit - Suchmaschinenranking wichtig, dass alle Webseiten schnell abgerufen werden können.

Der Crawler zieht seine Konfiguration aus der TSConfig der Rootseite im Backend. Eine ausführliche Anleitung findet sich in der

• Dokumentation Typo3 Crawler und im
• Typo3 Crawler Wiki

Für den Crawler gibt der Pfad "tx_crawler.crawlerCfg.paramSets"die Parameter zur Konfiguration an. Eine normale Konfiguration sieht folgendermaßen aus:

Im Objekt "language", wessen Name i.Ü. frei wählbar ist, werden als Erstes an den Crawler Parameter übergeben. Den String in den eckigen Klammern wertet der Crawler so aus, dass im ersten Teil eine Tabelle angegeben werden kann, aus der dynamisch abgefragt wird und im Zweiten die jeweilige Spalte. Des Weiteren kann man über den Konfigurations-Parameter "procInstrFilter" zusätzliche Extensions in den Crawlprozess einbinden. Die baseUrl gibt dem Crawler die zu crawlende Domain an.

Da Inhalts-Erweiterungen wie z.B. tt_news eine andere Art der Inhaltsverwaltung haben, muss der Crawler daran angepasst werden. Bei tt_news sind die Inhaltselemente nicht kaskardierend an eine Rootseite eingehängt, sondern liegen in einem Ordner. Die Auswahl des jeweiligen Datensatzes erfolgt über einen Parameter in der URL. Diese Funktion muss in der Crawler-TSConfig nachgebildet sein:

Wie man sieht, ist die Übergabe der Paramter ähnlich wie im ersten Beispiel über die Angabe der Datentabelle (tt_news), wobei hier die ID des Sysordners angegeben ist, in dem die News liegen. Damit der Crawler diese Konfiguration nur für die einzelnen Newsbeiträge ausführt, wird er über "pidsOnly" auf die UID der "Singelview"-Seite eingesperrt.

So weit, so gut. Steht ja auch alles in der Doku.

Bei tt_news gibt es darüber hinaus eine Pagination. Diese listet in der LIST - Ansicht alle weiteren Beiträge auf Unterseiten auf, sobald die maximale Anzahl Seiten pro Listenansicht erreicht ist. Diese "Unterseiten" werden über den URL-Parameter "pointer" generiert. Ohne eine entsprechende Konfiguration werden diese Übersichtsseiten aber nicht vom Crawler erfasst. Dies mag für das Caching eventuell unerheblich sein. Wenn man mithilfe des Crawlers und der Extension staticpub jedoch HTML-Seiten generieren möchte, fehlen die Dateien im Ordner der statischen Seiten.

Als Lösung müsste man demnach eine weitere Crawler-Konfiguration anlegen und dem Parameter "pointer" die jeweilige Pagination-ID (Also 1-n) mitgeben. Generell ist die Übergabe dynamischer Parameter über das TSConfig abhängig von der jeweiligen Extension. Wie oben bereits gesehen, kann über die TSConfig dem Crawler eine Tabellenabfrage mitgegeben werden. Und witzigerweise scheinen die Macher des Crawlers auch an den Sonderfall mit der Pagination gedacht zu haben. Bei einem Blick in die Skript-Dateien fällt einem die Funktion "expandParamters" ins Auge, welche die übergebenen Informationen auswertet. Und an diese Funktion kann man auch einen "integer-range" übergeben, im Format [int] - [int]. Im TSConfig würde das folgendermaßen aussehen:

Wobei der Crawler hier die Werte von eins bis 50 durchgeht, unabhängig davon, ob noch Inhalte für die Pagination vorhanden sind. Aber es tut, was es soll, und das ist das Wichtigste :-)

Durch Zufall bin ich durch die google Webmastertools darauf aufmerksam geworden, dass ich eine Fehlerseite auf allen meinen Typo3-Projekten habe, wo eigentlich keine sein sollte. Wenn ich die Indexseite einer Typo3-Installation mit laufendem Realurl folgendemaßen Aufrufe, bekomme ich einen 404 Fehler:

http://www.domain.de/index.html

bzw. das für Realurl typische

"Segment "index" was not a keyword for a postVarSet as expected!"

Normalerweise bedeutet dieser Aufruf ja "gib mir die Startseite zurück". Da eber einige eingehende Links auf die index.html verweisen, wollte ich diese per 301-Weiterleitung auf die Startseite "/" umziehen.

Dafür wollte ich per htaccess eine Weiteleitung setzen. Das geht bekanntermaßen per Redirect:

Geht aber nicht, und der Fehler ist sogar nachvollziehbar. Da normalerweise ein Aufruf des Domain-Wurzelverzeichnisses den Aufruf der Index-Datei zur Folge hat, ist obige Anweisung eine Endlosschleife. Sozusagen "Leite von der Indexseite auf das Wurzelverzeichnis auf die Indexseite".

Die Lösung bringt Typo3 mit. Wobei ich mich ehrlich gesagt darüber wundere, dass sie funktioniert... Bei installiertem Realurl können die sprechenden URLs über das "Info" Modul im linken Backend-Menü administriert werden (Info->"Speaking URL Management" im Dropdown). Im daraufhin erscheinenden Dropdown "Redirects" auswählen. Dort auf "New Entry". Url ist demnach die "index.html", die weitergeleitet werden soll auf "Destination"->"http://www.domain.de/". Natürlich per 301, man will ja nichts verschenken :-). Dann wird sauber weitergeleitet.

Was ich nicht verstehe - vielleicht hilft hier jemand weiter, der mehr Ahnung hat: Wo ist der Unterschied, ob ich die Weiterleitung per htaccess setze oder per Skript im header? Sollte die Endlosschleife nicht in beiden Fällen auftreten? Naja, ich bin froh, das es jetzt erstmal läuft!

Nachdem ich das Problem der großen Seitenbäume durch einen Workaround lösen konnte, stand ich jetzt bei dem gleichen Projekt vor dem Problem, dass die Seitentitel zu lang waren und im Backend abgeschnitten wurden. Jeder Titel wird standardmäßig nach 30 Zeichen gekürzt. Wenn innerhalb dieser 30 Zeichen kein individuelles Merkmal der Seite erscheint, hat man keine Möglichkeit, die Seiten voneinander zu unterscheiden. Die Lösung is, dass man im Typo3 für die Backend-Benutzer den "Standard-Abschnitt" und die Anzeige vergrößert:

TSconfig des BE-Users oder besser der BE-Benutzergruppe:

Gefunden habe ich die Lösung bei Sebastian. Thx!