Hirdetés
Új hozzászólás Aktív témák
-
Ha fafejség ellen kell harcolni, arra a nézettábla megoldás.
Itt az az érdekes helyzet van, hogy a nézettábla két irányból is alkalmazható:
1. van egy pocsék tárolási struktúrád, és abból akarsz jó nézetet generálni.
2. csinálsz egy rendes tárolási struktúrát és abból generálsz pocsék nézetet.Én azt javaslom, hogy minél előbb át kell térni a rendes megoldásra, vagyis 2.
Tehát megcsinálod a 3 táblát, elkezded abba tölteni az adatokat, akár visszamenőleg is, és ráhúzol annyi nézetet, amennyi az aktuális helyzetben kell. Ráadásul nézetet ráhúzni és eldobni sokkal egyszerűbb, mint alaptáblát módosítani. Megcsinálod, hogy azok a programok, amik a rossz struktúrát használják, használják a nézettáblákat, amiket meg ezután módosítotok, már az új megoldást használják.
szerk: ha minden szenzor egy tábla rendszerben tárolod az adatokat és egy nézettáblába hozod össze a sok táblát, akkor ott problémás lehet, hogy egy új szenzor hozzáadásakor megcsinálod a szenzor saját tábláját, és amikor a nézettáblát módosítod, akkor le kell bontani a korábbi nézettáblát és feltenni az újat. Ha pedig minden szenzor egy tábla rendszer van, akkor az új nézettábla létrehozása nem befolyásolja a többi működését.
Itt kerül elő az alapkérdés, hogy milyen a kapcsolat a fafejűekkel, hogy nekik mi mindenről van döntési joguk és mi mindent kell tudniuk. Én csendben átírnám, oszt jónapot.
-
Hasonló témához periférikusan közöm van. Egy táblába jönnek különböző mérők adatait és az időben egymást követő, de azonos mérő azonosítóhoz tartozó adatok egy növekvő sorszámmal vannak ellátva hasonlóan, ahogy Bambano is írta.
Ha egy lokáción lecerélik a mérőt, akkor az új mérő azonosítóval újra indul a sorszámozás. Nálunk csak dátum pontosságal jönnek az adatok, de így is kezelhetetlen lenne az egész, ha mérőnként lenne egy-egy tábla.
Nem én találtam ki, hogy így legyen, én csak felhasználója vagyok az adatoknak. -
Ha össze akarod kapcsolni a méréseket, akkor azt kell csinálni, hogy a mérés konkrét dátuma mellett egy azonosító sorszámot is leraksz a táblába, és azzal joinolsz, nem a dátummal. Persze lehetne olyat is, hogy az a program, ami a mérést végzi, lekér egy dátumot, amikor indul, és utána az összes mérési adatot azzal a dátummal teszi le.
Azt látom abból, amit leírtál, hogy nagyon erősen javasolt lenne nulláról újraterveztetni az egészet egy szakértővel. Az, hogy 500 darab azonos tábla legyen egy adatbázisban, az abszolút nonszensz.
"A View egyébként mindig a tartalmazza az összes adatot, azaz magától frissül?": a view, magyarul nézettábla *NEM LÉTEZIK*. Az egy definíció, ami leírja, hogy a tárolási sémából hogyan kell előállítani a nézettáblát. A lekérdezéskor számolódik ki. A magától frissül kérdés értelmetlen. Azt az adatot tartalmazza, amit megadsz neki, hogy tartalmazzon.
-
rum-cajsz
őstag
Nem ismerem a MariaDB lehetőségeit de én ezt úgy oldanám meg, hogy van egy function, amiben egy olyan kurzor van, ami a felolvasandó táblákon megy végig, a belseje pedig végrehajtja a lekérdezést a paraméterként kapott táblán, és egy record típusú OUT változóban gyűjti a dolgokat összegezve, alternatív megoldás, hogy egy külső táblába insertája a gyűjtött adatokatl. Ezt Postresben és Oracle-ben dinamikus query-nek hívják.
De ennek a megoldásnak elég komoly limitáció vannak és nagyon nem mindegy, hogy mennyi rekordon akarsz dolgozni. Mennyi recordot vársz eredménynek.
Ha jól olvasom, szenzorok adatait akarod összegezni, amire sokkal egyszerűbb és tartósabb megoldás a többek által javasolt triggeres módszer.
Arra is oda kell figyelni, hogy az adatbázisban ha elszaporodnak a táblák, az tud tárolási és működési kockázat lenni. Nem tudom hány szenzorról beszélünk, de mondjuk százezres nagyságrendnél az általad elképzelt bármelyik működés használhatatlan lesz. -
Akkor kell írni egy tárolt eljárást, ami a szenzorokból érkező adatokat kiegészíti egy szenzor azonosítóval és egy táblába insert-álja bizonyos időközőnként az összes szenzor adatait. A duplikált betöltés érdekében a datetime, counter, sensorid mezők összevonásával képeztek egy egyedi azonosítót, amire vizsgáltok betöltéskor, hogy ugyannak a szenzornak ugyanazon adata ne töltősldhessen be többször.
Ha új szenzor kerül a rendszerbe, akkor csak ezen töltő eljárást kell kiegészíteni az új szenzor táblájával és id-jával.
Így egy táblában lesz historikusan az összes szenzor adata és csak a töltést kell időzíteni automatikus futásra. -
postgresül így néz ki:
with T as (
SELECT date_part('year',Zeit) as Year,
date_part('month',Zeit) as Month,Zeit, zaehlerstand,
Zaehlerstand-coalesce(
lag(Zaehlerstand) over (order by Zeit),
zaehlerstand) as Consumption
FROM Energy)
select year,month,sum(consumption) from T
group by 1,2 order by 1,2;a problémád az lehet, hogy a lag függvény az első sorra NULL értéket ad, ezért a kivonás nem működik. tehát nem nullát, hanem NULL-t. ezt lehet kikerülni a coalesce függvénnyel.
-
lehet az a baj, hogy a group by és a lag sorrendje nem az, ami neked jó.
ezért javaslom a subquery-t. valahogy így:with alselect as (SELECT Month(zeit) as Month,Zaehlerstand - lag(Zaehlerstand) over (order by zeit) as "Consumption" FROM database.table)select * from alselect group bystb. nem ismerem a mysql-t, a pontos szintaxist az olvasóra bízzuk
-
ha nekem kellene ezt a problémát megoldani, első nekifutásra biztosan nem sql-lel foglalkoznék, hanem megnézném, hogy van-e erre a Grafana-nak megoldása. Az ilyen grafikonrajzoló cuccok ősének tekinthető mrtg ezt alapból tudta kezelni. emlékeim szerint gauge volt a konfig opció.
-
A napi, heti fogyasztást úgy tudod megoldani, hogy képzel két oszlopot a Time mezőből, az egyikben a napok, a másikban az Év-hetek leszenek (azért nem csak hét, mert több éves adasor esetén a különböző évek ugyanazon heteit nem tudnád megkülönböztetni.
Erre a két oszlopra mar tudod group by-olni a fent kiszámított két Time közötti fogyasztási adatokat.
Ha két időpont között szeretnéd kiszámolni, akkor WHERE feltételben korlátozod az intervallumot. (Where Time between x and y).Nap:
CAST(Time as date) as Datum
Év-hétCONCAT(DATEPART(year, Time), '/' , DATEPART(iso_week, Time)) as Ev_het -
A LAG fügvénnyel tudsz hivatkozni előző értékekre
LAG(Counter, 1) OVER (ORDER BY Time)
Ez az adott sor előtt időben eggyel lévő sor Counter értékét adja vissza. Ebből kivonod az aktuális sor Counter értékét és megvan a fogyasztás a két időpont között. Ugyanezt be tudod vetni az időre is csak ott Datediff-et használj a két időpont között eltelt idő kiszámításához. -
nyunyu
félisten
select akt.id,
akt.time aktualis_ido,
akt.counter aktualis_allas,
elozo.time elozo_ido,
elozo.counter elozo_allas,
akt.time - elozo.time eltelt_ido,
extract(day from (akt.time - elozo.time)*24*60*60)/60 eltelt_ido_perc,
akt.counter - elozo.counter allas_valtozas,
(akt.counter - elozo.counter)/extract(day from (akt.time - elozo.time)*24*60*60)/60 atlag_fogyasztas
from oraallas akt
left join oraallas elozo
on elozo.id = akt.id - 1
order by id; -
nyunyu
félisten
Tetszőleges két időpont közötti: lekérdezed a két időpont közötti rekordokat, és a max(óraállás)-ból kivonod a min(óraállás)-t, max(időbélyeg)-min(időbélyeg) megmondja, mennyi idő alatt, kettőt osztva megvan az átlag.
(Feltételezve, hogy az óraállás monoton nő, és nincs visszatekeréses buhera.)Egy perccel korábbihoz képesti változáshoz meg össze kéne joinolnod az aktuális rekordot az eggyel előzővel, és úgy kivonni az óraállásokat, időbélyegeket.
Itt az időbélyeg - 1 perc mint join feltétel nem biztos, hogy járható út, mert nem biztos, hogy kereken percenként van új rekord, inkább be kéne számozni a rekordokat egy row_number() over (order by timestamp)-kel, aztán úgy joinolni a saját rn -1-gyel.
Új hozzászólás Aktív témák
- Vadonatúj, bontatlan iScooter i9Max elektromos roller, 1 év gari 35 km/h
- ADATA XPG Lancer Blade 32GB (2x16GB) DDR5 6000MHz CL34 - XMP/EXPO - 120 hó garancia
- Kingston FURY Beast 64GB (2x32GB) DDR5 6400MHz CL32 - XMP/EXPO - 120 hó garancia
- Kingston FURY Beast 32GB (1x32GB) DDR5 5200MHz CL40 - XMP/EXPO - 120 hó garancia
- Kingston FURY Beast 32GB (1x32GB) DDR5 6400MHz CL32 - XMP/EXPO - 120 hó garancia
- GYÖNYÖRŰ iPhone SE 2020 64GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3920
- Keresek Galaxy S21/S21+/S21 Ultra/S21 FE
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! MSI B550M R5 5600X 16GB DDR4 512GB SSD RTX 3070 8GB Lian Li Lancool 207 GIGABYTE 750W
- 170 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4090
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopszaki Kft.
Város: Budapest