Přejít na obsah


Fotka

Nesprávný výsledek SQL dotazu u velké db


  • Pokud chcete vložit odpověď, přihlašte se
37 odpovědí na toto téma

#1 Kreten8

Kreten8

    Advanced Member

  • Members
  • PipPipPip
  • 1 753 příspěvků(y)

Publikováno 09 červenec 2019 - 15:25

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.
  • 0

#2 tarmara

tarmara

    Air-cooled

  • Members
  • PipPipPip
  • 969 příspěvků(y)

Publikováno 09 červenec 2019 - 15:47

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..


Tento příspěvek byl upraven od tarmara: 09 červenec 2019 - 15:48

  • 0

#3 Kreten8

Kreten8

    Advanced Member

  • Members
  • PipPipPip
  • 1 753 příspěvků(y)

Publikováno 09 červenec 2019 - 15:58

Aktualizuji přes API, PQ u této databáze vůbec nepoužívám.
  • 0

#4 HaLuMa

HaLuMa

    Autor Geogetu

  • Members
  • PipPipPip
  • 14 508 příspěvků(y)

Publikováno 09 červenec 2019 - 16:35

aktualizovat by se to melo vzdycky. (tyhle zakladni udaje se aktualizuji vzdy, u listingu a logu se aktualizuje jen kdyz jsou zmeneny.)

 

Pokud se tak nekdy nedeje, je to chyba a je mi treba nahlasit zpusob importu, ktery s tim nehnul.


  • 0

#5 Kreten8

Kreten8

    Advanced Member

  • Members
  • PipPipPip
  • 1 753 příspěvků(y)

Publikováno 09 červenec 2019 - 16:41

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
  • 0

#6 Shashlick

Shashlick

    Advanced Member

  • Members
  • PipPipPip
  • 513 příspěvků(y)

Publikováno 09 červenec 2019 - 17:48

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. 


  • 1

Jde se lovit!

Moje statistiky ZDE


#7 Kreten8

Kreten8

    Advanced Member

  • Members
  • PipPipPip
  • 1 753 příspěvků(y)

Publikováno 09 červenec 2019 - 18:11

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.
  • 0

#8 LudekV

LudekV

    Advanced Member

  • Members
  • PipPipPip
  • 2 166 příspěvků(y)

Publikováno 09 červenec 2019 - 20:12

A co si třeba vypsat i dtupdate2 a podívat se, co v něm máš?

SELECT geocache.id,geocache.dtupdate2 FROM geocache INNER JOIN geolist ON geocache.id = geolist.id ORDER BY geocache.dtupdate2 LIMIT 10000;

Mám v databázi něco přes 100 000 keší, dotaz se mi chová naprosto konzistentně, s narůstajícím LIMIT prostě přidává další, začátek je stále stejný.


  • 0

a : Drake - vše potřebné pro (offline) geocaching na Android * Stránka projektu na GitHubu - požadavky a reklamace

Hlavní kešovací zažízení: Samsung Galaxy A41


#9 Kreten8

Kreten8

    Advanced Member

  • Members
  • PipPipPip
  • 1 753 příspěvků(y)

Publikováno 09 červenec 2019 - 21:35

No mě se to chová takto:
Limit  první keš          poslední keš
5000    8. 4.2019 22:18 - 10.5.2019 16:47
50000  21.12.2018 22:31 - 10.5.2019.16:47
200000 19. 5.2018 19:25 - 10.5.2019 16:47
500000 19. 5.2018 19:25 - 10.5.2019 16:47
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á

Tento příspěvek byl upraven od Kreten8: 09 červenec 2019 - 21:36

  • 0

#10 Kreten8

Kreten8

    Advanced Member

  • Members
  • PipPipPip
  • 1 753 příspěvků(y)

Publikováno 09 červenec 2019 - 21:38

Mám v databázi něco přes 100 000 keší, dotaz se mi chová naprosto konzistentně, s narůstajícím LIMIT prostě přidává další, začátek je stále stejný.

tady si nejsem jist, že je to dostatečně velká databáze
  • 0

#11 HaLuMa

HaLuMa

    Autor Geogetu

  • Members
  • PipPipPip
  • 14 508 příspěvků(y)

Publikováno 09 červenec 2019 - 21:42

a kontrolu integrity databaze jsi zkousel?


  • 0

#12 Kreten8

Kreten8

    Advanced Member

  • Members
  • PipPipPip
  • 1 753 příspěvků(y)

Publikováno 09 červenec 2019 - 21:45

Na databázi pravidelně dělám VACUUM, REINDEX a ANALYZE - je snad ještě nějaká další možnost jak databázi "opravovat"?
  • 0

#13 HaLuMa

HaLuMa

    Autor Geogetu

  • Members
  • PipPipPip
  • 14 508 příspěvků(y)

Publikováno 09 červenec 2019 - 21:51

myslel jsem pragma integrity_check


  • 0

#14 gord

gord

    Advanced Member

  • Members
  • PipPipPip
  • 10 107 příspěvků(y)

Publikováno 10 červenec 2019 - 7:25

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. :-)


  • 1

MHD/PID vybranych mest CR jako POI (diskuse)
GeoGet:
- Combine - automatizace opakovanych cinnosti (diskuse, dávky)

Stator - statistiky y GeoGetu (diskuse)

- Spoiler - uložení spoilerů do GPS jako POI (diskuse)

- Náhrada GJ legálními postupy

 


#15 tarmara

tarmara

    Air-cooled

  • Members
  • PipPipPip
  • 969 příspěvků(y)

Publikováno 10 červenec 2019 - 10:13

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.synol...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

Tento příspěvek byl upraven od tarmara: 10 červenec 2019 - 10:23

  • 0

#16 Kreten8

Kreten8

    Advanced Member

  • Members
  • PipPipPip
  • 1 753 příspěvků(y)

Publikováno 10 červenec 2019 - 10:41

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?

Tento příspěvek byl upraven od Kreten8: 10 červenec 2019 - 10:42

  • 0

#17 gord

gord

    Advanced Member

  • Members
  • PipPipPip
  • 10 107 příspěvků(y)

Publikováno 10 červenec 2019 - 10:44

 

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.synol...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.


  • 0

MHD/PID vybranych mest CR jako POI (diskuse)
GeoGet:
- Combine - automatizace opakovanych cinnosti (diskuse, dávky)

Stator - statistiky y GeoGetu (diskuse)

- Spoiler - uložení spoilerů do GPS jako POI (diskuse)

- Náhrada GJ legálními postupy

 


#18 Kreten8

Kreten8

    Advanced Member

  • Members
  • PipPipPip
  • 1 753 příspěvků(y)

Publikováno 10 červenec 2019 - 10:46

Teď jsem si pro zajímavost dal LIMIT jen 5 a vrátilo mi to jednu kešku s datumem 8.4.2019 22:18 a čtyři s datumem 3.5.2019 22:17
Kam se ztratily všechny staré kešky?

Tento příspěvek byl upraven od Kreten8: 10 červenec 2019 - 10:47

  • 0

#19 gord

gord

    Advanced Member

  • Members
  • PipPipPip
  • 10 107 příspěvků(y)

Publikováno 10 červenec 2019 - 11:34

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.


  • 0

MHD/PID vybranych mest CR jako POI (diskuse)
GeoGet:
- Combine - automatizace opakovanych cinnosti (diskuse, dávky)

Stator - statistiky y GeoGetu (diskuse)

- Spoiler - uložení spoilerů do GPS jako POI (diskuse)

- Náhrada GJ legálními postupy

 


#20 Shashlick

Shashlick

    Advanced Member

  • Members
  • PipPipPip
  • 513 příspěvků(y)

Publikováno 10 červenec 2019 - 12:12

A zkoušel jsi už vyjet si i tem dtupdate2, jak psal Luděk? 

SELECT geocache.id,geocache.dtupdate2 FROM geocache INNER JOIN geolist ON geocache.id = geolist.id ORDER BY geocache.dtupdate2 LIMIT 10000;

Ideálně to vyjeď a pak zkopíruj třeba pár prvních a posledních řádků (mohl by stačit i printscreen).


Tento příspěvek byl upraven od Shashlick: 10 červenec 2019 - 12:12

  • 0

Jde se lovit!

Moje statistiky ZDE





0 uživatel(ů) prochází toto téma

0 uživatelů, 0 návštěvníků 0 anonymních uživatelů

Reklama

Naše nabídka