Arduino MEGA i BLYNK, LCD odchodzi do lamusa...

[SOYER]

zdecydowanie 10 minutowy. Raz, że Arduino może nadal wysyłać do BLYNKa co minutę, a do RPi co 10 min, a dwa, że ESP dane z czujnika jakości powietrza i tak wysyła również co 10 min, trzy wolałbym też uniknąć dodatkowego HDD... 

wprawdzie dalej nie widzę sensu tak dokładnych danych historycznych, ale jak tak jest lepiej... 

[ethanak]

2 minuty temu, SOYER napisał:

wprawdzie dalej nie widzę sensu tak dokładnych danych historycznych, ale jak tak jest lepiej... 

Dzisiaj nie widzisz a za miesiąc się wkurzysz, bo będziesz chciał sprawdzić o której to sąsiad w zeszły wtorek oponę w piecu spalił...

Poza tym nie pisałem że tak jest "lepiej" - tak jest prościej. Nie ma potrzeby stosowania jakichś dodatkowych aplikacji i fafnastu dodatkowych tabel, wszystko jest elegancko umieszczone w jednej najprostszej z możliwych, a przy okazji masz możliwość sięgnięcia wstecz (jak mówiłem, dzisiaj nie chcesz a pojutrze będziesz chciał).

To co, zrób taką śliczna tabelkę i będziemy sobie dalej kombinować?

[SOYER]

Czyli co? W poziomie te 13 czujników, kolumny, ok, ale w jaki sposób zrobić te wiersze. Pewnie mają się same dodawać z każdym odczytem, si? 

[ethanak]

A jak inaczej? @Treker Ci nie wspominał że masz podstawy kwerend opanować? A gdybyś miał taką sztywną tabelkę jak zaprojektowałeś to byś pytał, czy dane się będą same uaktualniać za każdym odczytem?

A ja bym prosił o odrobinkę pomyślenia czym jest tabela w bazie danych... a przede wszystkim przestań myśleć kategoriami wiersz/kolumna bo skojarzenie z Excelem samo się nasuwa a to niestety zupełnie coś innego.

No bo jeśli nie rozumiesz czym jest tabela (a tego nie podejmuję się wytłumaczyć) to jak chcesz pisać jakiekolwiek programy na owych tabelach operujące...

 

[SOYER]

8 minut temu, ethanak napisał:

No bo jeśli nie rozumiesz czym jest tabela (a tego nie podejmuję się wytłumaczyć) to jak chcesz pisać jakiekolwiek programy na owych tabelach operujące...

Więc proszę kogoś o wytłumaczenie różnic. 

Dla mnie to coś takiego co widzę w phpMyAdmin... tabelka... 

Jak inaczej na to spojrzeć?? 

Co masz na myśli... 

[ethanak]

OK spróbujmy.

W phpMyAdminie nie widzisz tabeli jako takiej tylko wynik jakiegoś zapytania na tej tabeli operującego (np. "Pokaż wartości wszystkich pól w kolejności jakiejśtam").
Wyobraź sobie tabelę w bazie danych jako zbiór nieuporządkowanych rekordów (nie żadnych wierszy, bo to by sugerowało istnienie jakiejś kolejności) zawierających pola (nie kolumny) określonego typu. Dopiero wynik kwerendy SELECT tworzy tabeloida zawierającego kolumny i wiersze - poprzez przyporządkowanie konkretnych pól (czy funkcji na owych polach operujących) do kolumn i określenie kolejności, w jakiej owe wiersze będą tworzone.

Coś to wyjaśniło?

[SOYER]

no tak, baza to jeden wielki burdel, dopiero kwerenda robi tam porządek... 

[ethanak]

No - niezupełnie burdel. Rekordy w bazie mogą być zaindeksowane (jak w naszym przypadku) - czyli wprowadzony zostaje dodatkowy porządek. Istnieją powiązania między tabelami, wiele czynności jest wykonywanych automatycznie na owych powiązanych tabelach, ogólnie panuje tam większy porządek niż w tabelce Excela, gdzie jak wstawisz wiersz między trzecim a czwartym to stodwudziestyósmy przestaje by stodwudziestymósmym (a przecież właśnie poprzez numery wierszy w Excelu się do nich odwołujemy)

Brak jedynej słusznej i niezmiennej metody sortowania (czyli określenia "naturalnej" kolejności rekordów) to przecież nie jest kwestia nieporządku, a elastyczności. Zresztą... co jeśli pobierasz dane z kilku tabel jednocześnie? Jaka ma być ta "naturalna" metoda? Według kolejności wstawienia? Przy katalogu w bibliotece raczej niewiele by to dało. Alfabetycznie według jakiegoś pola? Jakiego? Nawet w bibliotece możesz sortować według autora, tytułu, numeru ISBN, daty wydania (która z datą wprowadzenia do systemu, a więc i z kolejnością nie ma wiele wspólnego)  czy czegokolwiek. Nie może takiej metody być - Ty ją masz określić poprzez klauzulę ORDER BY, bo inaczej dostaniesz dane w takiej kolejności w jakiej siedzą na dysku (czyli nie mającej nic wspólnego z jakimkolwiek sposobem sortowania).

Wiele języków (choć akurat nie C i nie PHP czy JavaScript) ma typ danych "set" - właśnie nieuporządkowany zbiór wartości. Tyle że każdy element w takim zbiorze ma jakieś tam własności, możemy stworzyć kryteria według których będziemy owe elementy ze zbioru wybierać i na końcu (o ile jest nam to potrzebne, bo przecież nie zawsze) wybrać kolejność, w jakiej owe elementy będą przetwarzane.

No i gdzie tu burdel?

 

[SOYER]

No ni ma. 

Takw sumie to by wystarczyło zrobić szkielet, a później z każdym odebraniem danych tworzyć dalszy ciąg "tabelki". Jest zdaje się takie coś jak CREATE... 

[ethanak]

Że co?

Przestań zgadywać tylko zerknij do jakiejś najprostszej dokumentacji SQL-a albo innego kursu. Masz do dyspozycji:

a) kurs Zelenta - co prawda uczenie się operacji na bazach danych z filmików na jutubie uważam za wielce chory pomysł, ale cóż, DGCC...

b) Naucz się sql w 60 minut - nie bardzo mi się chce wierzyć, ale być może...

c) Kurs sql  na Sqlpedii. Co prawda omawia wyłącznie wyciąganie informacji z bazy (czyli SELECT z przyległościami) ale za to bardzo drobiazgowo.

Dwa ostatnie omawiają język SQL a nie konkretny dialekt, konkretnie o MySQL-u masz u Zelenta. Niestety, większość materiałów jest po angielsku dlatego nie kieruję Ciebie od razu na dev.mysql.com.

I proszę, zanim zaczniesz jakieś herezje wypisywać zapoznaj się przynajmniej z tym drugim... 60 minut chyba możesz poświęcić

[SOYER]

ok wczoraj coś czytałem, i tak mi się dzisiaj skojarzyło... createm to se mogę nową tabelę zrobić... 

to co, nie wolno mi tej tabeli zrobić "graficznie" w phpMyAdmin? 

przecież to tylko 12 czujników... 

15 pozycji: data, czas i 13 czujników... 

[ethanak]

Ależ możesz sobie zrobić graficznie, w końcu po to jest phpMyAdmin i to tylko interfejs do "create table".

I nie 15 pozycji a 14 - jeśli zrobisz oddzielnie datę i czas to potem będziesz kombinował jak koń pod górkę. Istnieje typ datetime, tego się trzymaj, zrób dokładnie tak jak Ci pokazałem (czyli primary key i default current_timestamp), jeśli nie wiesz dlaczego to spróbuj jednak przeczytać po angielsku: https://dev.mysql.com/doc/refman/5.7/en/data-type-defaults.html - a przynajmniej pierwszą (tę krótszą) część "handling of explicit values".

Tak przy okazji sprawdziłem - translator Googla bardzo prawidłowo to przetłumaczył, tak że dalszych argumentów o słabej znajomości angielskiego nie przyjmuję.

Jakbyś się zastanawiał dlaczego datetime a nie timestamp to później wyjaśnię, w każdym razie przyjmij że do zapisu tego typu danych (pozycja w czasie konkretnego zdarzenia) służy właśnie typ datetime.

 

 

[SOYER]

-- phpMyAdmin SQL Dump
-- version 4.6.6deb4
-- https://www.phpmyadmin.net/
--
-- Host: localhost:3306
-- Czas generowania: 29 Sty 2019, 00:38
-- Wersja serwera: 10.1.37-MariaDB-0+deb9u1
-- Wersja PHP: 7.0.33-0+deb9u1

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";


/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;

--
-- Baza danych: `meteokryry`
--

-- --------------------------------------------------------

--
-- Struktura tabeli dla tabeli `meteoTabela`
--

CREATE TABLE `meteoTabela` (
  `id` int(11) NOT NULL,
  `czas` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `tempKuchnia` int(11) NOT NULL,
  `wilgKuchnia` int(11) NOT NULL,
  `tempCO` int(11) NOT NULL,
  `tempStrych` int(11) NOT NULL,
  `tempPiwnica` int(11) NOT NULL,
  `tempZew` int(11) NOT NULL,
  `wilgZew` int(11) NOT NULL,
  `tempSlonce` int(11) NOT NULL,
  `tempGrunt` int(11) NOT NULL,
  `cisnienie` int(11) NOT NULL,
  `pm1` int(11) NOT NULL,
  `pm2` int(11) NOT NULL,
  `pm10` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

--
-- Indeksy dla zrzutów tabel
--

--
-- Indexes for table `meteoTabela`
--
ALTER TABLE `meteoTabela`
  ADD PRIMARY KEY (`id`);

--
-- AUTO_INCREMENT for dumped tables
--

--
-- AUTO_INCREMENT dla tabeli `meteoTabela`
--
ALTER TABLE `meteoTabela`
  MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

 

 

Dołożyłem jescze id, żeby móc sprawdzić ile zapisów jest w bazie, choć bez tego też pewnie da się to policzyć, tak?

Może być ta tabela?

P.S. ten link do tego wegańskiego portalu bardzo ciekawy, 60-min kurs bardzo ogólny, to już wolę W3school, mają nawet fajne apki na telefon.

Jednak najciekawszy był ten artykuł: https://www.sqlpedia.pl/wszystko-o-null/, ciekawa sprawa ten null...:-)

Edytowano Styczeń 29, 2019 przez SOYER

[ethanak]

Nie może być.

Wszelkie sekwencje typu AUTO_INCREMENT stosuje się nie w celu jakiegokolwiek zliczania (bo do tego służą funkcje zliczające różne rzeczy), a do zapewnienia unikalnej wartości w każdym rekordzie. Po to jest wtedy PRIMARY KEY, aby móc szybko znaleźć rekord o danej wartości pola.

Przecie jeśli stworzysz kiedyś tę aplikację kompaktującą dane w tabeli - będzie ona usuwać z niej starsze rekordy, czyli wartość id będzie zupełnie z czapy.

I spójrz teraz co zrobiłeś (bo chciałeś być mądrzejszy):

W mojej wersji unikatem był czas zapisu i na nim był założony indeks. Miało to spowodować jak najszybsze znalezienie rekordów odpowiadających zapytaniu - czyli na przykład najnowszego rekordu (ten cały ORDER BY czas DESC LIMIT 1). W takiej sytuacji pobranie ostatniej wartości wymagałoby odczytania z bazy jednego - tego najnowszego - rekordu.

Ty oczywiście musiałeś wprowadzić jakieś sztuczki z AUTO_INCREMENT. Wskutek tego indeks został założony na polu, którego nigdy nie używasz, a do znalezienia najnowszej wartości trzeba przeszukać wszystkie rekordy.

Oczywiście zaraz usłyszę że można dać ORDER BY id. Tak, można. Ale jeśli poprosisz o dane z ostatnich 24 godzin na przykład już tego za pomocą id nie zrobisz. Wiem, można próbować wiedząc co ile czasu wykonywane są zapisy do bazy próbować obliczyć sobie ów id w aplikacji. Tyle że wystarczy, aby z jakichś powodów dane przestały spływać (np. coś przerabiasz albo zwyczajnie elektrownia prąd wyłączyła) i możesz sobie liczyć najwyżej na przypadek.

Czy to jasne?

Aha, jakbyś pytał to do liczenia rekordów służy funkcja COUNT, np:

SELECT COUNT(*) FROM METEO;

albo ciekawsze:

SELECT COUNT(*) FROM METEO WHERE tempZewn < 0;

 

 

Edytowano Styczeń 29, 2019 przez ethanak

[SOYER]

Jasne i sensowne. Szczególnie fragment o tym jak wywalę część rekordów i wtedy id zupełnie traci sens. O tym nie pomyślałem. 

ID wylatuje.