nicht angemeldet
Moin!
ich mache eine Datenbankabfrage und lasse mir das Ergebnis dann anzeigen. Nun möchte ich das Ergebis nachträglich nach verschiedenen Kriterien sortieren lassen. Da ich keine Lust habe die gesamt Abfrage nochmal durchzuführen hab ich mir gedacht, dass ich ja den Array mit den Resultaten der Abfrage mit serialize verpacken kann, dann noch ein base64_encode drüber und das ganze dann in einen longblob in die Datenbank.
Hm, nochmal langsam zum Mitlesen: Weil es dir aus irgendwelchen Gründen nicht behagt, einmal
SELECT felder FROM tabelle WHERE xyz
zu machen und erneut
SELECT felder FROM tabelle WHERE xyz ORDER BY sortier
nachzuschieben, hast du dir überlegt, dass es vielleicht sinnvoller ist, stattdessen
INSERT INTO blobtabelle (blobfeld) VALUES ('ganzlangerserializestring')
SELECT blobfeld FROM blobtabelle WHERE blobid
DELETE FROM blobtabelle WHERE blobid
anzuwenden.
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.
Dabei ist mir aufgefallen, dass serialize anscheinend ein Problem mit größeren Datenmengen hat.
Sicher, dass serialize() der Grund ist? Oder könnte auch die Anbindung der Datenbank oder die zur Verfügung gestellte Spalte das Problem sein?
- Sven Rautenberg