Hirdetés
- eBay-es kütyük kis pénzért
- Luck Dragon: Asszociációs játék. :)
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- Brogyi: CTEK akkumulátor töltő és másolatai
- bb0t: Ikea PAX gardrób és a pokol logisztikája
- GoodSpeed: Márkaváltás sok-sok év után
- ldave: New Game Blitz - 2025
- sziku69: Szólánc.
- Gurulunk, WAZE?!
- gban: Ingyen kellene, de tegnapra
Ú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
- BESZÁMÍTÁS! ASRock B550M R5 5600X 32GB DDR4 512GB SSD MSI SuprimX RTX 3070Ti 8GB Zalman Z1 PLUS 750W
- BESZÁMÍTÁS! MSI B450M R5 5600X 32GB DDR4 512GB SSD ASUS ROG STRIX RTX 3070Ti 8GB Zalman Z1 PLUS 750W
- 8x16 ddr4 vízhűtéses ram
- BESZÁMÍTÁS! MSI B450M R5 5600X 32GB DDR4 500GB SSD RX 6800 16GB Zalman Z1 PLUS Cooler Master 750W
- BESZÁMÍTÁS! ASROCK B650M R7 8700F 32GB DDR5 1TB SSD RX 7900XT 20GB Be quiet Pure Base 500FX EVGA750W
- Apple iPhone 13 Pro Max Sierra Blue ProMotion 120 Hz, Pro kamerák 128 GB Használt, szép,100%
- BESZÁMÍTÁS! Logitech G920 Driving Force Racing kormányszett
- Telefon felvásárlás!! Samsung Galaxy A20e/Samsung Galaxy A40/Samsung Galaxy A04s/Samsung Galaxy A03s
- BESZÁMÍTÁS! ASRock B550M R5 5600X 32GB DDR4 512GB SSD MSI SuprimX RTX 3070Ti 8GB Zalman Z1 PLUS 750W
- Apple iPhone 12 Pro Max 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest