- distinct wenn es geht beim select benutzen
kenn ich nicht :(
Beispiel:
spalte1
*******
a
b
c
a
v
query:
select distinct spalte1 from tabletest
result:
a
b
c
v
(doppelte wurden entfernt)
- im join möglichst unterscheiden zw. left,right,inner
- im join kannst du z.b. sagen:
left join table2 on table1.index = table2.indexdas habe ich ja benuzt...
SELECT
villages.x,
villages.y,
tribe.name,
ally.id
FROM villages
LEFT JOIN tribe ON villages.tribe=tribe.id
LEFT JOIN ally ON tribe.ally=ally.id
WHERE
villages.x >= ".$x_start.")
&& (villages.x <= ".$x_end.")
&& (villages.y >= ".$y_start.")
&& (villages.y <= ".$y_end.")
Da ich kein Query-Prog habe, ist es schwierig, das im Kopf zu analysieren. Am Besten ist, du baust deinen Code komplett neu auf. Ein Schritt nach dem Anderen. Dann wirst du sehen, warum es langsamer geworden ist. Hat bei mir auch immer funktioniert.
eine ON-Verknüpfung ist schneller als eine WHERE-Verknüpfung aber wichtiger ist der strukturierte Aufbau der DB und die richtigkeit der Abfrage.
Deswegen such ich nach einer alternative für WHERE
Das hat aber mit der Struktierung der Abfrage zu tun, nur damit du es weisst.
Haste PrimaryKey und das Klump?
hm guck ich nochmal nach. als primary muss man doch immer die ID felder definieren oder? und was ist Klump?
:) Klump ist auf österreichisch Müll. Primary Key ist die Indexspalte. Entweder ein Zähler oder ein "eindeutiger Identifizierer". Möglichst Zahl und richtig definieren (Geschwindigkeit).
Mit deinem Query kann ich dir leider nicht helfen, weil ich es nicht verstanden habe. Gehts einfacher (so einfach wie möglich)?
hm. frag doch bitte nach. ist eigentlich alles drin was wichtig ist. wenn ich was rausnehme ist es nicht meher das was es vorher war...
Danke schonmal, peter
Wie gesagt, bau es neu zusammen is am Besten. Ich hatte Abfragen, die waren najo ziemlich gross da verliert man leicht die Übersicht.