Příspěvky

121

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 25. 06. 2021, 05:31:25 »

ORM je tzv. "leaky abstraction" -  https://en.wikipedia.org/wiki/Leaky_abstraction

coz vubec nevadi, pokud nepotrebujete stridat databaze. Hlavni ucel ORM je moznost psat SQL ve vyssim, expresivnejsim jazyce.

SQL je dostatečně expresivním jazykem, většina ORM toho nedosahuje.

Neni, je to jazyk nizke urovne abstrakce. SQL napriklad neumoznuje jednoduche skladani dotazu ze znovupouzitelnych casti, kdyz chcete pristupovat k nejakemu atributu pres pet joinu, musite je psat znovu a znovu v ruznych dotazech, ktere se navzajem podobaji. ORM a query buildery nahrazuji dynamicke lepeni dotazu z retezcu.

Muzeme se bavit konkretne, ukazte mi priklad SQL dotazu a ja vam ukazu radove kratsi ORM kod, ktery dela to stejne.

Pokud chcete slovickarit jako obvykle, nebudu odpovidat.

To co umožňuje perzistentní  kompozici v SQL se jmenuje pohledy. Pokud si vyrobíte pohled, tak nemusíte opakovaně psát JOINy.

Stačí jednoduchá úloha - mějte relaci obce, a relaci okresy, a pro každý okres dohledejte 10 největších obcí (efektivně).

122

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 22. 06. 2021, 11:52:54 »

Můžete, ale tím se "zdvojuje" prefix, a co jsem viděl, tak pokud se používá tato konvence, tak byla snaha nepoužívat aliasy.

Tohle nějak nechápu - ale nečetl jsem nic na toto téma. Když mám v klíči jméno tabulky, tak mi přijde, že tím spíš můžu použít krátké aliasy a orientaci mi poskytne právě prefix v identifikátoru klíče. Zatímco krátké identifikátory se mi zdají v kombinaci s tabulkovými aliasy méně čitelné (a.id vs. a.account_id). Je pravdou, že při inner joinech lze pracovat úplně bez prefixu i bez aliasu, a nesníží to čitelnost.

Nemáš k tomu nějaký text? Možná by to mohlo být podnětné.

Možná je to víc o estetice (a ta je subjektivní) a až potom k tomu hledáme technické argumenty. Podobné je to třeba s formátováním SQLka. Ten subjektivní pocit je důležitý pro mentální pohodu, ale zároveň to vylučuje větší shodu.

Mně vyhovuje a vycházím ze stylu Joe Celka Joe Celko's "SQL Programming Style"

https://www.sqlstyle.guide/

123

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 22. 06. 2021, 11:34:51 »

Druhý zápis je expresivnější, a mám možnost volby aliasů (a je zdůrazněný rozdíl mezi primárním a cizím klíčem)

Aliasy můžete volit i u prvního zápisu, v tomto ohledu se to neliší.

Můžete, ale tím se "zdvojuje" prefix, a co jsem viděl, tak pokud se používá tato konvence, tak byla snaha nepoužívat aliasy.

Podle mne výhody, a nevýhody budou podobné jako např. u použití maďarské notace. Je to hodně podobné.

124

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 22. 06. 2021, 10:57:48 »

Mohl byste to prosím ilustrovat na příkladu?
Děkuji, opravdu bych takové doporučení považoval za užitečné.

Každá konvence vede k trochu jinému zápisu. Funkčně je to úplně stejné.

Kód: [Vybrat]

SELECT zam_prijmeni, adr_ulice || adr_cp FROM zamestnanci JOIN adresy USING (zam_id)

nebo

Kód: [Vybrat]

SELECT z.prijmeni, a.ulice || a.cp FROM zamestnanci z JOIN adresy a ON z.id = a.zamestnanec_id

První zápis vás nutí dodržovat konvenci (což je dobrá vlastnost), ale musím si pamatovat navíc prefixy. Druhý zápis je expresivnější, a mám možnost volby aliasů (a je zdůrazněný rozdíl mezi primárním a cizím klíčem)

125

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 22. 06. 2021, 06:43:46 »

Proč? Salary.id říká docela přesně, o co se jedná. Nesnáším pleonasmy.

Protože u tabulek v dotazech používáte aliasy a u cizích klíčů stejně musíte uvést jiné označení, než jen "id".
PostgreSQL (a myslím, že i další) zápis joinů ujednodušit, pokud se jména sloupců shodují (a prosté "id" se shoduje u více tabulek).

Takže místo

Kód: [Vybrat]

SELECT ... FROM sallary AS s INNER JOIN employee AS e ON s.employee_id = e.id

zapíšete pouze

Kód: [Vybrat]

SELECT ... FROM sallary AS s INNER JOIN employee AS e USING (employee_id)

Je to pak čitelnější, méně náchylné na chyby.
Má to pak zase jiné, menší nevýhody - ale určitě nejde říct, že používat prosté "id" je lepší.

Já osobně nemám USING rád. Nedej bože NATURAL JOIN. Konvenci tabulka_sloupec používám pro cizí klíče, ale už ne pro primární - pak by nebylo poznat, co je primární klíč a co cizí klíč. Navíc, a to vychází od Joe Celka, v případě, že máte název tabulky zkopírovaný v názvu sloupce, tak si nemůžete pomoct aliasy. A pokud máte delší názvy tabulek, tak zákonitě musí být dotaz delší a asi hůře čitelný.

Pokud se s databází nepracuje ručně (schéma generuje CASE, dotazy ORM nebo query designer), tak je to asi jedno, ale při ruční editaci jsou rozumně dlouhé identifikátory základ.

126

Vývoj / Re:Zlepšení čitelnosti vlastního kódu

« kdy: 03. 06. 2021, 20:42:55 »

Code review, aby mělo smysl, musí nějakou dobu trvat a účastníci se na něj mají připravit, pročíst si kód.
Představa, že procházím cizí kód za týden - OD ČTYŘ LIDÍ - vlastně pěti (i svůj), protože na codereview se člověk prostě trochu připraví = zabiju tím 5 lidí * 1-2 hodiny každý = celý pracovní den. Resp. zabiju PĚT člověkodní, protože to stejné musí udělat i ti ostatní. Takže jsem ztratil pět člověkodní a to to ještě nezačalo. Plus - nějakou dobu to trvá, takže celkem pět lidí se svým kódem, každý 40 minut? A pak nějaký čas na finální opravy? I kdybych to všechno stihl za jeden den, pořád to musí udělat všech pět lidí a je zabitých 5 pracovních dnů.

...ale mohu se plést, pletu se často a pletu se rád....

U kritických aplikací se tohle běžně dělá - nicméně jsou to úplně jiné ceny. U Postgresu se dělá review každého patche na několika úrovních a běžně se kód přepisuje 10-100x. Nicméně ten kód pak budou používat milióny lidí. Review kódu odděluje okresní přebor od první ligy. Je to jeden z ukazatelů, jak poznat slušnou firmu. V několika firmách v republice jsem to zažil. Samozřejmě, že pokud má firma na jednom produktu jednoho programátora, tak nemá cenu dělat code review, ale tam těžko bude kdokoliv za cokoliv ručit. Máte aplikace, kdy za neplánovaný výpadek se platí penále v jednotkách miliónů, a code review je základ pro kvalitní kód. Záleží, kdo code review dělá a jak. Ale i tak, je tam psychologické hledisko. Špičkový programátor neprasí, ale takových je málo. Normální programátor neprasí, pokud ví, že jeho kód bude číst někdo jiný, a že pokud ho neodsouhlasí, tak ho bude přepisovat.

127

Server / Re:Zdroje o Postgresql v Cestine

« kdy: 14. 05. 2021, 11:12:08 »

Ahojte,
viete odporucit dobre zdroje o Postgresql v cestine (nie len zaklady, ale napriklad aj JSONB, polia, pohlady, procedury,...)?

https://postgres.cz/wiki/Kategorie:%C4%8Cl%C3%A1nky

128

Server / Re:Mazanie duplicit v Icinga db - zlepšenie sub selectu

« kdy: 10. 05. 2021, 11:26:44 »

Ahoj,

musim pomazat duplicity (bug) v icinga_commenthistory (5000000 zaznamov).

Vymyslel som to tak ze zistim maximalne id v subselecte a tieto ID nebudem mazat. Zial bezi to neskutocne dlho.

Kód: [Vybrat]

select max(commenthistory_id)
from icinga_commenthistory
group by comment_time, comment_data

Nejaky napad jak toto urychlit?

Co to je za databázi? Pro většinu db se dá vygooglit dotaz na efektivní mazání duplicit.

Váš dotaz by dost možná urychlil složený index na (comment_time,comment_data, comment_history_id)

129

Studium a uplatnění / Re:Aktuální MD rate pro korporáty

« kdy: 04. 05. 2021, 08:08:05 »

učitelku může dělat de fakto každý,

Nie, nemoze. To su take kecy zaprdenych ajtakov, ktori cely den presedia za pc

Ono ani toho kuchaře nebo pekaře nemůže dělat každý :-)

130

Server / Re:Postgres - upgrade v ramci kontejneru

« kdy: 01. 05. 2021, 06:16:00 »

já myslel, že kontejnery zjednodušují práci. Je něco obtížného na yum install postgresql-server-x?

Je to jako s každým jiným nástrojem – nějakou práci to zjednoduší, jiná se tím zkomplikuje. Nainstalovat jeden PostgreSQL na jeden server je samozřejmě jednodušší pomocí balíčkovacího manažeru, ale když na tom serveru budu chtít mít třeba pět verzí PostgreSQL kvůli testování, záleží už na konkrétní distribuci, zda má PostgreSQL zabalený tak, že více verzí umožňuje (zrovna kvůli těm upgradům to asi bude u PostgreSQL běžné, ale u jiného softwaru ne).

To právě u pg není vůbec žádný problém.

131

Server / Re:Postgres - upgrade v ramci kontejneru

« kdy: 30. 04. 2021, 17:40:50 »

Já to řešil kdysi, a problém byl, že kontejner neobsahoval ty správné verze binárek (staré i nové zároveň), jak píšete.

Existuje https://github.com/tianon/docker-postgres-upgrade který by to měl řešit, ale já jsem to tenkrát vzdal, a vrátil se k MySQL pro kontejnerové nasazení, takže zkušenosti s tím nemám.

já myslel, že kontejnery zjednodušují práci. Je něco obtížného na yum install postgresql-server-x?

132

Server / Re:Postgres - upgrade v ramci kontejneru

« kdy: 30. 04. 2021, 14:51:03 »

Pro upgrade ale nepotřebujete mít tu starou verzi PostgreSQL nainstalovanou, ne? Je potřeba mít data ze staré verze a k tomu novou verzi Postgresu. Tj. postup s kontejnery by měl být takový, že zastavíte kontejner se starou verzí, zazálohujete data. Pak z kontejneru s novou verzí spustíte initdb do nového datového adresáře, pak spustíte pg_upgrade z adresáře s původními daty do adresáře s novými daty a na závěr už jen spustíte kontejner s novou verzí, ke kterému bude připojen adresář s daty v nové verzi. Díky kontejneru ani nemusíte PGDATA měnit – prostě jen datový adresář přilinkujete na správné místo.

To si jsem jistý, že u pg_upgrade to tak není (možná si to pletete s MySQL). Podívejte se na povinné argumenty pro pg_upgrade. Zadáváte tam cestu ke starým binárkám. U Postgresu nové binárky neumí přečíst starý systémový katalog. Klienti se umí připojit ke staré verzi Postgresu (psql, nebo pg_dump), ale ta stará verze musí běžet.

133

Server / Re:Postgres - upgrade v ramci kontejneru

« kdy: 30. 04. 2021, 11:10:36 »

Nikdy jsem nic takového nezkoušel, nicméně pg_upgrade funguje tak, že musíte mít vedle novou instanci Postgresu, a tudíž v jednu chvíli musíte mít nainstalovanou jak starou, tak novou verzi (ve vašem případě 10 a 13). Uděláte initdb vůči nové verzi (nesmíte ji nastartovat), pak vypnete starou verzi a zavoláte pg_upgrade. Když to projde (migrace z 10 na 13) by neměla být problémová, tak pak můžete smazat (předpokládám, že máte backup) starou verzi, a pokud vám nevyhovuje aktuální adresa nové instance, tak přesunout novou instanci, kam chcete. Jen někde musíte změnit PGDATA, aby se odkazoval na novou instanci. Z praktických důvodů (aby šlo jednoduše volat pg_upgrade) se do cesty v PGDATA dává verze pg.

134

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 22:01:27 »

ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.

135

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 17:51:23 »

Takže pokud je objektový graf v paměti, nebude mít ani objektové databáze s hromadnou operací nějaký zásadní výkonnostní problém (cyklus se změnou nějaké hodnoty u kolekce objektů může být docela rychlá operace, navíc to asi půjde v řadě případů i paralelizovat). Hlavní benefit by přitom byl nulový object-relational impedance mismatch (neznám český ekvivalent tohoto pojmu). Ten sám o sobě přináší výkonnostní problémy, takže v reálných projektech by pak mohla být objektová databáze naopak rychlejší než neoptimálně použité ORM, kde navíc hrozí  i nekonzistence (při neobratném použití), což zase eliminuje další killer feature sql databází (konzistenci).

Konceptem in-memory objektové databáze se pohybujeme cca někde na úrovni toho Smalltalku, který taky ukládá image na disk až na ruční vyžádání. Čili se nakonec celá debata vede o tom, co z ACID (atomicity, consistency, isolation, durability) mohou objektové (či NoSQL) databáze vlastně nabídnout. A téma o možnosti objektovou databázi provozovat distribuovaně napříč stroji je další level téhož.

Pokud to bude inmemory a na aplikačním serveru, tak by výkon mohl být ok. Nicméně asi stejně potřebujete něco ve smyslu indexů (ať už nějaké stromy nebo hash tabulky). Je otázkou, jak by se to chovalo po studeném startu. Jinak samozřejmě, výkon a chování by mělo být +/- srovnatelné s ostatními inmemory databázemi. Ale i mezi inmemory databázemi mohou být výkonnostní rozdíly - v extrému se řeší i design, který minimalizuje výpadky CPU cache - on random access nesvědčí ani RAMce