 |
Die letzten 5 Postings in diesem Thema » Alle anzeigen
| von raiserle |
Ok - gut, so kann man das stehen lassen.
Mir missfiel eben nur der Grundsatzgedanke (Generell) in deinem Post.
Zugegeben: Man muss in den einzelnen Fällen "Benchmarks" machen.
Ich kann nur soviel dazu sagen, dass ich SQL-Statemenst schreibe, die auch mal mehr als 2 A4-seiten füllen. Um das selbige Ergebnis in PHP zu konstuieren, müssten mehere Schleifchen und ne Menge
IF-Else herhalten. Da habe ich schon mal eher das Gefühl, dass ich es lieber das (R)DBMS :D machen lasse.
lG raiserle |
| von chip |
OK, zugegeben ist MySQL sicher nicht optimal, hat aber genauso seine Schwächen wie andere Systeme (PostgreSQL, etc.)
Optimierer sind natürlich immer im Spiel, können aber nur innerhalb ihrer Grenzen die Query optimieren (Selektionen & Projektionen vorziehen, usw.). Ob ein komplettes kartesisches Produkt gebildet werden muss, hängt von der Abfrage ab (und das kommt durchaus häufiger vor). Unter kartesischem Produkt verstehe ich hier auch im weitesten Sinne, wenn alle Tupel ausgelesen werden müssen (also von vorherigen Projektionen mal abgesehen). Und die sind sehr wohl teuer.
Der DB-Server mag schneller sein, als die Interpretersprache, aber die Anbindung an eben diesen Server ist der Knackpunkt (egal welches DBMS). Es dauert eben, bis der Interpretersprache alle Daten vom DBMS zur Verfügung stehen. Genau hier sollte man sich gut überlegen, wem man die "Arbeit" überlässt.
Was die Performance der Berechnungen angeht kann PHP schneller sein, weil die Funktionen auf C-Bibliotheken aufsetzen, die einen Geschwindigkeitsvorteil bieten (aber in engen Grenzen, da gebe ich dir vollkommen Recht). Wenn man schon eine Query ausführt, kann man meistens die Berechnungen auch vom DBMS erledigen lassen, da hast Du recht.
Ich stehe zu dem Grundsatz, die DB-Abfragen auf das nötigste zu begrenzen (da gibst du mir sicher Recht) und lieber etwas mehr Arbeit an PHP abzugeben. Natürlich nicht immer, weil man von Fall zu Fall abwägen muss. Es hängt auch stark von der Komplexität der Queries und "Aufgaben" ab. |
| von raiserle |
Aha:
Chip, sorry. Nein dem ist nicht so.
A) Gibt es Optimierer, die bei Subselects (Joins) ziehen.
B) Wird niemals ein komplettes "Kartesiche Produkt" gebildet
C) Ist der DB-srv sehrwohl schneller als die "Interpretersprache" PHP.
und
D) auch mal über den Tellerrand gucken. Es gibt ja nicht nur MySQL - was mit Berechnungen nicht sehr optimal umgeht - zugegeben.
Es geht hier um deinen Grundsatz: Lieber das "Backend" die Arbeit machen lassen - als das "RDBMS".
Und dem kann ich als Grundsatz NICHT zustimmen.
Gruß raiserle |
| von chip |
raiserle schrieb am 05.04.2010 14:35
Kann man so absolut nicht stehen lassen. Grundsätzlich gilt:
Was schon mit dem DB-srv abgearbeitet werden kann (e.g. Berechnungen, Stringfunctionen, etc.), sollte auch mit diesem erledigt werden.
Mit der Anfrageanzahl gehe ich mit - so gering wie möglich. (Aber wozu gibts Joins, Subselects...) |
Nein, kann ICH leider nicht so stehen lassen  .
Joins und Subselects sind teuer (kosten viel Zeit, Rechenleistung und Speicher, weil meist alle Tupel ausgelesen werden müssen, dann Kreuzprodukt und Selektion). Besser ist es in diesem Fall mehrere kleine Anfragen zu haben.
Berechnungen, etc. würde ich nur bedingt dem DB-System überlassen, weil auch diese meist langsamer sind, als die nativen PHP-Funktionen.
Es ist also alles immer eine Einzelfallabwägung. |
| von raiserle |
chip schrieb am 13.03.2010 11:55
Generell ist es besser so wenig wie möglich DB-Abfragen zu haben und PHP mehr Arbeit machen zu lassen. |
Kann man so absolut nicht stehen lassen. Grundsätzlich gilt:
Was schon mit dem DB-srv abgearbeitet werden kann (e.g. Berechnungen, Stringfunctionen, etc.), sollte auch mit diesem erledigt werden.
Mit der Anfrageanzahl gehe ich mit - so gering wie möglich. (Aber wozu gibts Joins, Subselects...) |
|
|
|
