[php] schnellster Datenbank-Layer

[Sebastian Mendel]

Yannik Hampe schrieb:
> 
> 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...

das ist eine generische Klasse die für jede Zeile beliebiger Tabellen ein
Objekt bildet - ein eigene Klasse würde ich da auch nicht programmieren ...


> 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.

naja eben nicht, weil das Query eben nicht immer gleich ist, ich müsste also
für jede Anzahl an Parametern ein prepared statement vorhalten und
vergleichen welches passt ... weil es eben eine genersiche Klasse müsste ich
erst eine Spezielle ableiten - will ich aber nicht, bin zu faul

kurz: um prepared statements zu verwenden müsste ich auf mich wesentlich
bessere Vorteile verzichten ... außer ich schreib eben eine spezielle Klasse

ich würde mir die für mich geringen Vorteile von prepared statements teuer
erkaufen ...


>>> 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.

den gesamten Ast (root -> blatt) anhand eines Blattes bekommen?

das kann nicht wirklich ein Problem bei nested sets sein ...

googlum ... z. B. da:

"Durch eine entsprechende Eingrenzung kann man sich auch alle Vorgänger zu
genau einem Knoten ausgeben lassen:"

http://ffm.junetz.de/members/reeg/DSP/node11.html#SECTION04344000000000000000


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

'ich' muss nichts escapen, das passiert alles im Objekt ... die Klasse kennt
die Tabelle und Felder und entscheidet wie die Daten validiert werden müssen.


-- 
Sebastian Mendel

www.sebastianmendel.de