A mai nap kulcsa az SQL kifejezesek atirasaban ez volt:
LEFT JOIN valami ON valami.valami_mas_id = valami_mas.valami_mas_id AND emez.emez_id = valami.emez_id
+LEFT JOIN valami as valami_to_ignore ON valami_to_ignore.valami_mas_id = valami_mas.valami_mas_id AND emez.emez_id = valami_to_ignore.emez_id AND valami_to_ignore.valami_id > valami.valami_id
... /* WHERE */
+ AND valami_to_ignore.valami_id IS NULL
/* GROUP BY itt volt mason, az nem volt megoldas, eleve szamlalashoz kellett, GROUP BY amugy is ketszer szamol */
Aztan ez ma igy tobb helyre bekerult, nehol meg igy is rossz a lekerdezett adat, mert a kesobbi a jo a duplikaciobol, de korabban ennel is kisebb esellyel volt ott is jo.
Na igenam, csak aztan jott a legnagyobb problema:
A `valami` tabla emez_id fieldjen nincs index (igen, foreign key constraint sincs, raadasul torolve van idonkent a "parent" tablabol). Ebbol kovetkezoen a vegeredmeny lassu, mint a szar.
Konyorgom nektek, ha SQL-eztek:
-hasznaljatok tarolt eljarasokat vagy CREATE FUNCTION-t olyan dolgokhoz, ami tobb tablaba ir iranyitottan
-hasznaljatok tranzakciokat
-hasznaljatok unique-ot azon, amibol nem kene hogy tobb legyen (akar ertekparon is lehet, ha ez nektek ujdonsag)
-ez utobbi esetere hasznaljatok az "ON DUPLICATE ENTRY" kifejezest INSERT-kor
-ha az ORM motorotok hulye ehhez, vagy nem tudjatok a csapatnak elmagyarazni, hogy egy ORM-en belul hogy lehet ezekre figyelni, inkabb hagyjatok a picsaba azt a kurva ORM-et, es irjatok SQL-t. Higgyetek el, sokkal konnyebb volt nekem a sima SQL query-kbol atirni az elbaszottakat, az in-house ORM-eseket meg most is vadaszom, hogy kene megjavitani, halistennek abbol volt kevesebb.
- carlcolt blogja
- A hozzászóláshoz be kell jelentkezni
- 898 megtekintés