Die Bewertung kommt von mir, weil es mit Spaltenarrays technische Schwierigkeiten gibt, das habe ich an anderer Stelle auch mal erklärt.
Ich find's immer gut, wenn man weiß, was bemängelt wurde ;-)
Das kann ich sehr gut verstehen, und auch den Reflex sich verteidigen zu müssen. Allerdings löst so eine reflexartige Reaktion, nur selten die Bereitschaft deines Gegenüber aus, sich nochmal zu erklären. Mit einer höfliche Bitte um Feedback hast du mehr Aussichten auf Erfolg und das liegt ja in deinem Interesse.
Alle einfachen PHP-eigenen Aggregats- und Sortierfunktionen werden durch "Zeilenarrays" unbenutzbar.
Um auf das Beispiel "Preis + Versandkosten" zurückzukommen, benötigt man dafür am einfachsten eine eigene Spalte. Die kann man aber leicht erzeugen. Und dann kann man die wieder mit asort() sortieren.
Den Gedanken habe ich in der früheren Diskussion ja auch bereits geäußert, aber das finde ich keine gute Lösung. Dieser Ansatz mischt Stammdaten, die für die Geschäftslogik relevant sind, mit administrativen Daten, die für die Ausführung spezifischer Algorithmen gebraucht werden. Das ist unhygiensch. Man muss darauf achten, dass die temporäre Spalte konsistent mit den Stammdaten ist, ändert sich der Preis, muss auch der Gesamtpreis aktualisiert werden. Außerdem muss man darauf achten, dass es keine Namenskollision zwischen den Spalten gibt. Das lässt sich alles irgendwie lösen, aber das bedeutet Aufwand, und ich sehe ehrlich gesagt noch keinen Vorteil.
PHP hat eine eingebaute generische Sortierfunktion, der man belibeige Sortierkriterien übergeben kann. Für eine neue spezifische Sortierfunktion reicht es dann, nur noch das Kriterium zu definieren - das reduziert den Programmieraufwand auf die Essenz des Problems.
Zumal die Datenstruktur hier sowieso schon als Zeilenarray vorlag. Man müsste sie also erstmal in die Form eines Spaltenarrays bringen. Genauso, werden Datenbank-Ergebnismengen zeilenweise gelesen, solche Daten müsste man auch erst transponieren. Und man muss bei Spaltenarrays viele typische Container-Operationen neu implementieren, für die primitven CRUD-Operatinen, hast du das freundlicherweise schon gemacht und die Leistung will auch auch gar nicht schmälern, dennoch muss das für komplexere Operationen, wie array_map
, array_reduce
oder array_filter
noch gemacht werden, wenn sie denn gebraucht werden. Dann ensteht auch wieder Mehraufwand.
Für kleine Beispiele ist das folgende vielleicht weniger relevant, aber man sollte zumindest im Hinterkopf haben, dass Operationen auf Spaltenarrays – jedenfalls die aus dem Wiki-Artikel – schlechteres komplexsitätstheoretisches Laufzeitverhalten haben. Wenn n
die Anzahl der Datensätze ist, und m
die Anzahl der Felder in einem Datensatz, dann hat ein direkter Lesezugriff die Komplexitätsklasse O(1)
in einem Zeilenarray, in einem Spaltenarray aber O(m)
. Das Transponieren, das vorher nötig ist, hat sogar O(n*m)
, das ist der Faktor der ensteht, wenn man eine MySQL-Ergebnismenge in ein Spaltenarray umwandeln muss.
Außerdem, funktioneren Zeilen-Arrays auch mit klassischen objekt-orientierten Entwürfen. Ich kann ein Array von Objekten mit genau den selben Operationen traversieren und manipulieren, wie ein Array von Arrays oder ein Array von Integern. Man kann also mehr Funktionen wieder verwenden.