Nos, a termékekből (L) 1600 db van, ehhez van FK (LD néven), aminek a számozása most közel 59000-nél jár, és ezekhez az LD-khez vannak sorok (LDL, szintén FK, de LD-hez), amelyeknek a számozása pont most lépte át a 150.000-et.
Ez mostanában nőtt meg, míg februárban 20MB volt a tömörített dump mérete, ez most már 150MB, ami még mindig nem egy hatalmas mennyiség, de a fájlrendszeren - furcsa mód - az LD mérete 700 MB, az LDL mérete pedig mindössze 16MB .
Mennyire sok ez a szám? Egy L-hez 2 LD-nek kellene tartoznia, és azokhoz max. 10 LDL-nek darabonként, csak hát az emberek nem takarítanak maguk után. Mennyit javítana, ha ez ki lenne kényszerítve? Mennyire okoz a fenti méret lassulást, ha azokba a táblákba a query-k nem futnak bele? A cél a 10.000 L elérése év végére.
Amúgy ilyesmi query-k vannak:
SELECT
DISTINCT (62 paraméter neve vesszővel elválasztva)
FROM `eee_l` INNER JOIN `generalobj_gostatus` ON (`eee_l`.`way_to_eee_id` = `generalobj_gostatus`.`id`) WHERE (`generalobj_gostatus`.`code` = 'on_print' AND NOT (`eee_l`.`print_id` = '' AND `eee_l`.`print_id` IS NOT NULL) AND `eee_l`.`user_id` = 1 AND `eee_l`.`id` IN (1047, 1377, 1282, 83, 1303)) ORDER BY `eee_l`.`id` ASC
.
Találtam most egy olyan részt a kódban, ahol egy select (html) 32 eleméhez (option) mindig lefut egy sql query-s összehasonlítás. 20 terméknél ez már 640 plusz query, holott 20-ból, vagy kevesebből megoldható lenne... . Ezek azért hajmeresztőek.