preformance Problem

Ich glaub ich machs echt so, wie meine Idee war. Ich mache einfach aus den 3 Werten einen eindeutigen Wert, den ich dann in eine seperate Spalte schreibe und auf diese Spalte setze ich den Index.
Ist sicher noch sparsamer als hier Spaltenteile zusammenzusetzen.

Muß ich mir nur überlegen, welchen wirklich eindeutigen Wert ich nehme.
Mit time() kann ich hier ja nicht arbeiten, weil mir ja beim Import die voranngegangene Time() nicht bekannt ist.

Gott wenn ich das gewußt hätte

Wegen der eventuellen Duplikate bei md5() bzw. sha1() baruch ich mir glaub ich keine Sorgen zu machen.

Es wird ja kein Zufallswert generiert von mir den ich umwandeln möchte, sondern der Inhalt von 3 Werten zusammengesetzt. Und schon alleine wegen dem user, sowie der internen Nummer kann es hier zB. schon kein Duplikat geben.
Ausserdem müsste ich um das zu erreichen eine Riesensumme von Händlern (usern) haben, was aber auch nicht sein kann, weil dann der User und die Int.Nummer ident sein müssten und der Exporteur genauso.
Also kann ich sicher ohne Gewissensbisse den md5() nehmen, weils ja auch weniger Zeichen sind

Da denk ich doch richtig, oder? Bin schon völlig matsch in der Birne

Original geschrieben von ghostgambler
Also einen Primary-Key auf eine Kombination aus 3 Varchar-Spalten zu legen - davon rate ich jetzt mal spontan ganz dolle ab oO

Da geb ich dir natürlich recht - varchar ist für sowas immer böse. Aber eine Kombination aus enum und int funktioniert hier tadellos.

PrimaryKey nur mit Varchar hab ich hier in ner größeren Tabelle aber auch ohne Probleme laufen.

Original geschrieben von web4free
Da denk ich doch richtig, oder?

Nein.

Original geschrieben von ghostgambler
Nein.

Na das war deutlich genug

Ich habe gerade eine andere Überlegung die mir nochmals etwas Performance schaffen würde.

Leider muß ich ja bei jeden Fahrzeug immer nachfragen in der DB ob das Fahrzueg bereits vorhanden ist um dann zu entscheiden obs ein Update oder ein Insert wird.
Hierzu bräuchte ich ja diesen komischen Index der wiederum beim INSERT und UPDATE einen Bock aufstellt.

ABER:
Ich kenne den Usernamen beim Import (und ich bekomme jetzt Mitte nächster Woche den 2. Server).
Was, wenn ich hergehe und einfach alle Fahrzeuge des jeweiligen Händlers von der Hauptdatenbank in die 2. Datanbank am 2. Server rüberkopiere.
Da hätte ich dann grad mal nur max. 3.500 Fahrzeuge - Im Schnitt sinds eher 200 - 500 Fahrzeuge - und dadurch eine viel kleiner Datenbank zu durchforsten, als wenn ich das auf der Hauptdatenbank mache. Die Daten brauch ich ja nur um zu wissen ob Insert oder Update gemacht werden soll.
Diese Daten würden dann ja wieder gelöscht werden und durch die Daten des nächsten Händlers ersetzt werden und das Spielchen würde sich wiederholen.
So würde ich grad mal nur einen SELECT auf den Usernamen machen in der Hauptdatenbank und das war es dann wärend dem Import auch schon wieder. Der Rest spielt sich dann schon am 2. Server und 2. Datenbank unabhängig von der Hauptdatenbank ab.

Somit bräuchte ich diesen ominösen KEY über 3 Spalten nicht und ich bräuchte nicht einmal diese zusätzliche Spalte von der ich weiter oben gesprochen habe.

Denkt Ihr auch, dass ich damit die Hauptdatenbank wärend dem Import weit weniger belasten würde??
Denn der Select auf den usernamen würde ja nicht soviel verbrauchen.

lg.
Werner