[php] schnellster Datenbank-Layer

[Yannik Hampe]

Sebastian Mendel wrote:
> Yannik Hampe schrieb:
>> Sebastian Mendel wrote:
>>> Yannik Hampe schrieb:
>>>
>>>> Ich verwende in allem, was ich jetzt noch mache mit PDO...
>>>> PDO ist wirklich toll :-). Vorallem die prepared Statements finde ich
>>>> Klasse. Vergiss all' das escapen von Parametern und vergiss das ständige
>>>> neuparsen eines Querys.
>>>> Besonders wenn du in Schleifen gleiche Querys (mit verschiedenen
>>>> Paramatern) immer wieder aufrufst haut das Performancemässig richtig
>>>> rein :-).
>>> ich will ja keinesfalls behaupten das es nie nötig ist mehrere 'gleiche'
>>> Abfragen auszuführen ... aber ich habe es zumindest noch nicht gesehen ...
>>> denn meißtens lasen diese sich zu einer zusammenfassen - und das sparrt
>>> wesentlich mehr Zeit als alle einzeln zu senden. Oder?
>> Wenn du einen Datensatz in eine DB einfügst und die inserted_id
>> brauchst, dann wirst du schonmal Schwierigkeiten Insert-Querys
>> zusammenzufassen.
> 
> stimmt, wenn man parent und child in einer Tabelle hat, ... bin ich aber
> bisher auch noch nicht drüber gestolpert, weil wenn dann wären das alles
> einzelne Objekte und diese Objekte müssten sich dann das Prepared statement
> teilen ... da ist mir der Programmiertechnische Aufwand zu hoch (relativ
> gesehen) für den seltenen Fall wo so viele neue 'childs' eingefügt werden.
> Zumal das erzeugte Query auch immer nur die Felder enthält die geändert
> wurden bzw. vom DEFAULT abweichen - somit wären die Querys auch wieder nciht
> imemr gleich.

Ich bin ein grßer fan von OOP in Java und Delphi. In php eigentlich
auch, aber weit weniger stark. Ich würde es wirklich vermeiden für jeden
Knoten ein eigens Objekt zu nehmen ;-). Besonders, wo man es mit einer
korrekt organisierten Rekursion mit print sowieso alles direkt raushauen
kann und es nicht nötig ist irgendwas zu speichern...

Aber egal. Wo sagen wir du nimmst ein Objekt für jheden Datensatz:
Wo siehst du das Programmiertechnischen Aufwand?? Du schreibst einmal
"static" vor das prepared Statements und fertig.
> 
>> Und auch bei Selects kann es durchaus sein, dass du beim nächsten Query
>> Daten abhängig vom ersten Abfragen willst (bei einem rekursiven Menü zum
>> Beispiel).
> 
> na sowas mach ich mit JOINS oder speziellen Tabellen die für Nested Sets
> sind ...

Bei Menüs sind Nested Sets nicht wirklich Mittel der Wahl. Du brauchst
ja normalerweise nur einen Ast und kennst ein Blatt von dem du den Ast
willst. Dich da hochzuhangeln geht mit einer rekursiven Struktur viel
schneller.
Wie du das alles mit Joins bewerkstelligen willst, will ich sehen.

Und es bleibt das Argument, dass du nichts mehr escapen musst :-).

Yannik