Příspěvky

16

Server / Postgresql - SPI-Trigger nebo udf-funkce

« kdy: 09. 11. 2021, 22:41:28 »

potreboval bych pri updateu tabulky nova data jeste napsat nekam do pameti. Zjistil jsem , ze se nabizi asi dve cesty.
Jednou by bylo pracovat s SPI-triggery, druha moznost  by byla nejaka udf-funkce, ktera by se volala v triggeru tabulky, ktery by byl nedefinovan beznym zpusobem.
Nema nekdo zkusenosti s tim, kde by byla nejake zadrhely, co je jednodussi. Co jsem zatim zjistil je, ze u toho SPI Triggeru je asi (mozna) jednodussi ziskat jednim volanim cely tuppel (kdy jsou obsahy jednotlivych sloupcu stringy) , kdezto u te funkce bych musel asi obsahy jednotlivych sloupcu pri volani predat jako parametry.
Obecne bych jeste rad znal nazor, zda se to SPI programovani stale nejak vubec pouziva -> na internetu je toho relativne malo. Aby to nebyla slepa ulicka.

17

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

« kdy: 07. 06. 2021, 16:28:41 »

.... Jenže u programování se nejen vždy znovu vynalézá kolo, to se montuje do celé sestavy a to často za běhu motoru a s cestujícími na palubě, ale během cesty se z původního stroje stává často něco zcela jiného, než bylo původně zamýšleno a zdokumentováno.

a tenhle nesmyslny styl prace vylepsime tedy tim, ze budeme psat srozumitelnejsi komentare, budeme psat jen 65 znaku na radku .... ?

18

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

« kdy: 07. 06. 2021, 16:23:41 »

Dělal jsem čtyři roky ve fabrice. Když jsem nastupoval, ptal se mě ředitel, zda rozumím výkresům - no, učil jsem se to, no.
Pak jsem pravidelně chodil za mistrem s tím, ať zavolá zadavateli, že na tom plánu jsou tyhle kóty dvakrát, rozporné, a tady zase rozměr chybí.

Tož asi tolik k tvému příspěvku :-)

ano, je to presne jak pises. Aniz by si znal toho zadavatele si mohl okamzite zjistit kde jsou v tom kodu chyby a samozrejme si take chapal o co jde. A i ten mistr a ti ostatni tomu take rozumneli ... atd , atd ...

Uprimne receno jsem ani necekal, ze nekdo ty moje myslenky podpori.

19

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

« kdy: 07. 06. 2021, 14:03:48 »

kdyz jsem procital diskuzi, tak jsem si rikal, jestli je rok 1980.

Ale tenkrat vlstne root jeste neexistoval. No nic, asi ten vyvoj nejde tak rychle - tedy jak jsem si to ja kdysi predstavoval.

Pred nedavnem jsem byl u znameho ve firme. Tam jsem ve vyrobni hale na stolech videl taky takove predpisy, navody, pracovni postupy, jak je co treba delat. Rikali tam tomu vykres. Bylo dost prekvapive, ze kazdy tem navodum rozumnel - dokazal je cist. A dokonce ani neznali toho, kdo ty navody(programy  ) psal.
Ani tam nepouzivali tu metodu, jak ji tady nekdo propaguje v diskuzi, totiz ze by u soustruhu stali 2 zamestnanci a delali by na jedne veci spolecne.
Co je podobne je ten review - to u tech vykresu taky nekdo dela, je tam dokonce kolonka, kde ten kontroler napise jmeno a datum. Ale jenom jeden a asi to kontroloval jen na jedne urovni , ne jako u toho postgresql.
Co jsem take nevidel byly  komentare. A kdyz, tak jsou porad stejne ... to je divne
 

20

Distribuce / Re:Na co přejít z Centosu?

« kdy: 23. 05. 2021, 12:52:53 »

Ahoj,
pomalu se blíží konec roku a s ním i konec plné podpory Centos 7.

to snad ne. Centos 7 ma podporu do 30.6.2024, nebo?

21

Studium a uplatnění / Re:Stát se programátorem po čtyřicítce

« kdy: 01. 05. 2021, 13:49:29 »

jo, to je ta otazka - kdo je programator

ja uz jsem davno v duchodu a za cely zivot jsem zazil jedineho opravdoveho programatora - (v rijnu to bude 10 let co zemrel) - je mu venovana ta znama pisnicka:

Write in C ...https://www.youtube.com/watch?v=wJ81MZUlrDo

V te pisnicce je take zodpovezeno, zda jsou jsou skutecne potreba vsechny ty skills, o kterych tady nekteri hovori. (napr SQL :-) )

22

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 23. 04. 2021, 23:43:35 »

V takovych diskuzich se pak cas od casu najdou lide, kteri upozorni, ze existuji i nadale 'nerelacni' cerpadla a ze by nebylo od veci se po takovych poohlednout.
V nasledne diskuzi ...

Následně se nějaký trouba zeptá, ok, jaké to nerelační čerpadlo má výhody? A dostane se mu odpovědi - to musíš zkusit.

Takhle jsi to myslel? ;-)

ne , kdyz se nekdo zepta, tak se nejdrive odkaze na CAP-teorem a pak na nejake pojednani o tom teoremu (napr. https://blog.nahurst.com/visual-guide-to-nosql-systems), aby se tazatel zacal orientovat, jake ty vztahy mezi temi relacnimi a jinymi databazemi vypadaji.

Pak se samozrejme vyjmenuji v obecne rovine ty hlavni vyhody:
- odpada impedance mismatch mezi relacnim dotazovanin a naslednym imperativnim zpracovanim dodanych dat
- skalovatelnost
- flexibilita pri ukladan dnesnich rozmanitych, ruznorodych a menícich se dat
- vestavene funkce pro vyhledavani a dotazovani, diky nimz jsou data kdykoli lepe vyuzitelna
- mozna realizace bitemporernich funkci (co se vedelo , od kdy se to vedelo)
- lepsi podpora pri realizaci 'recommender' systemu

Samozrejme, ze se vyjmenovane musi rozvest a upozornit na to, ze pro ukladani dat pro nejaky e-shop je naproso jedno do ceho se to bude ukladat. A ze ty argumenty nahore plati spis pro amazon nez pro nejakou firmicku s 5 lidma.

To vse uvedene jsou samozrejme fakta pro lidi, kteri se radi o databazich pokecaji a podiskutuji.

Pro ty praktiky staci, ze se sdeli, ze pro ty nerelacni cerpadla:
- neni potreba pan Vondra nebo Stehule
- neni potreba nejakych skoleni
- dokumentace pro pristup k datum se vejde na A4 papir
- filozofie pristupu k datum pochopi prumerny stredoskolach za 2 minuty
- na zacatku projektu neni treba vedet vsechno do detailu
- v prubehu projektu se zmeny v nazorech a pozadavcich nepromitnou negativne do prubehu projektu
- zakaznik nepozaduje pristup k datum pres SQL (protoze to neexistuje) a tim se vyhnou oba partneri garancnim sporum

na zaver je mozno zminit, ze ten nejvetsi prinos je, ze to nasazeni tech nerelacnich cerpadel teprve umozni tu rozumnou modularizaci softwaroveho produktu - ale to se rekne jenom potichu, aby si toho nikdo nevsiml - protoze to je bohuzel nevysvetlitelne.

23

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 22. 04. 2021, 17:23:29 »

sakra nejde edit
Ještě doplním - to co říkáte je o to horší, že podobný argument z automobilismu by byl "tady musí být něco špatně s auty a manuální převodovkou, když je možné aby (když tam necháte jedničku) jednou byly perfektně rychlé, a jindy jely maximálně 40km/h a dělaly přitom děsný kravál" - ty rozdíly nejsou v oblasti špičkový závodník vs běžný řidič, ale na úrovni autoškoly :-(

Jsem rad, ze jste prinesl ten priklad, protoze jak rikaji v Nemecku, v kazde poradne technicke diskuzi musi byt priklad z automobiloveho prumyslu -  (to ted neni mysleno zle)

Bohuzel je to s temi priklady tak, ze se pak vetsdinou diskutuje o tom, zda je ten ktery priklad vhodny. Presto to zkusim a predkladam neco (myslim si) prihodnejsiho:

Mame cerpadlo , ktere ma cerpat do 50 metru vysky. Ale neni to ledajake cerpadlo, je to cerpadlo intergalakticke ktere cerpa jakoukoliv tekutinu za jakychkoliv podminek (jak stoji v prospektu toho cerpadla - na Sahare nebo servnim polu). Je to proste intergalakticke cerpadlo, ktere ma jen jeden hacek. Musi se to poradne nastavit. Ten, kdo to nastavuje nejlepe navstivi skolenui u znameho experta a nebo si vsechno zjisti samostudiem. Vlastne je to nastaveni toho cerpadla hracka - chce to jen chtit.

Na strojnich fakultach se v oboru hydrodynamika vyucuji jen intergalakticka 'relacni' cerpadla a o tech drivejsich se moc nemluvi. Behem vyuuky se studentum klade na srdce, ze pri pumpovani za pomoci relaacnich cerpadel je treba zohlednit tu filosofii takovych cerpadel a to jak se pumpovalo driv je treba zapomenout.

Existuje rada vyrobcu 'relacnich' cerpadel a na znamych portalech se obcas objevi otazka, zda je cerpadlo A lepsi nez B. V takovych diskuzich se pak cas od casu najdou lide, kteri upozorni, ze existuji i nadale 'nerelacni' cerpadla a ze by nebylo od veci se po takovych poohlednout.
V nasledne diskuzi si pak priznivci obou taboru vymneni dojmy typu 'u me to funguje', 'neni to vubec tezke', 's SQL se nemuzeme zdrzovat' apod.

V ramci takove diskuze priznavaji specialiste na 'relacni' cerpadla, ze v praxi nachazeji velmi casto pripady spatne nastavenych cerpadel, coz zpusobuje , ze vetsina cerpadel pumpuje nejvys do 2 metru. A zde prichazi do hry ta mocna carodejka - priroda - ktera to zaridila tak, ze 99% uzivatelu potrebuje pumpovat do tech 2 metru a proto je to sumafuk jak je to cerpadlo nastaveno. Takovym uzivatelum by stacil kybl, ale protoze vetsina 'relacnich' cerpadel je zadarmo, tak se to pouzije.

Existuji pripady, kdy je ovsem treba pumpovat do tech 50 metru. A najednou to nejde a je treba zavolat toho specialistu.  A ten zjisti, ze se zapomnelo dat sito na tom vtoku a je to vyrizene. A nebo ale take zjisti, ze se zapomnel rybnik predelit  hrazi na dve casti, ze je potreba do vody pridavat zmekcovadla (denormalizace  , ze je treba rybnich pred vypumpovanim ohrat nebo ochladit a dalsi veci, ktere by provozovatel vedel, kdyby navstivil to skoleni 'jak pumpovat s intergalaktickym relacnim cerpadlem'.

24

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 20. 04. 2021, 16:45:02 »

Ty problémy by měla každá databáze - ...... A)

V IT dělá každý, kdo má ruce. .... B)

A)
moje zkusenost je takova, ze kdyz se nepouzije SQL tak zadne problemy s SQL nejsou. U databazi jako ADABAS, SAP-DB, SolidDB, SAP Advanced Server, Faircom, BerkeleyDB nemusite vubec nikoho skolit na SQL , nikdo nevi co je referencni integrita a normalni formy, kdy se u jake databaze smi a nesmi pouzit jaky trigger   a presto je vsechno vpohode a ACID 
Aplikacni programatori si prectou na A4 papiru, jak se jmenuji ty funkce , ktere prectou data z databaze a jak se jmenuji ty, ktere neco zapisuji. Jedine co musi clovek mentalne uchopit je pojem indexu a k cemu je to dobre - ale to se dozvi kazdy programator v prvnim prikladu, kdy ma vytahnout z databaze vsechny faktury s datumem XX.XX.ZZZZ.

B)
jestli tomu rozumim, tak ten rozpor na ktery upozornuji - totiz SQL je jednoduchy koncept versus SQL nikde nefunguje poradne - vysvetlujetezrovna tak  jako nekolik ostatnich kolegu tim, ze uroven lidi v IT je spatna?
Ale co proti tomu delat? Udelat si lepsi lidi?
Nebylo by skutecne mozne, ze ta SQL technologie nastavuje prece jenom pro siroke vrstvy prilis vysokou latku?

25

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 20. 04. 2021, 12:22:53 »

kdyz uz se ta diskuze rozbehla obecnejsim smerem, tak bych taky rad na neco upozornil.

Mnozi, kteri zde jiz desetileti ctou si jiste vsimli, ze pan Stehule a ostatni relacni evangeliste neustale hovori o tom, jak jsou relacni databaze bezvadne a jak je to vlastne jednoduche. A v dalsi vete pak poznamenaji, ze kazdy den chodi k zakaznikum a opravuji u nich ty spatne navrzene modely, doplnuji chybejici indexy a jsou zdeseni, ze obrovska vetsina uzivatelu  neni s to napsat i jednoduchy prikaz s nejakym joinem. Jak pan Stehule zde v diskuzi uvedl, pred nedavnem u zakaznika zrychlil chod rel. databaze 50x. To je zajimave, predstavte si, ze pouzivate produkt, jehoz jedna zakladni vlastnost se muze i 50 x lisit.
Ja si myslim, ze tady neco skutecne nehraje. Budto je ta technologie tak spatna, ze vetsina uzivatelu/programatoru neni schopna ty relacni databaze rozumne pouzivat a nebo je to skutecne tak jednoduche a slo by to naucit, ale ta technologie vyzaruje jakousi karmu, ktera odrazuje i ty, kteri by se to naucit chteli.
Presto je mozno na zaklade diskuze odpovedet tazateli nasledovne:
- at uz se zvoli jakakoliv jmenovana databaze, tak ten navrh a provedeni bude statisticky mizerne a vykon suboptimalni
- budto to bude statcit a pak je to OK
- nebude to stacit a je treba zavolat ty odborniky pro tu kterou databazi - u postgresql  vime ze existuji minimalne 4 lide
Tazatel tedy musi pouze zjistit, jake kontakty jsou k te ktere databazi k dispozici. Je to vlastne jednoduche.