Thread Insert Into... On Duplicate Key Update... (20 answers)
Opened by rosti at 2012-05-25 20:39

rosti
 2012-05-27 10:00
#158637 #158637
User since
2011-03-19
3492 Artikel
BenutzerIn
[Homepage]
user image
2012-05-26T12:07:11 jan
hast du mal einen benchmark laufen lassen, was schneller ist?

Ich finde deinen Code eher unschön, a) datenbankspezifisch und dann b)
Code: (dl )
$STH->execute($ins, $ins)


das wird doch superhässlich und unübersichtlich, wenn du 10 felder befüllst.


Moin ;)

Dieser Code, den ich weiter oben schrieb, ist KEINE Empfehlung! Er soll lediglich deutlich machen, dass die Verwendung eines eigenen auto_increment-Wertes in dem Moment überflüssig ist, wenn als Schlüssel für die Haupttabelle OHNEHIN ein URSPRÜNGLICHER Wert aus der Datenquelle genommen wird, welcher Eindeutig ist. UND: Über diesen eindeutigen Wert kann im weiteren Verlauf des DB-Designs die referenzielle Integrität in weiteren Relationen hergestellt werden, womit letztendlich die Verwendung eines ZUSÄTZLICHEN Auto_Increment-Felds nicht notwendig ist.

Mein Beispiel zeigt also, dass mit dem Auto_Increment-Wert NUR ein Mapping der Schlüssel erfolgt, was letztendlich nicht unbedingt sein muss.

Es ist also nicht die Frage, welche Art zu fragen (vorher oder hinterher) performanter ist, sondern es ist die Frage, wie sich ein schleichender Performanceverlust überhaupt vermeiden lässt, wenn die Mächtigkeit einer DB-Engine besser genutzt wird, d.h., dass auf eine eigens codierte Abfrage ("Habe ich den Record schon?") einfach nur verzichtet wird.

Meine diesbezüglichen Gedanken kommen nicht von ungefähr, täglich habe ich Unmengen von Daten aufzuarbeiten, die aus einer Oracle-DB kommen und relational nach MySQL abgebildet werden. Hinsichtlich Performance gibt es noch Einiges zu optimieren und einige der Bremsen sind eben genau solche Sachen, wie hier beschrieben.

Viele Grüße,
schönen Sonntag,
Rosti

View full thread Insert Into... On Duplicate Key Update...