Új hozzászólás Aktív témák
-
Taci
addikt
válasz bambano #5077 üzenetére
Alapból a my.ini-ben ez volt:
innodb_buffer_pool_size = 16MEzt most kicseréltem ennek a tartalmára:
my-innodb-heavy-4G.ini
innodb_buffer_pool_size = 2GÍgy a lekérdezés első futtatása ugyanúgy ~20mp-ig tartott, viszont amikor újra futtattam, már csak 0.01-ig.
Szóval ennél a lekérdezésnél a memória bővítése valóban segített, viszont, csak addig, amíg pont ugyanezt a lekérdezést futtatom, mert így memóriából tudja újra felhasználni. Amint akár egy feltételt is módosítok, újra 20mp várakozás, memóriába töltés. Aztán megint változtatok, megint várakozás. És ez csak 1 felhasználó, nem 10e-100e.Szóval sajnos nem ez a jó megoldás, de azért köszönöm a tippet.
------
@martonx: Az a legelső ajánlásaitok egyike volt, azóta indexelve van. Írtam is 3 hozzászólással korábban, hogy indexelt a feed_date.
Az EXPLAIN-eknél látszik, hogy hiába indexelt, mégis, ha van DISTINCT és ORDER BY is, akkor átnéz és rendez 410e rekordot lekérdezésenként, ezért tart 20 mp-ig...
Ha csak az ORDER BY-t használom, akkor 0,01 mp:
Ha csak a DISTINCT-et használom, akkor is 0,01 mp:
------
És ha van mindkettő, DISTINCT és ORDER BY is, akkor nem a jó logika mentén alkalmazza a DISTINCT-et, mert ez a találat (a LIMIT 4-gyel):
Tehát így a rekordok valóban különbözőek, viszont ezt ugye a JOIN-os nagy egészre nézi. És ebben benne van az általatok javasolt plusz tábla, amibe ki lettek szedve a kategóriák, hogy ha egy bejegyzéshez több kategória is tartozik, akkor az mind külön rekord legyen. És ezzel így összefűzve a DISTINCT valóban jó eredményt ad - csak rossz logika szerint:
nekem az kellene, hogy a feed_id-kra legyen vonatkoztatva, tehát a képernyőfotós példában a 100111 csak egyszer szerepeljen. -
Taci
addikt
válasz bambano #5104 üzenetére
Talán ez lehet a jó irány...
Most így néznek ki a lekérdezések:
Az "eredeti" (a javasolt változtatásod előtti):
SELECT i.item_id, i.item_date
FROM items AS i
JOIN items_categories AS ic
ON i.item_id = ic.item_id
JOIN categories AS c
ON c.category_id = ic.category_id
WHERE
c.category_id NOT IN (1,3,13,7,20)
AND
i.item_id NOT IN (117,132,145,209,211)
GROUP BY i.item_id
ORDER BY i.item_date DESC LIMIT 4
Showing rows 0 - 3 (4 total, Query took 10.8688 seconds.)
A categories tábla kivétele a Join-ból:
SELECT i.item_id, i.item_date
FROM items AS i
JOIN items_categories AS ic
ON i.item_id = ic.item_id
WHERE
ic.category_id NOT IN (1,3,13,7,20)
AND
i.item_id NOT IN (117,132,145,209,211)
GROUP BY i.item_id
ORDER BY i.item_date DESC LIMIT 4
Showing rows 0 - 3 (4 total, Query took 5.0478 seconds.)
A subquery-s megoldás (WITH-et nem engedett használni, így most ezt a megoldást találtam a "helyettesítésére"):
SELECT item_id, item_date
FROM items
WHERE
item_id IN (select item_id from items_categories where
category_id not in (1,3,13,7,20) and
item_id not in (117,132,145,209,211))
ORDER BY item_date DESC LIMIT 4
Showing rows 0 - 3 (4 total, Query took 0.7163 seconds.)
(És ide már nem is kell a Group By.)
Frissítettem a db-fiddle-t vele.
Mind a 3 változat ugyanazt a 4 rekordot adja vissza, helyesen.
Ez utóbbi, az általad javasolt valóban sokkal gyorsabb - bár (lehet, az én implementálásom miatt) még így is lassú (0,8 mp környéki lekérdezés).
(Furcsa mód ha kiveszem az Order By-t belőle (ami eddig csak lassította), a 0,8 mp-ből 6,6 mp lesz...)De ezzel talán már el lehet indulni ebbe (subquery) irányba.
Még valami ötlet esetleg ehhez az irányhoz?Köszönöm a tippeket és hogy ránéztél!
[ Szerkesztve ]
-
tm5
tag
válasz bambano #5150 üzenetére
SELECT TRUNC(datum) AS nap,
CASE WHEN DATEPART(HOUR,datum)>11 THEN 'DU' ELSE 'DE' END AS napszak,
SUM(szam) AS osszeg
FROM tabla
GROUP BY nap,
CASE WHEN DATEPART(HOUR,datum)>11 THEN 'DU' ELSE 'DE' END
ORDER BY 1,2
Legyen neked Karácsony Nálunk 12 és 1 között ebéd szünet van, olyan senkiföldje. -
sztanozs
veterán
válasz bambano #5156 üzenetére
Ez viszont nem jól fogja számolni, lesz egy nap két DE (2*8 óra, hajnalban és éjszaka) és egy DU (1*16 óra napközben).
Valahogy így lehet jó:
SELECT
TRUNC(dateadd(hour,-8,datum)) AS nap,
CASE WHEN date_part('hour',dateadd(hour,-8,datum))>12 THEN 'DU' ELSE 'DE' END AS muszak,
SUM(szam)
FROM tabla
GROUP BY 1,2 ORDER BY 1,2;Így a hajnal még az előző naphoz fog tartozni mint DU műszak.
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
sztanozs
veterán
válasz bambano #5161 üzenetére
Jaja, viszont a tiéd matematikailag helytelen: az egybe nem tartozó ‘délelőtti’ értékeket kumulálja (az előző második műszak végét, a következő második műszak elejével).
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Taci
addikt
válasz bambano #5436 üzenetére
Annyira szeretném érteni, amit írtok, de csak fejek jönnek elő belőlem (meg rengeteg kérdés).
Google Analytics erre a megoldás, saját kókányolás helyett.
Szeretnék egy menüpontot, hogy pl. "Legolvasottabb cikkek". De az nem világos, hogy hogyan lehet jobb az Analytics-es adat, mint a saját szerveren tárolt. Vagy van rá mód, hogy direktben elérjem ezt az adatot (Google), és be tudja építeni egy query részeként? Tehát hogy pl. rendezze sorba a cikkeket aszerint, hányszor voltak megnyitva (aka. Legolvasottabb cikkek). Mert csak erre kellene.az a megoldás, ha a link a saját webjére mutat és redirectel a célra.
Ezt elmagyaráznád, kérlek, hogy miért jó? Szeretném megérteni, hogy aztán implementálni tudjam. (Ez offtopic ide, ezért rakom off-ba, de nagyon szeretném érteni.)
Így hirtelen ami eszembe jutott, hogy külső linkekkel operál az a hírkereső. Meg is néztem gyorsan, ott ez hogyan van megoldva.Egy példa (direkt nem alakítom linkké):
https://rd.hirkereso.hu/rd/39891270?place=6544&partner=hirkereso&url=https%3A%2F%2Fprohardver.hu%2Fhir%2Fjon_lg_elso_hibrid_projektora.htmlEz ide dob tovább:
https://prohardver.hu/hir/jon_lg_elso_hibrid_projektora.htmlMegköszönném, ha lenne annyi türelmed, hogy pár szóban elmagyarázod, hogy ez a link miért így épül fel. Pl. itt miért kell az "rd" aldomain? redirect, gondolom, de ez miért kell?
https://rd.hirkereso.hu/rd/39891270
Ez is ugyanoda továbbít, már a többi rész nélkül is. (és minden más cikkhez is van egy ilyen "redirect-id") Akkor miért kell a többi rész? Nem is igazán értem, bár ez gondolom a saját kódjához kell valamiért.És ennek a headerjében van a
Status Code: 301 (from disk cache)
location: https://prohardver.hu/hir/jon_lg_elso_hibrid_projektora.htmlViszont semmilyen forrásadatot nem látok, nem tudom, hogy továbbít.
Szóval talán az aldomain azért kellhet, mert ezekhez a külsős linkekhez csinált 1-1 saját linket a redirect aldomain-ban, és ezek a linkek 301-el továbbítják a valós cikkhez?
Ez plusz forgalmat generál neki? Vagy miért jó?Milyen rendszert kell építeni mögé? Mit kell hogy tudjon?
És miért jobb, ha így nyílik meg a link, mintsem a direkt link? Mi a célja, szerepe?
A startlap pl. a külsős linkeket simán csak belinkeli, nincs redirect. Akkor ők rosszul csinálják?Vagy ha nincs türelmed, kedved, természetesen azt is megértem, csak kérlek, ez esetben legalább a megfelelő keresőszavakkal segíts, hogy a megfelelő cikkeket találjam meg.
Egy általános "url redirect" sajnos nem mondja meg, hogy hogyan (és miért) kell saját weblapról saját weblapra átirányítva átirányítani. (Se másik jó pár keresés az utóbbi majd' 1 órában.)
Köszönöm.
-
-
sztanozs
veterán
-
cog777
senior tag
válasz bambano #5621 üzenetére
Koszi a valaszt!
A gepek rendkivul pontos helyzete van naplozva es abbol terkep felepitve, igy nem igazan van mas valasztasunk mint szinkronizalni az adatokat. Tudom hogy nagy szivas az ilyen , szerencsere van egy DB expert is velunk, hat majd meglassuk.Sok adat keletkezik es a leheto leggyorsabban kell atkuldeni, hogy a gepek lassak a tobbi poziciojat es az irodaban ulo menedzser is
Elertuk azt a pontot amikor elkezdtuk hasznalni a syslog-ot is
HP ZBook Studio 15.6 G8 Mobile Workstation - Windows 11
-
nyunyu
félisten
válasz bambano #5627 üzenetére
az külön necces, hogy egyes gépen hol van net, hol nincs, ahelyett, hogy ilyenkor másik gépen keresztül küldi az adatot, inkább oldjátok meg, hogy legyen net. mibe se kerülne egy építési területre saját wifit telepíteni...
Mondjuk egy Paks2 alapozását ássa 25 munkagép jellegű témánál macerás lehet a saját wifi kiépítése, de mobilnettel megoldható.
Hello IT! Have you tried turning it off and on again?
-
cog777
senior tag
válasz bambano #5627 üzenetére
"inkább oldjátok meg, hogy legyen net. mibe se kerülne egy építési területre saját wifit telepíteni..."
Minden gep 4G modemmel rendelkezik azonban bizonyos orszagok, bizonyos teruletein nincs net, pl hegyekben, kint a tajgan, oserdoben stb.
Pl Alpokban a ho'tolo'k allomasanal van internet, de amikor kimennek, akkor vannak foltok ahol total nincs net es nem fognak telepitgetni nagy tavolsagu wifi allomasokat."ne kelljen multimastert csinálni, mindig pontosan egy irányba menjenek az adatok "
jah, egyetertek, 1 master eseten sokkal konnyebb lenne az elet.@tobbieknek: koszi az eszreveteleket.
HP ZBook Studio 15.6 G8 Mobile Workstation - Windows 11
-
fjanni
tag
válasz bambano #5829 üzenetére
Igen, valószínűleg a subquery a megoldás amiatt amit írtál.
Készítettem egy queryt de valamiért hibás:
(
SELECT
Year (zeit) as Year,
Month(zeit) as Month,
Zaehlerstand-lag(Zaehlerstand) over (order by zeit) as "Consumption"
FROM table
) as T
select * FROM T group by Year, MonthMi lehet a gond?
-
fjanni
tag
válasz bambano #5836 üzenetére
Köszi, a sum(consumption) a külső Select-ben segített.
Most már jól működik, összesít és a 12. hónap is megvan.
Márcsak egy gond van, valahogy hiányzik a két hónap közötti adat, azaz a hónap első számlálóállása és az előző hó utolsó számlálóállása közötti adat. Azaz a sum-ban csak azok a különbözetek szerepelnek amelyekben mindkét Zeit ugyanahhoz a hónaphoz tartozik. -
coco2
őstag
válasz bambano #5877 üzenetére
Szerintem azt a táblát ügyesebben is használhatnád. Előre gyárthatnál egy intervallum listát dátum tól-ig, amikhez bejegyzed, hogy abban az intervallumban az eredeti határidőt X-re át kell írnod (tovább tolod). Ha nem találtál olyan tábla sort, marad a régi. Ha akár perc pontosan akarsz számolni, akkor naponta egy sor, ami éves viszonylatban még mindig csak 365 sor. Nem a világ vége.
>valaki akar egy ilyen sql lekérdezésen agyalni?
A lekérdezést nem írom meg helyetted, a lusta mindenit
>előre is kösz.
you welcome
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
nyunyu
félisten
válasz bambano #5877 üzenetére
Nálunk ez úgy van megoldva, hogy van egy days tábla, amibe kolléga minden decemberben feltölti előre a következő évi dátumokat, meg mellé, hogy hanyadik napja a hétnek.
Ha valami ünnepnap, akkor 1-7 helyett 8 értéke van, ha meg munkanap áthelyezéses szombat, akkor 5 (péntek) lesz az értékeEzt használva az x. napot követő első munkanap lekérdezés úgy alakulna, hogy megnézed, hogy a kérdéses dátum+x. nap után melyik a legkisebb olyan nap, aminek 1-5 közötti az értéke.
Ha meg x. munkanap kell, akkor a kérdéses dátumnál nagyobbak közül sorbarakod az 1-5 közötti értékűeket, aztán ebből veszed az x. legkisebbet.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz bambano #5883 üzenetére
x. munkanap:
select actdate
from (
select d.actdate, row_number() over (order by actdate asc) rn
from days d
where d.actdate > to_date('2024-12-20','yyyy-mm-dd')
and d.dateid in (1,2,3,4,5) --munkanap
)
where rn = 15;
-- 2025-01-17 00:00:00(actdate a dátum mező, dateid-ben van tárolva az 1-7 hétfő-vasárnap, 0 ünnep)
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
coco2
őstag
válasz bambano #5882 üzenetére
>Nem elég egyszer feltölteni, mert az, hogy mi munkanap, folyamatosan változhat.
HR portálon előző év végén már ott a lista következő évre. Elvileg nem kellene túl nagy ügynek lennie, hogy írsz egy függvényt, aminek tömbösen behajigálod azokat az adatokat, és az legyártja neked a korrekciós táblát. Évente 1x kicsi manuális pepecselés, de ha ennyitől kizökkensz, add ki diákmunka cégeknek
Eltérő ünnepnap halmozódások.
Ha jól értettem, hosszú határidők vannak, és menet közben több ünnepnap, hétvége, olyasmi tud közbe jönni, és az a problémád, hogy olyankor eltérő korrekció kell. Nos, ha legalább a határidők folyton azonos hosszúságúak, az induló napból egy korrekciós tábla meg tudja neked adni a határidő lejártát. Mert azt előre kiszámolod. Ha eltérő határidők léteznek, mint 8,15,23,32 nap és társai, részint csinálhatsz minden határidő típusra külön táblát, részint csinálhatod azt, hogy tábla elemek helyére egy json stringet raksz be, ami attól a naptól kezdve az összes határidő típusra ad egy kimenetet, és a string lekérdezése után a json-t parsingolod, aztán felhasználod. A json belefér 1 táblába, de kissé N1NF. Ha szebben akarod, az több tábla lesz, és az lesz "csúnyább"
Ha adatkezeléssel foglalkozol, nem baj, ha nem akadsz ki azon, hogy gyártani kell pár táblát, amit fel is kell töltened. Vagy ha annyitól kiakadsz, és látni sem bírod az adatkezelést, inkább bízd azt a részét másra. Amit nem látsz, az nem fáj
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
nyunyu
félisten
válasz bambano #5892 üzenetére
Ja, ha multikulti környezetben akarod ezt használni, akkor kell még egy oszlop a days táblába, ahova felveszed az országot/tartományt, aztán a függvénybe/querybe azt a feltételt is beleteszed, hogy melyik ország/tartomány munkanapjait számolja.
De akkor lehet szívni az olyan különbségekkel, mint pl. araboknál péntek-szombat a hétvége, tehát arab országoknál a vasárnap lesz az 1, csütörtök az 5 a táblában.
Meg külön-külön összevadászni+felvinni a helyi ünnepeket...[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz bambano #5897 üzenetére
Akkor legenerálod helyben az adott dátumnál nagyobb hétköznapokat, ebből a halmazból kivonod (minus vagy left outer join) a főnököd dátumait, aztán abból keresed x. legkisebb értéket.
De ezzel nem oldottad meg a szombati munkanapok kérdését.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz bambano #5899 üzenetére
Oracleben gyorsan összedobva:
with munkanap as (
select a.*
from (
select to_date('2023-12-31','yyyy-mm-dd') + rownum as actdate, to_char(to_date('2022-12-31','yyyy-mm-dd') + rownum, 'd') as dateid
from (
select rownum r
from dual
connect by rownum <= 5000)
) a
left join days d
on d.actdate = a.actdate
and d.dateid = 0
where a.dateid in (1,2,3,4,5)
and d.actdate is null)
select actdate
from (
select m.*, row_number() over (order by actdate asc) rn
from munkanap m
where m.actdate > to_date('2024-12-20','yyyy-mm-dd')) x
where rn = 15;Ahogy néztem reggel, Postgre szintaxissal sokkal egyszerűbb lenne a munkanap CTE.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
coco2
őstag
válasz bambano #5897 üzenetére
Ha 60 nappal előre mindig meg kell adni, mi lesz munkanap, és mi nem, amin utólag nem változtathatnak, és határidőt soha sem kell 60 napra előre számolni, akkor létezik logikus megoldás. Hanem azt korábban nem írtad, és nekem nincsen ismeretem a kérdéses környezet ügyintézésében. Mint ahogy abban sem, létezik-e 60 napon túli határidő? Ha igen, megint csak baj van.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
nyunyu
félisten
válasz bambano #5921 üzenetére
De kéne.
Eredeti DBben nem ugyanúgy hívják a hiteligenylesek meg a másik rendszerből származó táblákban a számlaszámos mezőket, így nem akadt fenn azon az Oracle, hogy elfelejtettem táblaaliast írni a select oszlopai elé, mivel egyértelmű volt, hogy melyik táblából jön.
Csak itt a szemléltetés kedvéért olvashatóbbá egyszerűsítettem a kódot, és nem követtetem a DBnk örökölt hülyeségeit, hogy minden táblában másképp hívják ugyanazokat a mezőket, aszerint, hogy ki mikor/hogyan specifikálta.
Pl. createdate vs create_date még az egyszerűbbik eset...
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz bambano #5924 üzenetére
Az a bajom, hogy túlzottan alulnézetből látom az adatokat, és nem mindig ismer(het)em a keletkezésük, elromlásuk pontos körülményeit a különböző rendszerek közti adatszinkronizációk útvesztőjében, viszont nekem kéne helyrekalapálni a félreálló biteket.
Bár elnézve azt,hogy ~3500 GDPR érett igénylést akartam javítani, de belekerült 10 friss is a szórásba, az csak 0.3% hibaarány, bőven elviselhető kerekítési hiba
Hello IT! Have you tried turning it off and on again?
Új hozzászólás Aktív témák
- Eladó Canon EOS-550D váz + EF-S 50mm f/1.8 objektív (fix fókuszú/makró)
- Lenovo ThinkPad T470s, I7-6600U, 8GB RAM, FHD, 2 év garancia, áfás számla! (43)
- Samsung Galaxy S23 Ultra 1TB + 12GB RAM Gyári független (Phantom Black) SM-S918 + 24 hó garancia
- Samsung Galaxy S23 Ultra 1TB + 12GB RAM Gyári független (Phantom Black) SM-S918 + 24 hó garancia
- LG 65" B3 OLED 4K HDR SMART 120HZ GAMING TV
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen