Vím, že tu je pár šílenců (jako jsem já), kteří mají databázi více států. Já mám problém u jedné takové velké databáze, že mi SQL dotaz vrací špatný výsledek. Tak jsem chtěl poprosit někoho s velkou databází, jestli by to nevyzkoušel, abychom případně zjistili příčinu toho špatného výsledku.
Dotaz je to jednoduchý (má za úkol najít kešky s nejstarší aktualizací a platným listingem, abych si je zaktualizoval):
SELECT geocache.id FROM geocache INNER JOIN geolist ON geocache.id = geolist.id ORDER BY geocache.dtupdate2 LIMIT 50000
No a když ho provedu, tak se mi ve výsledku objeví i kešky, které jsem aktualizoval nedávno, přitom vím, že těch starých neaktualizovaných je tam více než ten požadovaný limit 50000. Tak když to někdo zkusíte, budu rád.
máš to dobře napsané, pokud aktualizuješ přes API. Mě to takhle fungovalo do té doby, než jsem začal aktualizovat přes pocket query. Docela by mě zajímalo kdy a jak se aktualizuje to pole geocache.dtupdate2. mám pocit, že při aktualizaci přes PQ se neaktualizuje. Ale možná se něco změnilo i s novým API..
Mě ale nejde o aktualizaci dtupdate2, ale o to, že po spuštění ten dotaz vrátí nedávno aktualizované keše, které v dtupdate2 mají třeba jen týden starou hodnotu a přitom v té velké databázi musí těch starých dlouho neaktualizovaných kešek být mnohem víc než těch 50000 v tom LIMITu
SQL dotaz nevrací špatný výsledek, ale jen to, na co se ptáš :D To, že si myslíš, že tam nějaká konkrétní data musí být, nutně neznamená, že tam jsou :)
Ale od toho přeci existuje SQL, aby sis to v databázi věřil. Na tvém místě bych si prostě vyjel keše, které mají datum aktualizace starší než nějaké datum, které si myslíš, že je dostatečně daleko v minulosti. A nebo si data zgroupuj podle data (nebo měsíců).
Odpověď píšu bez podrobnější znalosti obsažených dat. GG mám na ntb, který o víkendu umřel. Ale prostě bych se v té tabulce víc pošťoural, než začal tvrdit, že SQL dotaz vrací špatný výsledek.
K přesvědčení, že to vrací špatný výsledek mě vede třeba i to, že když ten LIMIT zvětším, tak se jakoby proporcionálně zvětší jak počet starých dat, tak počet nových dat. Takže takto se k těm starým datům dostanu, ale na úkor velikosti LIMITu, který musím několikanásobně zvětšit.
takže s narůstajícím limitem se až do určité hranice (zřejmě to narazí na tu opravdu nejstarší kešku) posouvá ta první keš víc do minulosti, zatímco poslední keš je pořád stejná
Obecne nemuze SQL vracet "spatny" vysledek a predstava, ze vysledek zavisi na velikosti databaze se mi zda hooodne podivna. A prikaz LIMIT preci nemeni velikost databaze, jen nastavuje pocet radku vypisu - pridavanim na konec.
Pozn.: Pokud vraci SQL **neocekavany** vysledek, znamena to, ze budto je spatne napsany nebo nejsou v databazi ocekavana data. A jeste muze pochopitelne nastat kombinace obojiho. :-)
no neco se mozna deje...vcera jsem pozoroval ve Statoru, ze se mi "otocily" kesky ve statistice "Prvni kes ve state", driv fungovaly tak jak maji, ted mi tahle statistika vypisuje posledni ulovenou kes v danem state....v definici modulu jsem nic nemenil... viz http://tarmara.synology.me/geoget/Statistics.html karta statistiky - ale v SQLite studiu použitý dotaz vrací správný výsledek, stejně tak při použití ve Smart filtru.
select id, cachetype "Type icon", Name, country "Country flag, text", dtfound||dttime "Found datetime"
from (
select gc.id, gc.name, gc.cachetype, gc.country,
substr(gc.dtfound,7,2) || '.' || substr(gc.dtfound,5,2) || '.' || substr(gc.dtfound,1,4) as "Found_date",
gc.dtfound, substr("0000"||gc.dtfoundtime,-4,4) dttime
from geocache gc
where gc.dtfound>0
order by gc.dtfound || dttime desc
)
group by country
order by dtfound || dttime asc
Tak PRAGMA integrity_check běžel asi 20 minut s tímto výsledkem:
g:\GeoGet.archiv>"C:\Program Files (x86)\GeoGet\sqlite3.exe" archiv.db3
SQLite version 3.28.0 2019-04-16 19:49:53
Enter ".help" for usage hints.
sqlite> PRAGMA integrity_check;
ok
sqlite>
SQL příkaz je tu napsaný a v něm nikdo chybu neviděl, a proč tedy SQL příkaz vrací starší záznamy při větším LIMITu? Tedy očekávaná data v databázi jsou, jen je problematické se k nim dostat. Kde by tedy mohla být chyba?
no neco se mozna deje...vcera jsem pozoroval ve Statoru, ze se mi "otocily" kesky ve statistice "Prvni kes ve state", driv fungovaly tak jak maji, ted mi tahle statistika vypisuje posledni ulovenou kes v danem state....v definici modulu jsem nic nemenil... viz http://tarmara.synology.me/geoget/Statistics.html karta statistiky - ale v SQLite studiu použitý dotaz vrací správný výsledek, stejně tak při použití ve Smart filtru.
select id, cachetype "Type icon", Name, country "Country flag, text", dtfound||dttime "Found datetime"
from (
select gc.id, gc.name, gc.cachetype, gc.country,
substr(gc.dtfound,7,2) || '.' || substr(gc.dtfound,5,2) || '.' || substr(gc.dtfound,1,4) as "Found_date",
gc.dtfound, substr("0000"||gc.dtfoundtime,-4,4) dttime
from geocache gc
where gc.dtfound>0
order by gc.dtfound || dttime desc
)
group by country
order by dtfound || dttime asc
Mnohokrat to tu uz zaznelo. Zmen DESC za ASC nebo odeber a pridej zpet modul. Nemam nejmensi tuseni, kdy a proc k tomu v minulosti doslo.
Tak PRAGMA integrity_check běžel asi 20 minut s tímto výsledkem:
g:\GeoGet.archiv>"C:\Program Files (x86)\GeoGet\sqlite3.exe" archiv.db3
SQLite version 3.28.0 2019-04-16 19:49:53
Enter ".help" for usage hints.
sqlite> PRAGMA integrity_check;
ok
sqlite>
SQL příkaz je tu napsaný a v něm nikdo chybu neviděl, a proč tedy SQL příkaz vrací starší záznamy při větším LIMITu? Tedy očekávaná data v databázi jsou, jen je problematické se k nim dostat. Kde by tedy mohla být chyba?
Tezko rict. Mne to dava stejne vydledky bez ohledu na to, kolik radku vypisu.
Napada me, ze pokud jsou hodnoty dtupdat2 stejne, pak vypis muze byt serazen ruzne "nahodne". Druha vec je, ze nektere kese, ktere jsou ze stare verze databaze a nebyly dosud aktualizovany, maji hodnotu dtupdate2=0.