MySQL: jak postavit správný dotaz na databázi

[Jan Kolář]

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

[Reklama]

[Krocan]

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;

[Krocan]

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;

[lobo]

preco taketo veci neriesis na aplikacnej urovni?
matlat nejaku logiku do SQL s milionom CASE a WHERE je cesta do pekla

[Jan Kolář]

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

[Reklama]

[Petr]

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ě.

[Petr]

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.

[Ondro]

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

[trr]

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.

[ivoszz]

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

[ivoszz]

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.

[Filip Jirsák]

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.

[Ondrej Nemecek]

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.

[PavelS]

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.

[Ivan Nový]

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.