SQL - návrh databáze - TYP
- pavel1tu
- Příspěvky: 2054
- Registrován: 26 říj 2017, 08:28
- Reputation: 0
- Bydliště: Trutnov
- Kontaktovat uživatele:
SQL - návrh databáze - TYP
Je tu někdo přes SQL databáze ?
Vytvářím novou databázi pro meteostanici,
budu importovat data z programu Cumulus asi za 15 let ?!
U každého řádku databáze se zadává jaký TYP to bude, já používám nevím proč FLOAT, asi že je to v příkladech.
Vyplatí se to vytvořit jakoby "na míru", třeba teplotu místo FLOAT DECIMAL(3,2) atd. ?
Je to obrovský objem dat (pro BananaPi), tak pokud to bude lepší, pohraji si s tím - ukládáme asi 30 položek
děkuji za názory
Vytvářím novou databázi pro meteostanici,
budu importovat data z programu Cumulus asi za 15 let ?!
U každého řádku databáze se zadává jaký TYP to bude, já používám nevím proč FLOAT, asi že je to v příkladech.
Vyplatí se to vytvořit jakoby "na míru", třeba teplotu místo FLOAT DECIMAL(3,2) atd. ?
Je to obrovský objem dat (pro BananaPi), tak pokud to bude lepší, pohraji si s tím - ukládáme asi 30 položek
děkuji za názory
UNO, NANO, Mikro, PRO mini, DUE, ESP32S2, RPi PICO
Pavel1TU
"Správně napsaný kod lze číst jako knihu"
Pavel1TU
"Správně napsaný kod lze číst jako knihu"
Re: SQL - návrh databáze - TYP
Já to spíš pochopil tak, že myslíš sloupec. Do řádků se pak skládají data. Pokud jsi si 100% jist, že do ono sloupce nikdy nebudeš chtít vložit nic jiného než to co tam potřebuješ, tak mu dej ten správný datový typ akorát tak nadimenzovaný. Ušetří to místo, které ta databáze pak zabere.
Pokud si chceš nechat nějaký prostor pro manévrování, stím že tam třeba budeš chtít uložit i někdy nějaký text ... nvm např ERR, jako chybovou hlášku rozlišitelnou od 0, FALSE ... tak já bych použil dostatečně nadimenzovaný varchar.To desetiný číslo se tam uloží jako prostě text ... takže čárka může lítat jak chce, jdou tam nacpat i znaky atd... Až si ty data potom z tý databáze vyžádáš nějakým klientem, tak si sám určíš jestli se k těm datům budeš chovat jako k float, nebo string.
Pokud si chceš nechat nějaký prostor pro manévrování, stím že tam třeba budeš chtít uložit i někdy nějaký text ... nvm např ERR, jako chybovou hlášku rozlišitelnou od 0, FALSE ... tak já bych použil dostatečně nadimenzovaný varchar.To desetiný číslo se tam uloží jako prostě text ... takže čárka může lítat jak chce, jdou tam nacpat i znaky atd... Až si ty data potom z tý databáze vyžádáš nějakým klientem, tak si sám určíš jestli se k těm datům budeš chovat jako k float, nebo string.
- pavel1tu
- Příspěvky: 2054
- Registrován: 26 říj 2017, 08:28
- Reputation: 0
- Bydliště: Trutnov
- Kontaktovat uživatele:
Re: SQL - návrh databáze - TYP
JJ myslel jsem sloupce.
byl to opruz ale vyzkoušel jsem to - buď všude FLOAT nebo u celých čísel INT, u čísel pod 255 TINYINT a tak dále.
za skoro 15 let dat to po přechrochtání SQL dotazem zabírá 1/4 místa nebo tak nějak, což je super
byl to opruz ale vyzkoušel jsem to - buď všude FLOAT nebo u celých čísel INT, u čísel pod 255 TINYINT a tak dále.
za skoro 15 let dat to po přechrochtání SQL dotazem zabírá 1/4 místa nebo tak nějak, což je super
UNO, NANO, Mikro, PRO mini, DUE, ESP32S2, RPi PICO
Pavel1TU
"Správně napsaný kod lze číst jako knihu"
Pavel1TU
"Správně napsaný kod lze číst jako knihu"
Re: SQL - návrh databáze - TYP
Ono to nemá vliv jen velikost samotné databáze, ale s rostoucím počtem záznamů i na rychlost její odezvy. Díky správným datovým typům se pak mohou některé sloupce oindexovat, čímž se urychlí výběr dat z db.
Float není úplně snadní správně použít, lépe je DECIMAL a specifikovat, kolik cifer bude požadováno za des. čárkou.
Nějaké případné chybové stavy rozhodně do tohoto sloupce nepatří (a nedejbože kvůli tomu měnit typ na varchar - tím si člověk odpráskne možnosti používat matematické agregační funkce). Pokud stanice může generovat chybový stav, tak buď: je evidovat v samostatném sloupci, nebo v samostatné tabulce...
Float není úplně snadní správně použít, lépe je DECIMAL a specifikovat, kolik cifer bude požadováno za des. čárkou.
Nějaké případné chybové stavy rozhodně do tohoto sloupce nepatří (a nedejbože kvůli tomu měnit typ na varchar - tím si člověk odpráskne možnosti používat matematické agregační funkce). Pokud stanice může generovat chybový stav, tak buď: je evidovat v samostatném sloupci, nebo v samostatné tabulce...
- pavel1tu
- Příspěvky: 2054
- Registrován: 26 říj 2017, 08:28
- Reputation: 0
- Bydliště: Trutnov
- Kontaktovat uživatele:
Re: SQL - návrh databáze - TYP
Děkuji,
dobrý podnět - udělám kody chyb číslem, podle bitové váhy kdy každý modul bude mít svoji chybu
vše co má desetinná místa jsem dal na DECIMAL, trochu to učesal a opět 5% úspory
testnul jsem na obou databázích i rychlost generování dat (statistiky za určitý měsíc) a je to skoro o 1/3 rychlejší (BananaPi dostal záhul)
dobrý podnět - udělám kody chyb číslem, podle bitové váhy kdy každý modul bude mít svoji chybu
vše co má desetinná místa jsem dal na DECIMAL, trochu to učesal a opět 5% úspory
testnul jsem na obou databázích i rychlost generování dat (statistiky za určitý měsíc) a je to skoro o 1/3 rychlejší (BananaPi dostal záhul)
UNO, NANO, Mikro, PRO mini, DUE, ESP32S2, RPi PICO
Pavel1TU
"Správně napsaný kod lze číst jako knihu"
Pavel1TU
"Správně napsaný kod lze číst jako knihu"
Re: SQL - návrh databáze - TYP
Asi bych to viděl nějak takto:
S tím, že nad sloupcem Nastala_chyba by byl index,
Chyba_text by byl NULLový.
Když budeš chtít vytáhnout všechny záznamy, kde nedošlo k chybě (a dále s nimi počítat), napíšeš si do dotazu WHERE Nastala_chyba=0.
Index nad TINYINT bude nejrychlejší. Nevím, co máš za DB, PostgreSQL třeba umí i BIT, MySQL tuším stále ne.
Kód: Vybrat vše
+-----------+---------------+-----------------------+-----------------+
| ID | Teplota | Nastala_chyba | Chyba_text |
+-----------+---------------+-----------------------+-----------------+
| UNINT | DECIMAL | TINYINT | VARCHAR |
+-----------+---------------+-----------------------+-----------------+
Chyba_text by byl NULLový.
Když budeš chtít vytáhnout všechny záznamy, kde nedošlo k chybě (a dále s nimi počítat), napíšeš si do dotazu WHERE Nastala_chyba=0.
Index nad TINYINT bude nejrychlejší. Nevím, co máš za DB, PostgreSQL třeba umí i BIT, MySQL tuším stále ne.
- pavel1tu
- Příspěvky: 2054
- Registrován: 26 říj 2017, 08:28
- Reputation: 0
- Bydliště: Trutnov
- Kontaktovat uživatele:
Re: SQL - návrh databáze - TYP
Mám MariaDB
chyby a alarmové stavy budou ve druhé tabulce databáze
bude se podle těch záznamů ovládat posílání emailů a SMS
chyby a alarmové stavy budou ve druhé tabulce databáze
bude se podle těch záznamů ovládat posílání emailů a SMS
UNO, NANO, Mikro, PRO mini, DUE, ESP32S2, RPi PICO
Pavel1TU
"Správně napsaný kod lze číst jako knihu"
Pavel1TU
"Správně napsaný kod lze číst jako knihu"
Kdo je online
Uživatelé prohlížející si toto fórum: Žádní registrovaní uživatelé a 1 host