Frank Fischer: Anscheinend ein Größenproblem mit serialize

Beitrag lesen

Du ersetzt also einen SQL-Ausdruck durch mindesten drei SQL-Ausdrücke, welche darüber hinaus auch noch schreibend auf die Datenbank (bzw. die Blobtabelle) zugreifen - eine Operation, die immer verhältnismäßig langsam ist, weil man dazu die Tabelle (zumindest aber die betroffenen Spalten) exklusiv für Lesezugriffe sperren muß.

Performancemäßig gewinnst du auch nichts, weil die zu übertragende Datenmenge grob geschätzt gleich ist - wahrscheinlich aber eher mehr, wenn du mit serialize arbeitest.

Das Problem hierbei ist nicht die zu übertragende Datenmenge sondern ehr die Abfrage, die sehr komplex ist und zudem über viele Datensätze geht. Es geht dabei um eine Statistik.
Wenn ich also die Abfrage mache dauert das ganze dann ca. eine Minute bis mein Ergebnis kommt. Wenn ich das nun noch sortieren will dauert es ja wieder eine Minute bis das sortierte Ergebnis kommt.
Ich sortiere ja außerdem nicht mit Hilfe von ORDER bei der Abfrage direkt sondern nachdem ich meine Werte habe innerhalb von verschiedenen Arrays, die aus meiner Abfrage erzeugt werden mit Hilfe von Multisort.

Deswegen wollte ich halt die nochmalige Abfrage vermeiden.

Sicher, dass serialize() der Grund ist? Oder könnte auch die Anbindung der Datenbank oder die zur Verfügung gestellte Spalte das Problem sein?

Es sollte an serialize liegen, da mir halt aufgefallen ist, dass bei kleineren Datenmengen (ca. 1000 Treffer mit jeweils 5 Werten) keine Probleme auftreten, bei größeren (ab 5000 Treffer mit jeweils 5 Werten) er dann aber das serialize nich mehr macht.
Ich hab dann halt ein Array mit 5000 Arrays drin, die jeweils auch wieder 5 Werte haben.

mfg
ff