Fórum Root.cz
Hlavní témata => Server => Téma založeno: Venca 20. 10. 2017, 20:22:19
-
Zdravím, už docela dost let se živím programováním a v rámci rozšiřování obzorů bych se chtěl začít věnovat databázím a obecně SQL jazyku. Kdysi dávno jsem se s ním setkal jen v základech, takže jsem prakticky začátečník. Jde mi o to naučit a dozvědět se co nejvíc o SQL z hlediska programování, ale i naučit se správné návyky při tvorbě tabulek a databází.
Našel by se někdo, kdo by mohl doporučit nějaké stránky, tutoriály, učebnice? V češtině, v el. podobě, ideálně zdarma? Na netu se toho válí spousty, google použít umím, ale ten už mi neřekne nic o kvalitě...
Díky za každý tip nebo radu.
-
Zdravím, už docela dost let se živím programováním a v rámci rozšiřování obzorů bych se chtěl začít věnovat databázím a obecně SQL jazyku. Kdysi dávno jsem se s ním setkal jen v základech, takže jsem prakticky začátečník. Jde mi o to naučit a dozvědět se co nejvíc o SQL z hlediska programování, ale i naučit se správné návyky při tvorbě tabulek a databází.
Našel by se někdo, kdo by mohl doporučit nějaké stránky, tutoriály, učebnice? V češtině, v el. podobě, ideálně zdarma? Na netu se toho válí spousty, google použít umím, ale ten už mi neřekne nic o kvalitě...
Díky za každý tip nebo radu.
A kterému SQL byste se chtěl věnovat? Jazyk mají všechny podobný, ale implementace a tím pádem i nutné návyky programátorů se pak liší.
-
Jsou mezi tím nějaké zásadní rozdíly? O konkrétní implementaci jsem nepřemýšlel...když už, tak asi MSSQL, ale klidně začnu i s Firebird, MySQL, SQLite...
-
Jsou mezi tím nějaké zásadní rozdíly? O konkrétní implementaci jsem nepřemýšlel...když už, tak asi MSSQL, ale klidně začnu i s Firebird, MySQL, SQLite...
Ok. Na MySQL a SQLite se vykašlete, obojí jsou parodie na SQL a na nich si vytvoříte leda zlozvyky.
MSSQL nebo Firebird nebo Oracle nebo PostgreSQL bych považoval za fajn pro učení.
Máte nějaký konkrétní projekt, který chcete zpracovat?
-
... docela dost let se živím programováním a v rámci rozšiřování obzorů bych se chtěl začít věnovat databázím a obecně SQL jazyku ...
V akom jazyku programujes ?
-
Na MySQL a SQLite se vykašlete, obojí jsou parodie na SQL a na nich si vytvoříte leda zlozvyky.
SQLite má téměř úplnou implementaci jazyka SQL. Jaké zlozvyky si na něm vytvoří?
Jazyk MySQL je sice horší, ale zato hojně rozšířený.
-
SQLite má téměř úplnou implementaci jazyka SQL. Jaké zlozvyky si na něm vytvoří?
Jazyk MySQL je sice horší, ale zato hojně rozšířený.
Ani jedno není SQL v pravém slova smyslu, a SQL v názvu mají víceméně omylem, resp. jen kvůli tomu, že jazyk vypadá stejně.
-
Z vyjmenovaných databází považuji za nejvhodnější pro uvedený účel PostgreSQL.
-
... docela dost let se živím programováním a v rámci rozšiřování obzorů bych se chtěl začít věnovat databázím a obecně SQL jazyku ...
V akom jazyku programujes ?
Java
-
Nejsou jen SQL databáze, jsou i NoSQL databáze.
https://cs.wikipedia.org/wiki/NoSQL
Dost často jsou - pro někoho možná překvapivě - jednak výkonnější pro určité typy dotazů a nebo prostě jen vhodnější.
https://www.zdrojak.cz/serialy/nerelacni-databaze/
Jsou případy, kdy případy použití klasické SQL databáze podobá snaze zašroubovat šroubek pomocí kombinaček.
Nic proti kleštím a kombinačkám už vůbec, ostatně jak jinak chcete vytrhat zuby tomu, kdo o vás prohlásil, že jste tak trochu excentrik. Ale v tomhle případě se může jednat o to, že by použití takových kleští bylo jako si ty zuby vytrhat sobě. Někdy prostě použijete NoSQL databázi a všechno jde samo, jednoduše, žádná abstrakce, milé, snadné, rychlé, přehledné, čitelné.
-
tak si najdi nejake priklady na pouzitie jdbc.
open connection, close connection
open resultset, close resultset
..etc
ked sa chec naucit zaklady sql mozes si kupit napr https://www.alza.sk/media/naucte-sa-sql-za-28-dni-d2367043.htm?o=4
Mylim, ze to je tak asi jedina vseobecna kniha pocesky o SQL, alebo si najdi nejake tutorialy pre konkretnudatabazu na webe.
-
Nejsou jen SQL databáze, jsou i NoSQL databáze.
https://cs.wikipedia.org/wiki/NoSQL
Dost často jsou - pro někoho možná překvapivě - jednak výkonnější pro určité typy dotazů a nebo prostě jen vhodnější.
Pokud by někdo chtěl degradovat SQL databázi na KVS, tak bych mu také doporučil výběr z NoSQL. S většinou z nich bude mnohem spokojenější než s databázemi SQL.
-
Relacni databaze: Codd, Darwen & Date. Ti vysvetluji, jak by se to melo delat. Pak je milion praktickych implementaci SQL, ktere jsou v ruznych smerech domrvene. Postgres je asi nejprijemnejsi (open-source, neni to mamut ale ma to dost funkci a slusny vykon), specializovat se jde podle potreby.
-
degradovat SQL databázi
Často není víc potřeba.
A poměrně často je to naprosto ideální řešení.
Příkladem budiž webový e-shop, matlat data do MySQL, řešit složitou strukturu...
Databáze jsou nástroje, když máš dobrý nástroj, jde práce rychle od ruky.
Člověk si zvykne používat kladivo, můžeš se s ním naučit i sádrovat, ale špachtlí to jde prostě líp.
Mimochodem, já bych začal právě tou NoSQL databází, protože se potupně dostane k nástrojům, které se snaží z SQL databáze udělat NoSQL databázi.
-
Zdravím, už docela dost let se živím programováním a v rámci rozšiřování obzorů bych se chtěl začít věnovat databázím a obecně SQL jazyku. Kdysi dávno jsem se s ním setkal jen v základech, takže jsem prakticky začátečník. Jde mi o to naučit a dozvědět se co nejvíc o SQL z hlediska programování, ale i naučit se správné návyky při tvorbě tabulek a databází.
Našel by se někdo, kdo by mohl doporučit nějaké stránky, tutoriály, učebnice? V češtině, v el. podobě, ideálně zdarma? Na netu se toho válí spousty, google použít umím, ale ten už mi neřekne nic o kvalitě...
Díky za každý tip nebo radu.
SQL se dá uchopit jednoduše i složitě. V tom jednoduchém případě to lze opravdu jednoduše. Pro psaní dotazů je zásadní pochopení outer JOINů a agregace - ostatní je primitivní. Pro design je pak důležité pochopení tzv normálních forem - zásadní jsou první tři a ty pokud možno v návrhu respektovat. V podstatě existují dvě chyby, které je dobré nedělat při návrhu - emulace dědičnosti a entity attribute value tabulky. Můžete použít moje materiály, které používám na školení SQL: http://www.pgsql.cz/skoleni/skoleni_sql.zip
Pro základy SQL je jedno, kterou SQL databázi použijete - důležité je nedělat z toho vědu. Jakmile člověk SQL umí, tak jej umí na SQLite, MySQL, Oracle, Postgresu, ... Samozřejmě, že tam jsou určité rozdíly, ale základ je stejný - to je jedna z výhod SQL (je to něco jako pravidla silničního provozu - téměř všude jsou stejná. Pak se samozřejmě musím přizpůsobit jestli jedu s osobákem nebo dodávkou nebo kamiónem). Použijte takovou databázi, do které se umíte přihlásit, a do které umíte poslat dotaz, a podívat se na výsledek.
-
degradovat SQL databázi
Často není víc potřeba.
A poměrně často je to naprosto ideální řešení.
Příkladem budiž webový e-shop, matlat data do MySQL, řešit složitou strukturu...
Databáze jsou nástroje, když máš dobrý nástroj, jde práce rychle od ruky.
Člověk si zvykne používat kladivo, můžeš se s ním naučit i sádrovat, ale špachtlí to jde prostě líp.
Mimochodem, já bych začal právě tou NoSQL databází, protože se potupně dostane k nástrojům, které se snaží z SQL databáze udělat NoSQL databázi.
Každá technologie má svůj use-case. Pokud se databáze používá pouze jako storage a ještě netransakční, pak NoSQL databáze mohou excelovat. V okamžiku, kdy se začne mluvit o konzistenci dat, zabezpečení dat, reportingu, pak naopak excelují SQL databáze, kde se tato funkcionalita implementuje 30 let. Na netu je dneska hromada blogů, kdy se firmy vrátily k SQL z důvodu většího výkonu, ztrát dat v NoSQL, případně pracnosti reportingu nad NoSQL a slabému výkonu. Samozřejmě, že jsou data, kde nepotřebuji silnou konzistenci (a těch je celá řada), jsou data nad kterými téměř nikdy nebudu dělat reporty. Pak je na místě uvažovat o NoSQL. V jiném případě určitě SQL, případně pro specifickou zátěž NewSQL.
-
... No a pak člověk zjistí, že ty NoSQL se dotazují také přes SQL jazyk, že dospělé databáze se naučili s nimi transparentně na pozadí komunikovat a že kontroly konzistence, integrity a další chujoviny jsou najednou také možné.
Abys mohl jít na pohovor a říct, že umíš SQL za mě potřebuješ znát obecnou teorii o práci s daty, normalizacích a něco málo z teorie čísel a umět designovat databázové tabulky. Poté musíš znát konkrétní implementaci SQL v konkrétní db, jsou v tom neskutečné rozdíly, co funguje na jedné, nefunguje na druhé a např. obyčejným where column is null dokážeš položit teradatu.
Dokumentace SQL od jednotlivých db nejsou špatnou volbou ke studiu. Osobně mě docela zaujala knížka SQL Cookbook od Anthony Molinaro nebo Database Design od Hernandeze. Řada vysokých škol má materiály a skripta ohledně databází dostupné přes google, zkus si pohledat.
Na trhu jsou dobře hodnocení lidé kolem MSSQL a Oracle, u něho jeho PL/SQL je už programovací jazyk a s tím se neztratíš, stojí na tom půlka korporátů.
Těch cest jsou ale tisíce a dokud neřekneš kam chceš směrovat a co chceš třeba za dva roky dokázat, těžko se ti dá poradit něco konkrétního.
-
Těch cest jsou ale tisíce a dokud neřekneš kam chceš směrovat a co chceš třeba za dva roky dokázat, těžko se ti dá poradit něco konkrétního.
Proto můj dotaz na začátku byl na to, jestli má tazatel nějaký projekt, na kterém to chce zkoušet. Podle toho by se dala tipnout technologie nebo use case, který bude tazateli nejblíž.
-
A kterému SQL byste se chtěl věnovat? Jazyk mají všechny podobný, ale implementace a tím pádem i nutné návyky programátorů se pak liší.
Aniž bych chtěl slovíčkařit, SQL je defacto jen jedno. V čem se to liší jsou různé procedurální nástavby jako PLSQL (Oracle), T-SQL (MS), atd... Ale to si každý na svém písečku dodělává to co mu ve vanila SQL chybí.
SQL se dá uchopit jednoduše i složitě. V tom jednoduchém případě to lze opravdu jednoduše. Pro psaní dotazů je zásadní pochopení outer JOINů a agregace - ostatní je primitivní. Pro design je pak důležité pochopení tzv normálních forem - zásadní jsou první tři a ty pokud možno v návrhu respektovat. V podstatě existují dvě chyby, které je dobré nedělat při návrhu - emulace dědičnosti a entity attribute value tabulky. Můžete použít moje materiály, které používám na školení SQL: http://www.pgsql.cz/skoleni/skoleni_sql.zip
Pro základy SQL je jedno, kterou SQL databázi použijete - důležité je nedělat z toho vědu. Jakmile člověk SQL umí, tak jej umí na SQLite, MySQL, Oracle, Postgresu, ... Samozřejmě, že tam jsou určité rozdíly, ale základ je stejný - to je jedna z výhod SQL (je to něco jako pravidla silničního provozu - téměř všude jsou stejná. Pak se samozřejmě musím přizpůsobit jestli jedu s osobákem nebo dodávkou nebo kamiónem). Použijte takovou databázi, do které se umíte přihlásit, a do které umíte poslat dotaz, a podívat se na výsledek.
Přesně tak. Důležité je, k čemu to chce člověk používat. Základ je naučit se SELECT + spojování a aggregační funkce. Pak umíte SQL. Podle toho jestli chcete dělat DBA, BI, ETL atd... se pak dá pak pokračovat dál. Není to žádné raketové inženýrství. Učí se to poměrně dobře ;D
A kterému SQL byste se chtěl věnovat? Jazyk mají všechny podobný, ale implementace a tím pádem i nutné návyky programátorů se pak liší.
[/quote]
-
A kterému SQL byste se chtěl věnovat? Jazyk mají všechny podobný, ale implementace a tím pádem i nutné návyky programátorů se pak liší.
Aniž bych chtěl slovíčkařit, SQL je defacto jen jedno. V čem se to liší jsou různé procedurální nástavby jako PLSQL (Oracle), T-SQL (MS), atd... Ale to si každý na svém písečku dodělává to co mu ve vanila SQL chybí.
[/quote]
S tím bych nesouhlasil. Pro optimální využití vlastností té či oné databáze musíte znát její specifika i to, na co je optimalizovaná. Např. MSSQL má rádo subselecty, PostgreSQL je neumí optimalizovat. Zase umí lépe optimalizovat joiny. Složité dotazy v každé databázi budete psát jinak, byť je jazyk prakticky stejný.
Pokud ale databázi používáte jen na dotazy key-value (KVS), pak je lepší zvolit mysql nebo nějaké nosql. Ale to je skill, který ovládá kdekdo, na to se asi tazatel neptá.
-
Na Stanforde je celkom fajn kurz a k tomu zadarmo (https://lagunita.stanford.edu/courses/Home/Databases/Engineering/about)
Prejdes od teorii k praxi, od relacnej algebry k CTE v SQL.
-
Dávam do pozornosti online kurz na Stanfordovej univerzite (je zdarma), robil som to pred niekoľkými rokmi, keď to spúšťali prvý krát. Väčšia časť kurzu bola o relačných databázach a SQL, pri konci aj niečo o ukladaní dát do XML a JSON. Keď som to robil, bol to kurz s testami v určitom termíne a kurz mal rovnaký rozsah, ako to, čo učia na Stanforde (a zrejme na ďalších vysokých školách - autorka kurzu je spoluautorka jednej z niekoľkých učebníc, ktoré na amerických univerzitách odporúčajú k úvodným kurzom).
Teraz bude rozsah asi podobný, ale nejako to rozdrobili na menšie časti, z ktorých si môžete vybrať podľa vlastnej úvahy a robiť to keď sa vám to hodí - a možno aj aktualizovali - ani sa mi nechce veriť, že keď som to robil ja, písal sa rok 2011. Stačí sa prihlásiť a môžete študovať: https://lagunita.stanford.edu/courses/DB/2014/SelfPaced/about
Zatiaľ čo som to písal, jozko ma predbehol, je to rovnaký kurz, ako odporúča on.
-
A kterému SQL byste se chtěl věnovat? Jazyk mají všechny podobný, ale implementace a tím pádem i nutné návyky programátorů se pak liší.
Aniž bych chtěl slovíčkařit, SQL je defacto jen jedno. V čem se to liší jsou různé procedurální nástavby jako PLSQL (Oracle), T-SQL (MS), atd... Ale to si každý na svém písečku dodělává to co mu ve vanila SQL chybí.
S tím bych nesouhlasil. Pro optimální využití vlastností té či oné databáze musíte znát její specifika i to, na co je optimalizovaná. Např. MSSQL má rádo subselecty, PostgreSQL je neumí optimalizovat. Zase umí lépe optimalizovat joiny. Složité dotazy v každé databázi budete psát jinak, byť je jazyk prakticky stejný.
[/quote]
To už jsou pak další kroky, které se řeší na konkrétním projektu, konkrétních datech, konkrétním železe (běžně 80% dotazů, které člověk napíše běhaji dobře na všem). Pro začátek je dobrý si dát rozumný cíle a zbytečně se nesnažit obsáhnout celý svět. Nehledě na to, že v 90% všech problémů v reálných podnicich se pořeší indexama nebo větší ramkou. Když člověk příliš brzo zabředne do detailů, tak se nikam nedostane :-\ .
-
S tím bych nesouhlasil. Pro optimální využití vlastností té či oné databáze musíte znát její specifika i to, na co je optimalizovaná. Např. MSSQL má rádo subselecty, PostgreSQL je neumí optimalizovat. Zase umí lépe optimalizovat joiny. Složité dotazy v každé databázi budete psát jinak, byť je jazyk prakticky stejný.
To už jsou pak klasický cargo kulty. Optimalizace poddotazů, joinů je ve všech slušnějších databázích dneska z 80% stejná. Liší se kalkulace statistik a tudíž v některých případech některé dotazy jsou na jedné db rychlejší a na jiné pomalejší. Ve 20 procentech jsou rozdíly, ale to jsou dneska spíš obskurní věci, které se dají moderním SQL udělat jinak a rychleji. Je pravda, že MSSQL má agresivnější optimalizace korelovaných poddotazů obsahujících agregace - ale zase, kvůli tomu, má pomalejší planner. Hitne to malé procento dotazů. U Postgresu 90% lidí neví o parametrech JOIN_COLLAPSE_LIMIT a FROM_COLLAPSE_LIMIT, kterými se tato optimalizace řídí - a pak jsou překvapeni.
-
To už jsou pak klasický cargo kulty. Optimalizace poddotazů, joinů je ve všech slušnějších databázích dneska z 80% stejná. Liší se kalkulace statistik a tudíž v některých případech některé dotazy jsou na jedné db rychlejší a na jiné pomalejší. Ve 20 procentech jsou rozdíly, ale to jsou dneska spíš obskurní věci, které se dají moderním SQL udělat jinak a rychleji. Je pravda, že MSSQL má agresivnější optimalizace korelovaných poddotazů obsahujících agregace - ale zase, kvůli tomu, má pomalejší planner. Hitne to malé procento dotazů. U Postgresu 90% lidí neví o parametrech JOIN_COLLAPSE_LIMIT a FROM_COLLAPSE_LIMIT, kterými se tato optimalizace řídí - a pak jsou překvapeni.
Moje zkušenost je, že když začnou lidé na mysql, tak tam i zastydnou. Mysql má nízkou režii spojení, málo účinný, ale rychlý planner. Na ostatních databázích, když trochu nepřemýšlí, tak se bez joinů, subselectů neobejdou. Na Mysql je to naopak, joiny je svým výkonem odradí je prakticky používat. Nemluvě o "specifikách" jednotlivých storage enginů, nad kterými mně zůstává rozum stát, ale laik=>začátečník vůbec nepochopí, o čem je řeč.
-
Na Mysql je to naopak, joiny je svým výkonem odradí je prakticky používat. Nemluvě o "specifikách" jednotlivých storage enginů, nad kterými mně zůstává rozum stát, ale laik=>začátečník vůbec nepochopí, o čem je řeč.
MySQL mal svojho casu JOINy dost rychle aspon pri porovnani s korelovanymi poddotazmi. Prepisom subselectov na JOINy som v minulosti (MySQL 5.5) zrychlil generovanie zlozitejsich reportov z jednotiek hodin na sekundy.
Na Oracli sa joiny a ekvivalentne korelovane subselecty vykonavali presne tak isto.
Narychlo vymysleny priklad selectu a subselectu, kde bol rozdiel v MySQL a nie Oracle. Uloha: mame ludi (people) a orientovany graf kamaratov (friends). Najdi vsetkych kamaratov cloveka s urcenym ID:
SELECT p.name FROM people p WHERE id IN (SELECT f.target FROM friends f WHERE f.source=:source_id)
SELECT p.name FROM people p JOIN friends f ON p.id = f.target WHERE f.source = :source_id
-
MySQL mal svojho casu JOINy dost rychle aspon pri porovnani s korelovanymi poddotazmi. Prepisom subselectov na JOINy som v minulosti (MySQL 5.5) zrychlil generovanie zlozitejsich reportov z jednotiek hodin na sekundy.
V MySQL jsem kdysi začínal se subselecty, protože jsem si myslel, že budou rychlejší. Nejsou. Když jsem totéž napsal s JOINem, tak jsem byl příjemně překvapen a od té doby se toho držím. Chce to jen trochu upravit myšlení a spolehnout se na to, že čím méně vychytávek do SQL napíši, tím má planner více prostoru pro optimalizaci.
-
To už jsou pak klasický cargo kulty. Optimalizace poddotazů, joinů je ve všech slušnějších databázích dneska z 80% stejná. Liší se kalkulace statistik a tudíž v některých případech některé dotazy jsou na jedné db rychlejší a na jiné pomalejší. Ve 20 procentech jsou rozdíly, ale to jsou dneska spíš obskurní věci, které se dají moderním SQL udělat jinak a rychleji. Je pravda, že MSSQL má agresivnější optimalizace korelovaných poddotazů obsahujících agregace - ale zase, kvůli tomu, má pomalejší planner. Hitne to malé procento dotazů. U Postgresu 90% lidí neví o parametrech JOIN_COLLAPSE_LIMIT a FROM_COLLAPSE_LIMIT, kterými se tato optimalizace řídí - a pak jsou překvapeni.
Moje zkušenost je, že když začnou lidé na mysql, tak tam i zastydnou. Mysql má nízkou režii spojení, málo účinný, ale rychlý planner. Na ostatních databázích, když trochu nepřemýšlí, tak se bez joinů, subselectů neobejdou. Na Mysql je to naopak, joiny je svým výkonem odradí je prakticky používat. Nemluvě o "specifikách" jednotlivých storage enginů, nad kterými mně zůstává rozum stát, ale laik=>začátečník vůbec nepochopí, o čem je řeč.
To není vůbec pravda. Dejte sem příklad toho pomalého Joinu a řeknu vám, co děláte špatně.
-
To není vůbec pravda. Dejte sem příklad toho pomalého Joinu a řeknu vám, co děláte špatně.
Je to možné. Já už MySQL na ničem větším dávno neviděl, takže příklad ani nemám. Zastavil jsem se na neřešitelnosti optimalizace u dotazů, kde bylo asi šest a více joinů, o dotazech, kde je třeba 20 joinů mi přišlo, že si MySQL může nechat jen zdát. A pravdou je, že mysql v takových případech opravdu nikde nepotkávám. Většinou potkám MSSQL, Oracle. Výjimečně (bohužel jen výjimečně) PostgreSQL.
-
To není vůbec pravda. Dejte sem příklad toho pomalého Joinu a řeknu vám, co děláte špatně.
Je to možné. Já už MySQL na ničem větším dávno neviděl, takže příklad ani nemám. Zastavil jsem se na neřešitelnosti optimalizace u dotazů, kde bylo asi šest a více joinů, o dotazech, kde je třeba 20 joinů mi přišlo, že si MySQL může nechat jen zdát. A pravdou je, že mysql v takových případech opravdu nikde nepotkávám. Většinou potkám MSSQL, Oracle. Výjimečně (bohužel jen výjimečně) PostgreSQL.
Hlavně MySQL má, a to minimálně do verze 5.6 (v 8čce už je to úplně jinak) pouze nested loop - tudíž výkon složitějších, na objem větších dotazů je nesrovnatelně horší než u ostatních databází, které mají a umí používat hash join, merge join. Problém není v optimalizaci, ale vůbec v chybějící implementaci. Ve verzi 8.0 už v mnoha ohledech MySQL vychází z Pg (resp. Pg je použité jako etalon) - což samozřejmě může být šok pro stávající uživatele.
-
S tím bych nesouhlasil. Pro optimální využití vlastností té či oné databáze musíte znát její specifika i to, na co je optimalizovaná. Např. MSSQL má rádo subselecty, PostgreSQL je neumí optimalizovat. Zase umí lépe optimalizovat joiny. Složité dotazy v každé databázi budete psát jinak, byť je jazyk prakticky stejný.
Pokud ale databázi používáte jen na dotazy key-value (KVS), pak je lepší zvolit mysql nebo nějaké nosql. Ale to je skill, který ovládá kdekdo, na to se asi tazatel neptá.
Ale to už jsou platform specific záležitosti, které sestejně bude muset učit za chodu pokaždé když změní databázi.
Navíc v některých oblastech (typicky business inteligence) spoustu té logiky občas dělá BI tool nad tou databází, a ten dotaz buď nemůžete nijak ovlivnit (vrcholem optimalizace je, že si to postavíte nad nějakým custom VIEW) nebo to logiku včetně JOIN operací provádí nástroj sám. Rozhodně je tam hranice mezi obecným SQL a optimalizacemi, které pak řešíte na konkrétní implementaci.
To je mimochodem jako kdybyste tvrdil, že Franta - dlouholetý Oracle specialista, neumí SQL,protože firma přešla na MSSQL ;)
-
Ja se to treba ucim v praci. Uz nekolik let. :)
Jak tu nekdo rikal, SQL jazyk je v podstate standardizovan, ale dabel je ukryt v detailech.
-
Rozhodně je tam hranice mezi obecným SQL a optimalizacemi, které pak řešíte na konkrétní implementaci.
To je mimochodem jako kdybyste tvrdil, že Franta - dlouholetý Oracle specialista, neumí SQL,protože firma přešla na MSSQL ;)
To bych opět nesouhlasil. Je velký rozdíl, jestli někdo stejná data vydoluje na 10 dotazů za sebou, nebo jestli napíše jeden dotaz a složí si ho. V prvním případě není co optimalizovat a je to výsledek blbých návyků - já to tu rád přisuzuju mysql, protože to k takto blbě dělané SQL práci vysloveně vede.
-
dabel je ukryt v detailech.
To mluvíš asi hlavně o MySQL/MariaDB a jejich "No, tak nějak to je, tak nějak to funguje" :-D
Ostatně tu nedávno byl článek, odkaz nebo diskuze, kde se probíralo, jak MySQL nevrací chybu, ale příkaz neprovede korektně. Třeba to sem někdo postne.
-
Ostatně tu nedávno byl článek, odkaz nebo diskuze, kde se probíralo, jak MySQL nevrací chybu, ale příkaz neprovede korektně. Třeba to sem někdo postne.
To bylo při vkládání řetězce delšího, než je limit. MySQL ho uloží ve zkrácené podobě a vrátí zpět jen warning, který většina aplikací prostě ignoruje. Uživatel se tedy o zkrácení nemusí dozvědět.
-
Je tam daleko víc věcí.
-
Je tam daleko víc věcí.
Tak to zkus dohledat, projedu to svými testy.
-
Tak to zkus dohledat, projedu to svými testy.
Myslím, že Vám věříme, že umíte s MySQL hodně dobře, ale možná byste byl překvapený, jak dál můžete jít s opravdovou databází.
-
Tak to zkus dohledat, projedu to svými testy.
Už jsem to zkoušel, vlastně mě to ani nezaujalo, spíš jsem jen přikyvoval.
Netušil jsem, že se o tom bude za pár dní znova mluvit.
-
Pavel Stěhule by mohl vědět, nebo Petr Krčmář.
Nevím, jestli to byl článek, blog nebo koment.
-
Tak to zkus dohledat, projedu to svými testy.
Myslím, že Vám věříme, že umíte s MySQL hodně dobře, ale možná byste byl překvapený, jak dál můžete jít s opravdovou databází.
Vím, že MySQL například bohorovně ignoruje klauzuli CHECK v CREATE TABLE, což je sice ve světě SQL neslýchané, ale webovým vývojářům to obvykle nevadí. Docela jsem se tenkrát vztekal, když jsem na tuto "vlastnost" přišel. Určitě to je jedním z důvodů, proč vývojáři místo SQL používají pochybné ORM frameworky. Cizí klíče také nefungují vždy a vytvoření či změnu struktury tabulky nejde strčit do transakce.
Je toho dost na to, aby se databáze MySQL v pokročilých aplikacích nepoužívala.
-
Vím, že MySQL například bohorovně ignoruje klauzuli CHECK v CREATE TABLE, což je sice ve světě SQL neslýchané, ale webovým vývojářům to obvykle nevadí. Docela jsem se tenkrát vztekal, když jsem na tuto "vlastnost" přišel. Určitě to je jedním z důvodů, proč vývojáři místo SQL používají pochybné ORM frameworky. Cizí klíče také nefungují vždy a vytvoření či změnu struktury tabulky nejde strčit do transakce.
Je toho dost na to, aby se databáze MySQL v pokročilých aplikacích nepoužívala.
No a proto tu říkám, že pokud se někdo chce o SQL databáze zajímat, měl by se MySQL vyhnout velkým obloukem. Weboví vývojáři jsou pěkným příkladem celé obrovské skupiny, která si osvojila zbytečně špatné návyky, a to jen kvůli tomu, že je do MySQL o něco nižší vstupní bariéra. Příčina => důsledek. A z toho důsledku je pak další komický důsledek: pro sw firmy je jednodušší najmout neznalé (My)SQLkaře a nastavit způsoby programování tak, aby to MySQL vyhovovalo. Tedy z důsledku se stává příčina pro další důselek. A pak nám vznikají takové věci, jako je HHVM, frameworky, které nevyrendrují ani Hello world pod 300 ms a stihnou k tomu udělat ještě patnáct dotazů do databáze atd. atd.
A tam nechci, aby zapadl pan kolega, který se chce SQL učit.
-
To už jsou pak klasický cargo kulty. Optimalizace poddotazů, joinů je ve všech slušnějších databázích dneska z 80% stejná. Liší se kalkulace statistik a tudíž v některých případech některé dotazy jsou na jedné db rychlejší a na jiné pomalejší. Ve 20 procentech jsou rozdíly, ale to jsou dneska spíš obskurní věci, které se dají moderním SQL udělat jinak a rychleji. Je pravda, že MSSQL má agresivnější optimalizace korelovaných poddotazů obsahujících agregace - ale zase, kvůli tomu, má pomalejší planner. Hitne to malé procento dotazů. U Postgresu 90% lidí neví o parametrech JOIN_COLLAPSE_LIMIT a FROM_COLLAPSE_LIMIT, kterými se tato optimalizace řídí - a pak jsou překvapeni.
Tazatel by měl říct co chce umět. Tvoje odpověď směřuje k tomu, že db považuješ jako relační uložiště dat pro eshop či podobnou aplikaci, tam se ten provoz tolik opravdu neliší, já naopak vidím SQL jako jazyk pro analýzu/zpracování/reporting terabajtů dat v tisících tabulkách nad databázovým clusterem, kdy člověk několik měsíců píše sql dotazy, aby splnil jediný úkol.
Na trhu ve velkém chybí přesně tihle lidé, analytici (ať už byznys, BI, sales či jiní) s dobrou znalostí databáze a SQL jazyka.
V praxi jsem se snad nepotkal s programátorem, pro kterého by byl velký problém se naučit SQL v potřebné hloubce za pár týdnů/měsíců při běžném plnění úkolů. Pokud si tazatel chce jen k programování rozšířit znalosti, aby uměl napsat i nějaký "join" v SQL, asi mu stačí jakýkoliv manuál, knížka, kurz. Pokud naopak chce být tím SQL pánem na full time, zabere mu to dva roky studováním a učením se konkrétní databáze a jejich zákoutí.
-
To už jsou pak klasický cargo kulty. Optimalizace poddotazů, joinů je ve všech slušnějších databázích dneska z 80% stejná. Liší se kalkulace statistik a tudíž v některých případech některé dotazy jsou na jedné db rychlejší a na jiné pomalejší. Ve 20 procentech jsou rozdíly, ale to jsou dneska spíš obskurní věci, které se dají moderním SQL udělat jinak a rychleji. Je pravda, že MSSQL má agresivnější optimalizace korelovaných poddotazů obsahujících agregace - ale zase, kvůli tomu, má pomalejší planner. Hitne to malé procento dotazů. U Postgresu 90% lidí neví o parametrech JOIN_COLLAPSE_LIMIT a FROM_COLLAPSE_LIMIT, kterými se tato optimalizace řídí - a pak jsou překvapeni.
Tazatel by měl říct co chce umět. Tvoje odpověď směřuje k tomu, že db považuješ jako relační uložiště dat pro eshop či podobnou aplikaci, tam se ten provoz tolik opravdu neliší, já naopak vidím SQL jako jazyk pro analýzu/zpracování/reporting terabajtů dat v tisících tabulkách nad databázovým clusterem, kdy člověk několik měsíců píše sql dotazy, aby splnil jediný úkol.
Na trhu ve velkém chybí přesně tihle lidé, analytici (ať už byznys, BI, sales či jiní) s dobrou znalostí databáze a SQL jazyka.
V praxi jsem se snad nepotkal s programátorem, pro kterého by byl velký problém se naučit SQL v potřebné hloubce za pár týdnů/měsíců při běžném plnění úkolů. Pokud si tazatel chce jen k programování rozšířit znalosti, aby uměl napsat i nějaký "join" v SQL, asi mu stačí jakýkoliv manuál, knížka, kurz. Pokud naopak chce být tím SQL pánem na full time, zabere mu to dva roky studováním a učením se konkrétní databáze a jejich zákoutí.
Já určitě nejsem ten, kdo by považoval databázi za storage. Pokud se někdo pídí informací tady na rootu, tak předpokládám, že se bude jednat o skutečného začátečníka. Samozřejmě, že je možné dál pokračovat - ale to už asi chce mít jasnější představu - už jen OLAP nebo OLTP se bude hodně lišit. I když pořád ANSI/SQL je pořád stejné.
-
Nevím, jestli to byl článek, blog nebo koment.
Bylo to v článku z LinuxDays (https://www.root.cz/clanky/ipv6-tunely-s-openvpn-mysql-zere-data-a-sifrovani-disku-s-tpm/), protože právě tam o tom měl přednášku David Karban. Můžete si i pustit záznam (https://youtu.be/W02MPPufQs8).
-
už jen OLAP
Vytvářet datovou kostku, transformace a řezy nad MySQL? ;D
To jde?
I s nástroji od M$ to považuji za nechutnou práci.
-
už jen OLAP
Vytvářet datovou kostku, transformace a řezy nad MySQL? ;D
To jde?
I s nástroji od M$ to považuji za nechutnou práci.
MySQL jsem zrovna pro OLAP na mysli neměl - ale třeba Netezzu nebo Vertiku.
-
Díky všem za reakce, nečekal jsem že se to tady tak rozjede. Taky se omlouvám, že reaguju až teď.
Jinak k věci - opravdu jde zatím jen o dovzdělávání se a rozšíření znalostí, takže nezáleží na konkrétní implementaci. Třeba MSSQL, protože na trhu práce je asi nejžádanější, nebo klidně PostgreSQL nebo Firebird, pokud jsou k učení nejvhodnější. Nějakou specializaci na jiné bych řešil až by to přišlo.
Šlo mi hlavně o tipy na tutoriály nebo knížky, podle kterých jste se např. někteří z vás učili.
-
už jen OLAP
Vytvářet datovou kostku, transformace a řezy nad MySQL? ;D
To jde?
I s nástroji od M$ to považuji za nechutnou práci.
MySQL jsem zrovna pro OLAP na mysli neměl - ale třeba Netezzu nebo Vertiku.
Je to asi raritka, ale vim o nasazeni desitek mysql (verze 3-4) jako datoveho skladu. Je to dost stary navrch a nulta vrstva se naliva maximalne 2x denne, protoze jinak se to vetsinou nestiha spracovavat. Kazdy sklad ma 5 vrstev pocinaje cca 300 tabulkama u prvni a konce cca 400 u posledni. Neni vyjimkou ze db myvaji kolem tera. Cele to bezi na myisam bez transakci. ETL je udelane v perlu. Nad skladem pak sedi cognos.
-
MySQL bych nezatracoval, protože projekty jako Presta, Magento to od sameho začátku používají a jede na tom spousty velkých eshopů.
-
MySQL bych nezatracoval, protože projekty jako Presta, Magento to od sameho začátku používají a jede na tom spousty velkých eshopů.
Jo, ale když se podíváte do střev, tak se Vám chce plakat, jaká je to prasárna. Kdyby ti samí programátoři ovládali SQL, byli by s tím produktem někde jinde.
-
Oba projekty mají zdrojáky na githubu, buď konkrétní, kde bys použil jiné možnosti SQL, které by produkty posunuly dál.
-
Oba projekty mají zdrojáky na githubu, buď konkrétní, kde bys použil jiné možnosti SQL, které by produkty posunuly dál.
Stačí se podívat na to, kolik dotazů do databáze pošlou, aby vyrendrovali jednu jedinou stránku. Je "dobrým" zvykem myslqkařů vše řešit na úrovni aplikace, a z db dolovat data po drobcích. Nevím, jak víc být konkrétní, ale vím, že jsem nepotkal nikoho, kdo by z dospělejší databáze přešel na mysql, opačným směrem znám lidí dost.
-
Máš srovnání s jinou srovnatelnou aplikací, která to dle tvého popisu dělá "správně", abychom se mohli poučit? Nebo alespoň příklad v jejich zdrojáku, kde bys to uměl zoptimalizovat a běželo by to na podobném HW rychleji/kód by byl přehlednější/bylo by to lépe rozšiřitelné? Obecné hlášky mě nezajímají, buď konkrétní.
-
Máš srovnání s jinou srovnatelnou aplikací, která to dle tvého popisu dělá "správně", abychom se mohli poučit? Nebo alespoň příklad v jejich zdrojáku, kde bys to uměl zoptimalizovat a běželo by to na podobném HW rychleji/kód by byl přehlednější/bylo by to lépe rozšiřitelné? Obecné hlášky mě nezajímají, buď konkrétní.
Konkrétně chci po svých lidech, aby mi vysvětlili jakoukoliv situaci, kdy je potřeba víc než 5 dotazů do databáze na stránku, a to si přijdu často jako velkorysý. Zbytek se dá provést složeným dotazem a inteligentní prací s navrácenými daty.
Takže to udělejme opačně. Napište mi, kde si myslíte, že je potřeba dotazů víc.
-
Já si nestěžoval, tobě se zrovna tyto produkty/jejich přístup nelíbí, tak buď konkrétní. Kolik dotazů na stránku generují a kde se to dá spojit do jednoho?
Tyhle projekty neznám a nepoužívám, ale stránky komerčních webů obecně obsahují celou řadu spolu víceméně nesouvisejících bloků. Často více než 5 a je to věcí požadavků obchodu, který produkty na stránce prodává. Těžko vyrobit jeden dotaz, který obslouží všechny bloky najednou, a zároveň udržet kód rozšiřitelný.
Samozřejmě se spoustu řeší asynchronně ajaxem, ale i to ve finále vygeneruje query. Nebo se to různě řeší kešováním, ale to už s tímto nesouvisí.
-
Já si nestěžoval, tobě se zrovna tyto produkty/jejich přístup nelíbí, tak buď konkrétní. Kolik dotazů na stránku generují a kde se to dá spojit do jednoho?
Nepotřebuji vést tento způsob diskuse, abych obhajoval, že mysql mizerně joinuje (výše to dokonce někdo vysvětlil), a že programátoři nevolí popsaný programování způsob jako výsledek racionální volby, ale jako nutnost pro využití mysql.
To vše v rámci threadu o tom, že se někdo chtěl naučit SQL a v rámci odpovědi, že mysql je parodie na databázi, a vytvoří v lidech akorát zkreslenou představu o tom, jak mají databáze fungovat a založí u dalšího nešťastníka špatné návyky.
V rámci diealektiky nabízím zamyšlení nad tím, proč a jak si může někdo myslet, že zejména v PHP (!) vytvoří lepší datovou logiku, než databáze. Kdokoliv, kdo data zpracovává v aplikaci, zejména takto pomalé, zaslouží přes prsty.
-
Máš pravdu, označit něco
když se podíváte do střev, tak se Vám chce plakat, jaká je to prasárna. Kdyby ti samí programátoři ovládali SQL, byli by s tím produktem někde jinde.
a pak nebýt schopen konkrétně označit, kde konkrétně v daném open source produktu je to prasárna a jak by s jiným přístupem k SQL byli někde jinde, opravdu není diskuse. Jsem zvyklý, že jsou takto kategorická tvrzení podložená argumenty. Ty projekty neznám, je docela možné, že jsou prasácké (pro mě je show stopper samotné PHP), ale bez připravených linků na kód v githubu bych si to tvrdit netroufl.
Mimochodem tím by se tazatel docela naučil, kdyby konkrétně viděl špatný příklad.
-
..., proč a jak si může někdo myslet, že zejména v PHP (!) vytvoří lepší datovou logiku, než databáze. Kdokoliv, kdo data zpracovává v aplikaci, zejména takto pomalé, zaslouží přes prsty.
Nad tím mi občas také zůstává rozum stát. Mé aplikace v PHP jsou rychlé právě díky tomu, že v něm data téměř nezpracovávám, pouze přes něj protékají sestaveným kanálem.
-
a pak nebýt schopen konkrétně označit, kde konkrétně v daném open source produktu je to prasárna a jak by s jiným přístupem k SQL byli někde jinde, opravdu není diskuse. Jsem zvyklý, že jsou takto kategorická tvrzení podložená argumenty.
Ale já to nemám jak označovat, o žádný takový produkt se toho času nestarám. Většinou se s těmito projekty setkám ve chvíli, kdy něco zlobí, a kdy člověk může leda pokrčit rameny, že se s tím nedá nic dělat. Bohužel zákazníci Prestashopu nejsou připraveni zaplatit manday za hledání nějaké možnosti optimalizace. (Jen jako příklad).
-
Konkrétně chci po svých lidech, aby mi vysvětlili jakoukoliv situaci, kdy je potřeba víc než 5 dotazů do databáze na stránku, a to si přijdu často jako velkorysý. Zbytek se dá provést složeným dotazem a inteligentní prací s navrácenými daty.
Takže to udělejme opačně. Napište mi, kde si myslíte, že je potřeba dotazů víc.
jednoduchy eshop, pristup na stranku www.shop.local/en/vlnene-ponozky co je kategoria s produktami. Len tak z hlavy ma napada hned 10 vecy, ktore treba z Db vytiahnut:
1. slug (/vlnene-ponozky je kategoria s ID = 123)
2. category info (name, description,..)
3. produkty v kategorii, ktore na stranke zobrazim (filtre, sort, strankovanie)
4. zakaznikov kosik (kolko ma produktov a celkova cena)
5. zakaznikov wishlist (kolko ma produktov vo wishliste)
6. nejaky SEO CMS text priradeny ku kategorii
7. user session ak mam v DB
8. reklamny banner
9. navigacia (strom kategorii)
10. nejake boxy (bestsellers, new products,..)
to fakt nutite programatorov tychto desat dotazov do DB zlucovat do jedneho?! ::)
-
Konkrétně chci po svých lidech, aby mi vysvětlili jakoukoliv situaci, kdy je potřeba víc než 5 dotazů do databáze na stránku, a to si přijdu často jako velkorysý. Zbytek se dá provést složeným dotazem a inteligentní prací s navrácenými daty.
Takže to udělejme opačně. Napište mi, kde si myslíte, že je potřeba dotazů víc.
jednoduchy eshop, pristup na stranku www.shop.local/en/vlnene-ponozky co je kategoria s produktami. Len tak z hlavy ma napada hned 10 vecy, ktore treba z Db vytiahnut:
1. slug (/vlnene-ponozky je kategoria s ID = 123)
2. category info (name, description,..)
3. produkty v kategorii, ktore na stranke zobrazim (filtre, sort, strankovanie)
4. zakaznikov kosik (kolko ma produktov a celkova cena)
5. zakaznikov wishlist (kolko ma produktov vo wishliste)
6. nejaky SEO CMS text priradeny ku kategorii
7. user session ak mam v DB
8. reklamny banner
9. navigacia (strom kategorii)
10. nejake boxy (bestsellers, new products,..)
to fakt nutite programatorov tychto desat dotazov do DB zlucovat do jedneho?! ::)
Tohle se do těch pěti dotazů v pohodě vejde.
-
to fakt nutite programatorov tychto desat dotazov do DB zlucovat do jedneho?! ::)
Ano, nutím. Protože ne všechno se musí brát z databáze. Já jsem nepsal, že víc nepřipustím, ale chci, aby to programátoři uměli odůvodnit. Např. reklamní systém nemá dělat v té samé databázi, jako je e-shop, kvůli riziku blokování, obzvlášť, pokud zaznamenává statistiky.
1+2+3+6 = může být jeden dotaz dle stránky, kde jsem (klíčem je ID kategorie, případně ID kategorie+ID uživatele).
4+5+7 = druhý dotaz, protože klíčem je ID uživatele (session podle mě v databázi nemá co dělat, maximálně v redisu)
9 = třetí dotaz, ale asi bych zvažoval cache
10 = záleží na situaci
-
to fakt nutite programatorov tychto desat dotazov do DB zlucovat do jedneho?! ::)
Ano, nutím. Protože ne všechno se musí brát z databáze. Já jsem nepsal, že víc nepřipustím, ale chci, aby to programátoři uměli odůvodnit. Např. reklamní systém nemá dělat v té samé databázi, jako je e-shop, kvůli riziku blokování, obzvlášť, pokud zaznamenává statistiky.
1+2+3+6 = může být jeden dotaz dle stránky, kde jsem (klíčem je ID kategorie, případně ID kategorie+ID uživatele).
4+5+7 = druhý dotaz, protože klíčem je ID uživatele (session podle mě v databázi nemá co dělat, maximálně v redisu)
9 = třetí dotaz, ale asi bych zvažoval cache
10 = záleží na situaci
1+2+6 chapu, ale neprijde mi moc prakticke k tomu pridavat 3. Jestli v te kategorii mam 90 druhu ponozek, tak u kazdeho z nich asi nechci mit i 1+2+6.
-
to fakt nutite programatorov tychto desat dotazov do DB zlucovat do jedneho?! ::)
Ano, nutím. Protože ne všechno se musí brát z databáze. Já jsem nepsal, že víc nepřipustím, ale chci, aby to programátoři uměli odůvodnit. Např. reklamní systém nemá dělat v té samé databázi, jako je e-shop, kvůli riziku blokování, obzvlášť, pokud zaznamenává statistiky.
1+2+3+6 = může být jeden dotaz dle stránky, kde jsem (klíčem je ID kategorie, případně ID kategorie+ID uživatele).
4+5+7 = druhý dotaz, protože klíčem je ID uživatele (session podle mě v databázi nemá co dělat, maximálně v redisu)
9 = třetí dotaz, ale asi bych zvažoval cache
10 = záleží na situaci
1+2+6 chapu, ale neprijde mi moc prakticke k tomu pridavat 3. Jestli v te kategorii mam 90 druhu ponozek, tak u kazdeho z nich asi nechci mit i 1+2+6.
I s touto výhradou se stále vejdeme do těch pěti dotazů. Ovšem neděláme zde rozbor konkrétního webu. V reálu bychom se dostali na běžné 2-3 SQL dotazy a 5 dotazů by mělo stačit téměř na vše.