Superhurtige dropdown-bokse — Forum på kbharkiv.dk (2016-2020)

Forfatter	Indlæg
Skrevet af bjørn enemark 2018-01-30 23:42:07	I dag opbygges dropdown-bokse ved hjælp af sql-kald til serveren, bortset fra de fastkodede felter køn og civilstand. Men hvis nu også de øvrige tabeller lå fast i programmet, så kunne dropdown-boksene opbygges ved at scanne tabellerne i memory, langt hurtigere! Jeg mener naturligvis ikke, at de skal være konstanter i programmet, det ville gøre det meget ufleksibelt. De skulle indlæses med sql fra begyndelsen og få lov til at blive liggende fra billede til billede. Jeg er dog lidt usikker på mulighederne for at holde data fra det ene billede til det andet i kildetasteren. (Normalt kan man gemme data i "parent"). Selv om det er mange elementer, så koster f.eks. dødsårsager kun 4500 * ca. 50 tegn, dvs. under 250.000, sikkert under 1 Mb for alle tabeller. Jeg forestiller mig et antal tabeller til data og id, en fælles placeringsrutine og en fælles søgerutine med tabel og søgekriterium som parametre. Data skulle naturligvis indlæses sorteret på prioritet og indhold, svarende til sql-kaldene i dag. Hvis data kan blive liggende i browseren, så vil belastningen på serveren også falde drastisk, blot ville browseren skulle genstartes for at få nytilkomne dødsårsager mv. ind. Selv hvis tabellerne skulle læses ind hver gang, ville det være en fordel ved de små tabeller: institution, dødssted, fra, sogn og til. Jeg har lavet og testet placeringsrutine og tilhørende søgerutine i Javascript til at søge på samme måde som med sql, dvs. med hensyntagen til % og _ i det angivne søgefelt ("query"). Søgerutinen tager også højde for at placere hits som i dag, dvs med dem, der starter med søgekriteriet forrest, prioriteret som i dag. Jeg sender gerne kode (ikke så egnet til Forum) og medvirker gerne. Ud over hastigheden ville det også løse problemerne med at sql-svar undertiden kommer i forkert orden (svar vedr. 2 bogstaver kan komme senere og overskrive svaret vedr. 3 bogstaver) Var det noget?
Skrevet af jeppec 2018-02-01 07:38:47	Hej Bjørn. Det lydet som en vej der skal afprøves. Jeg viser det til Bo :) Mange hilsner fra Jeppe Digitalarkivar ved Københavns Stadsarkiv
Skrevet af jeppec 2018-02-05 12:25:28	Hej Bjørn. Bo har set på dit script og kunne ikke umiddelbart inkoorperere det. Men jeg har haft en af vores datadiscpæle til at se på søgningerne til drop downlisterne og han fandt en måde at optimere den på. Således: SELECT id, deathcause, CASE WHEN deathcause LIKE ":query%" THEN 5 + priority ELSE priority END as prio FROM burial_deathcauses WHERE deathcause LIKE "%:query%" ORDER BY prio DESC, deathcause LIMIT 75; Jeg har indsat den på dødsårsagerne. I må gerne lægge mærke til om der er forskel på hastigheden på stillinger/gader overfor dødsårsagerne. Mange hilsner fra Jeppe Digitalarkivar ved Københavns Stadsarkiv
Skrevet af bjørn enemark 2018-02-05 13:36:42	Indrømmet, det er en større ændring at have tabellerne liggende som arrays i stedet for at slå op i dem på serveren! Jeg synes nu, at det er værd at se på. Mht. den optimering, du viser, så er det blot den indre sql. Jeg skrev til dig om den mulighed 2018-01-22. Jeg havde egentlig forventet, at Javascript ville fejlmelde, at der kommer tre parametre retur (id, deathcause og prio) i stedet for to.
Skrevet af jeppec 2018-02-19 09:54:55	Hej Bjørn og andre Kan I mærke en forskel på om dropdown-liste på dødsårsager er blevet hurtigere end fx gader? Det vil vi gerne have afklaret, altså om den optimering er mærkbar eller ej. Ellers skal vi ud i den noget mere tidskrævende ændring med at listerne i cachen Mange hilsner fra Jeppe Digitalarkivar ved Københavns Stadsarkiv
Skrevet af Grønvold 2018-02-19 14:15:43	Hej Jeppe Der er overhovedet ingen forskel. Det tager stadig ekstremt lang tid, også at taste dødsårsager. Så du må vist i gang med den store operation, så det kan blive bekvemt at taste igen. Glad hilsen og god dag Birthe Mylius Grønvold Kroman Profiler: genealogiskforum.dk: http://genealogiskforum.dk/ Genealogisk forum på Facebook: https://www.facebook.com/groups/genealogiskforum/ Facebook: https://www.facebook.com/birkro Linkedin: https://www.linkedin.com/in/birthekroman/
Skrevet af minna 2018-02-19 18:55:43	Enig med Birthe.
Skrevet af jeppec 2018-02-20 08:06:18	Tak for efterretning :) Jeg gør hvad jeg kan for at skyde den op i prioriteringen. Mange hilsner fra Jeppe Digitalarkivar ved Københavns Stadsarkiv
Skrevet af bjørn enemark 2018-02-20 15:47:54	Jeg er enig med Birthe og minna, ingen forbedring. Den indre sql søger igennem 4500 poster, tester hver enkelt op mod det indtastede og sorterer resultatet. Den ydre sql læser 10-15 poster (som allerede ligger i sql-cache) og fjerner blot prio-feltet. Så at nøjes med den indre sql (og sende alle tre felter videre) kan ikke gøre nogen egentlig forskel. Jeg tænker mere på den "forsinkelse", som er lagt ind for at undgå at svaret på to tastede bogstaver kommer senere end svaret på tre bogstaver. Er det den, som gør systemet langsomt?
Skrevet af jeppec 2018-02-21 08:13:41	Hej Bjørn Ja, tror vi skal prøve at fjerne den forsinkelse, som jeg ved Bo har lagt ind. Det vender jeg med ham. Mange hilsner fra Jeppe Digitalarkivar ved Københavns Stadsarkiv