Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Jan Kolář 03. 03. 2017, 13:14:25
-
Zdravím,
narazil jsem na problém, který mi dává zabrat. Mam databázi která obsahuje tabulku v niž je uložen čas, co za typ zařízení měřím a jeho hodnota. Tabulka až na čas toto obsahuje 60x. Tedy něco jako time_id, type1, i1, type2, i2, type3, i3.... type60, i60.
Teď ten problém. Během měření vyměním type1 = A za type1 = B, type2 nechám na původní hodnotě (např C) a měřím dál. Pokud však chci poté vygenerovat CSV z databáze tak SELECT time_id, i1, i2, FROM data WHERE type1=A or type2=C vrátí hodnoty měření i pro type1 = B (LOGICKY). Dotaz zní - lze nějak jednodušše vygenerovat dotaz aby vracel 0 do sloupce i1 pokud type1 se nerovna A?
Předem děkuji zkušenějším za radu
-
nechapem na co sa presne pytas, pretoze davas konkretny SELECT ale tabulku uz nedefinujes ...
t.j co je napr. i1, i2, typ1 a k tomu, ze preco menis typ zariadenia ...
---------------
vykasli sa na konkretny popis co robis, ale ries iba tabulky
---------------
btw. nemal si na mysli nieco ako CASE ?
SELECT
time_id,
CASE
WHEN type1 <> 'A' then 0
ELSE i1
END i1,
i2
data WHERE type1=A or type2=C;
-
samozrejme mi tam chyba FROM :-/
SELECT
time_id,
CASE
WHEN type1 <> 'A' then 0
ELSE i1
END i1,
i2
FROM
data
WHERE
type1= 'A'
OR type2='C';
nechapem na co sa presne pytas, pretoze davas konkretny SELECT ale tabulku uz nedefinujes ...
t.j co je napr. i1, i2, typ1 a k tomu, ze preco menis typ zariadenia ...
---------------
vykasli sa na konkretny popis co robis, ale ries iba tabulky
---------------
btw. nemal si na mysli nieco ako CASE ?
SELECT
time_id,
CASE
WHEN type1 <> 'A' then 0
ELSE i1
END i1,
i2
data WHERE type1=A or type2=C;
-
preco taketo veci neriesis na aplikacnej urovni?
matlat nejaku logiku do SQL s milionom CASE a WHERE je cesta do pekla
-
Tak presne toto zafungovalo... Dekuji
Teoreticky bych to mohl resit jeste na urovni PHP ktere ty data zpracovava (a v jednom pripade generuje jako CSV) ale z principu veci mi tohle prislo jako rychlejsi reseni nez to delat v PHP (a nacitat krome sloupcu ineco i sloupec typeneco).
Dalsi zadrhel me ceka jak rychle dokaze raspberry pi3 zpracovavat bobtnajici databazi rychlosti jeden radek za 15min po nekolika mesicich behu :)
Jsem ale otevren veskerym myslenkam
-
Asi v pohodě. Stačí indexy. A kdyby to bylo hodně let, tak rozhodit data na víc tabulek třeba po rokách či měsících.
Případně detailní záznamy udržovat jen za poslední třeba rok a u starších záznamů převést třeba na denní průměry, maxima, minima. Možností je hodně.
-
Ještě doplním, že jestli chceš mysql provozovat na Rpi, tak to hlavně nenechávej na standardní SD kartě. Ta ti možná nepřežije ani ten rok, když na ní budeš každou 1/4 hodinu zapisovat. Ale to už se tu řešilo hodněkrát.
-
Mna tam zarazila jedna vec a to, ze ta tabulka ma 121 stlpcov.
Niesom borec v SQL a normalizacii ale toto podla mna nieje dobre. Hlavne ked v tej tabulke budes mat vecsie mnozstvo dat a budes chciet riesit zlozitejsie SQL dotazy.
Porozmyslal by som nad upravou tabulky zo 121 stlpcov na 3 stlpce.
time_id | type | hodnota
-
Na ukládání naměřených dat nejsou relační databáze vhodné. Lepší je použít real time databázové systémy. Ty jsou uvnitř dělané jinak, nebo přímo nějaké řešení postavené pro ukládání dat ze senzorů. třeba TDMS.
-
Mna tam zarazila jedna vec a to, ze ta tabulka ma 121 stlpcov.
Niesom borec v SQL a normalizacii ale toto podla mna nieje dobre. Hlavne ked v tej tabulke budes mat vecsie mnozstvo dat a budes chciet riesit zlozitejsie SQL dotazy.
Porozmyslal by som nad upravou tabulky zo 121 stlpcov na 3 stlpce.
time_id | type | hodnota
antipatern
-
Na ukládání naměřených dat nejsou relační databáze vhodné. Lepší je použít real time databázové systémy. Ty jsou uvnitř dělané jinak, nebo přímo nějaké řešení postavené pro ukládání dat ze senzorů. třeba TDMS.
Jinak pro takovéto použití třeba influxdb.
-
Už to, že se vám v tabulce opakuje stejný vzor sloupců typeX a iX, je velmi podezřelé – ukazuje to, že máte pravděpodobně špatně navrženou strukturu tabulek. A když píšete, že typeX a iX tvoří nějakou dvojici a chcete hledat takové hodnoty iX, kde typeX má nějakou konkrétní hodnotu, je ten špatný návrh struktury jistota. Asi spíš chcete mít tabulku měření, typ, hodnota. A pokud chcete identifikovat i jednotlivá měření, dává smysl vedle toho mít tabulku měření, kde budete mít poznamenaný třeba čas měření, a na tuto tabulku se z tabulky výsledků měření jen odkážete.
-
Porozmyslal by som nad upravou tabulky zo 121 stlpcov na 3 stlpce.
time_id | type | hodnota
antipatern
Asi si to pletete s Entity-Attribute-Value antipattern. Ale IMHO to v daném případě antipattern není, alespoň pokud se ukládá do třetího sloupce stejná veličina nebo alespoň stejný datový typ.
-
Porozmyslal by som nad upravou tabulky zo 121 stlpcov na 3 stlpce.
time_id | type | hodnota
antipatern
Asi si to pletete s Entity-Attribute-Value antipattern. Ale IMHO to v daném případě antipattern není, alespoň pokud se ukládá do třetího sloupce stejná veličina nebo alespoň stejný datový typ.
Zalezi na tom, jak se to pouzije - pokud se budete ptat na jednu konkretni hodnotu, tak to neni antipattern bez ohledu na pouzity typ. Pokud se budete snazit vytvaret entitity selfjoinem a na nich pak delat dalsi operace, pak je to antipattern bez i kdyz pouzijete specialne typovane sloupce.
-
Porozmyslal by som nad upravou tabulky zo 121 stlpcov na 3 stlpce.
time_id | type | hodnota
antipatern
Asi si to pletete s Entity-Attribute-Value antipattern. Ale IMHO to v daném případě antipattern není, alespoň pokud se ukládá do třetího sloupce stejná veličina nebo alespoň stejný datový typ.
Zalezi na tom, jak se to pouzije - pokud se budete ptat na jednu konkretni hodnotu, tak to neni antipattern bez ohledu na pouzity typ. Pokud se budete snazit vytvaret entitity selfjoinem a na nich pak delat dalsi operace, pak je to antipattern bez i kdyz pouzijete specialne typovane sloupce.
Přece jde o měření v čase. Proč by to byl antipatern, joiny vůbec nepoužijete, pro zpracování údajů z měření budete počítat průměry, nebo odchylky, součty s GROUP BY type a omezením podmínkami na určitý časový interval, pro další zpracování to pak bude subselect.
Z hlediska modifikace je to jistě lepší datová struktura, než přidávat položky do SQL příkazů, když přidáte další čidlo. Když budete mít index na poli type, tak to bude i rychlé, prohledávat se bude jen index, a údaje se budou tahat z tabulky.
Z hlediska následného zpracování v php je spíše antipatern, pracovat s názvy polí jako s daty.
-
Už to, že se vám v tabulce opakuje stejný vzor sloupců typeX a iX, je velmi podezřelé – ukazuje to, že máte pravděpodobně špatně navrženou strukturu tabulek. A když píšete, že typeX a iX tvoří nějakou dvojici a chcete hledat takové hodnoty iX, kde typeX má nějakou konkrétní hodnotu, je ten špatný návrh struktury jistota. Asi spíš chcete mít tabulku měření, typ, hodnota. A pokud chcete identifikovat i jednotlivá měření, dává smysl vedle toho mít tabulku měření, kde budete mít poznamenaný třeba čas měření, a na tuto tabulku se z tabulky výsledků měření jen odkážete.
Vycházel jsem z toho, že script jenž měření zaznamenává vždy vygeneruje všech 60 měření (tj zaznamená 60 typu a 60 hodnot). K tomu potřebuji vědět čas kdy k měření došlo.
Aktuálně je vše v jedné tabulce, jelikož zápis je jeden dotaz na databázi. Export dat je typicky po 200 - 1000 hodinách, kde výsledkem je graf. Měří se po 15 minutách. K výsledkům se z 99% už není třeba vracet (zřejmě jednou za dva měsíce vyexportuji data starší než dva měsíce) a dotaz na databázi s CASE je jen proto, že vzorky se měří po skupinkách a pokud někdo zatrhne skupinky dvě a jedna je tam 500 hodin a druhá 200 tak by se vracela data z předchozí skupiny jenž tam byla před 200 hodinami.
Tedy dotaz na export dat se dělá max jednou za několik dní. Do začátku mě napadlo mít tabulku id, typ a proud pro každou pozici s tím že id by byl čas od prvního spuštění testeru inkrementovaný po 15 min. tj id = 1 by bylo 3.3. 12:00 a id = 2 by bylo 3.3. 12:15. Výpočetní složitost exportovaných dat mi přišla ale větší než to dělat takto - tedy snadno čitelně pro lidský zrak. Druhá myšlenka byla uchovávat pouze proud a typ určovat z tabulky typ vzorku, pozice, čas vložení, čas vyjmutí.
Veškeré ale mnou vymyšlené možnosti mi přišli příliš zatěžující RPI při zpracování a jejich benefit sporadický vzhledem k praktickému nasazení.
-
Na ukládání naměřených dat nejsou relační databáze vhodné. Lepší je použít real time databázové systémy. Ty jsou uvnitř dělané jinak, nebo přímo nějaké řešení postavené pro ukládání dat ze senzorů. třeba TDMS.
Jinak pro takovéto použití třeba influxdb.
Děkuji za typ - nastuduji
-
Ještě doplním, že jestli chceš mysql provozovat na Rpi, tak to hlavně nenechávej na standardní SD kartě. Ta ti možná nepřežije ani ten rok, když na ní budeš každou 1/4 hodinu zapisovat. Ale to už se tu řešilo hodněkrát.
Děkuji za typ - přestěhuji na USB