Příspěvky

616

Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?

« kdy: 07. 09. 2018, 22:53:46 »

Ta tabulkova evidence v dobach kartotek mela stejnou motivaci jako ty databaze: "Rychle se dostat k datum ktera chci".

Ne vždy byla důležitá „rychlost hledání“. Třeba pro účetní záznamy je přirozené zapisovat je chronologicky tak, jak přicházejí – A to zrovna rychlosti hledání často nepomáhá. Proto se pak ty záznamy přepisovaly v jiném uspořádání – ale zase do tabulek.

OK to jsem asi prilis zjednodusil.

Videl jsem v nedavne dobe dve aplikace (jedna stara 20 let, druha relativne moderni) u obou byla databaze vlastne jen datastore a synchronizace mezi nody. Jakmile se data vytahla tak se pracovalo se stromovou strukturou v pameti a v db byl lock az do doby nez se uzivatel rozhodl ukladat.

To, že se někde používají stromové struktury, přece ale neznamená, že se používají všude, ani že nikde nejsou data přirozeně uspořádaná do tabulek.

Ano,ale tady mi na prvni pohled prislo, ze by davalo smysl vyuzit databazi prave kvuli konzistenci dat a transakcim.
A zajimala by me motivace architekta k takovemu reseni. A protoze jsem videl toho Boba povidat o necem podobnem tak mi to vrta v hlave a snazim se prijit na to co bud ja nebo Bob a ty dva architekti nevidime. (BTW. jsou fakt dva ruzni, kazdy jina narodnost a kazdy v jine bance)

Obe to jsou bankovni aplikace a podle me obe jsou ten typicky use case evidence (ucty, firmy, osoby...).

To by mne zajímalo to konkrétní použití. Jasně, někdy jsou to třeba spíš dokumenty s nějakými vazbami – třeba firma, ta má nějaké vlastnosti, na firmu jsou navázaní lidé, ti mají zase nějaké vlastnosti. Ale třeba evidovat finanční transakce ve stromové struktuře mi moc smysl nedává.

Credit risk management. Nejde o nejake real time transakce, spis kalkulace rizika spojeneho s poskytnutim pujcky.
Takze se ukladaji produkty, zaruky, data o firmach, platebni historie, ...
Odhadem je tam asi 500 tabulek. 

617

Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?

« kdy: 07. 09. 2018, 22:29:50 »

Na jednu stranu jsem rad, ze se ozval odbornik. Na druhou stranu prave kvuli tvemu hobby muze byt tvuj nazor zkresleny.

Proč by relační tabulkové databáze měly zahynout? ...

Vubec nerozumim tvemu zpusobu diskuze.

618

Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?

« kdy: 07. 09. 2018, 22:01:08 »

Vlastnosti rotačních disků (rychlé sekvenční čtení, pomalé čtení s náhodným přístupem) byl asi jen jeden z faktorů proč se rozšířily relační SQL databáze.

1. Relace (tabulky) jsou vlastně množiny, což je jednodušší abstrakce než stromy (grafy). 1D tabulka má tu výhodu, že se s ní dobře jednoduše mentálně pracuje. Když pracujete s fakturou, zajímají vás položky faktury a už vás nezajímají složky, kde je faktura zařazena. Pokud pracuji s fakturami, tak mne nezajímají položky faktur, atd. Relační model není tak obecný jako síťový, ale je dostatečně silný, a velice jednoduchý.

2. Relační databáze byly navrženy pro uživatele - umožňují neprogramátorům pracovat s daty. Tuto vlastnost konkurenční systémy nikdy ve větším měřítku nenabídly - a je to dáno možnostmi a názorností a jednoduchostí relačního modelu. Ono ručně pracovat se stromy pro laika není to pravé ořechové.

3. Relační model byl doplněný o SQL - opět jednoduchý, ale dostatečně silný nástroj. A standardizace, byť ne vždy dokonalá je neskutečně silný nástroj. Pokud umíte pracovat s Mongem, umíte pracovat s Mongem, ale už nikoliv s čímkoliv jiným. Pokud umíte SQL, tak vytvoříte tabulky a dotazy na Oracle, MSSQL, MySQL, Postgresu, SQLite. Na určité úrovni nemusíte řešit detaily a základy jsou stejné. Univerzální dotazovací jazyk nabídly pouze relační SQL databáze. Resp. byly pokusy i u dalších modelů, ale bez výraznějšího rozšíření.

4. Tabulka je implementačně halda. Struktura, která se jednoduše implementuje. Navíc v kombinaci s indexy, kterých můžete mít k haldě tolik kolik potřebujete můžete mít rychlý přístup přes různé atributy. Halda (případně pole) je velice efektivní struktura. Na uložení stromu potřebuje výrazně více paměti.

Ve výsledku je důležitá abstrakce a SQL. Obojí umožňuje pracovat s daty komukoliv. Jestli v reálu data budou uložená na SSD nebo v RAMce, jestli budou uložená v poli, v hash mapě nebo v nějaké stromové struktuře je úplně jedno .. v momentě, kdy bude dost RAM, abych data uložil na disk. Co vždy ale bude důležité, že kdokoliv, kdo má práva a trochu znalostí se může na data podívat z Excelu, z libovolné aplikace a není omezen programátorem.

Hmm tak ted nevim... :-)
Na jednu stranu jsem rad, ze se ozval odbornik.
Na druhou stranu prave kvuli tvemu hobby muze byt tvuj nazor zkresleny.

Neuvedomuju si, ze bych potkal uzivaka kterej by umel aspon zaklad SQL, nebo si napojit excel na databazi.
Mozna mam jen smulu.

619

Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?

« kdy: 07. 09. 2018, 21:54:54 »

Maji tabulkove databaze na novych projektech smysl?

Zavisi od projektu. Uz jen z povahy tveho dotazu vyplyva, ze si s daty neuzivas moc dlouho. ...

Definuj dlouho :-)

620

Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?

« kdy: 07. 09. 2018, 19:47:59 »

A neměl on na mysli náhodou "big data"?
Jako když budu sledovat výskyt osob na strategických uzlech infrastruktury, přičemž identifikaci budu dělat jen z obrazu kamer a dejme tomu metadat z telefonů, tak si umím představit že SQL nebude optimální nástroj. Ale nenapadá mě, proč by nemělo být vhodné u pěkně strukturovaných dat.

Myslim, ze nemel na mysli big data. Mluvil o tom dost obecne.
A kdyz si vezmu treba hibernate tak to je typicky priklad, ktery dela z tabulkovych dat v databazi stromecky(mozna spis obecneji - grafy). A pouziva se i na aplikace s malym mnozstvim dat. *batis vlastne taky.
Cizi klice jsou reprezentovany jako reference na jine entity...

621

Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?

« kdy: 07. 09. 2018, 19:41:17 »

Mimochodem, řada SQL databází chodí v paměti. Někdy se prostě server nacpe takovým množství paměti, aby databázový stroj měl celou databázi načtenou v RAM jako v keši. Je to asi nejrychlejší řešení, pokud je hromada čtení. Jak to urychlí SSD? Bude rychlejší než RAM?

On v tom videu vlastne rika, ze SSD je takova persistentni RAM. Nicmene.. Pokud mam tolik pameti, ze v ni vsechno udrzim, existuje duvod proc to organizovat do tabulek?

622

Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?

« kdy: 07. 09. 2018, 19:36:35 »

Různé evidence (účetnictví, sklady, osoby) se tabulkově evidovaly dávno před databázemi, a ani dnes se z toho žádné stromy nevytváří. Takže bych řekl, že tabulkové databáze stále mají smysl. Ono totiž větší množství dat najednou ani moc jinak než tabulkově prezentovat nejde, takže pro lidi ta tabulková prezentace pořád bude přirozená, čemuž se pak samozřejmě podřizuje a systém evidence (její organizace – nezávislá na IT), a pak je přirozené takový systém reprezentovat v tabulkových databázích.

OK, ale...
Ta tabulkova evidence v dobach kartotek mela stejnou motivaci jako ty databaze: "Rychle se dostat k datum ktera chci".

Videl jsem v nedavne dobe dve aplikace (jedna stara 20 let, druha relativne moderni) u obou byla databaze vlastne jen datastore a synchronizace mezi nody. Jakmile se data vytahla tak se pracovalo se stromovou strukturou v pameti a v db byl lock az do doby nez se uzivatel rozhodl ukladat. Obe to jsou bankovni aplikace a podle me obe jsou ten typicky use case evidence (ucty, firmy, osoby...). Fungovalo to prekvapive dobre a je to jedna z pricin proc o tom premyslim. Kdyby se u nich zahodila ta databaze a serializovalo se to na file system treba jako xml tak by to mohlo byt i rychlejsi, protoze by se eliminoval network overhead.

623

Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?

« kdy: 07. 09. 2018, 19:17:40 »

Od doby vzniku toho videa nosql hype castecne odeznel.

Myslim, ze kdyz ma nekdo takovou praxi jako on tak uz ma vuci hype imunitu.
Je to videt i v tom videu kdyz srovnava ruzne jazyky.

624

Vývoj / Mají tabulkové databáze v dnešní době smysl?

« kdy: 07. 09. 2018, 18:00:57 »

Ahoj,
nedavno(a dneska znova, abych to nasel) jsem koukal na povidani strycka Boba o S.O.L.I.D. principles:
https://www.youtube.com/watch?v=t86v3N4OshQ

Vetsinu casu povida o jinych vecech, ale poutave takze dopurucuji.

Jedna z tech "jinych" veci, kterou zmini je ve strucnosti(asi od 54 minuty):
"Tabulkove databaze vznikly kvuli pomalym rotacnim diskum a v dnesni dobe kdy mame velka a rychla SSD ztraci smysl"

Mluvi o tom, ze tabulkove usporadani dat je pro programatory nepohodlne a ze stejne vetsinou z databaze data nacteme a vyrobime si z nich nejake stromy atp. se kterymi se nam dobre pracuje.

Dokonce rika: "If I were a database company right now, if I were Oracle, i'd be scared to death."

To video je 3 roky stare a ja porad vidim jak se na novych projektech Oracle nasazuje.
Vim, ze minimalne v korporatech se tabulkove databaze udrzi jeste dlouho.
Stryka Boba(kdyz odhlednu od politiky) respektuju, ale tady vaham.
Nezda se mi, ze by mel pravdu, ale na druhou stranu nenachazim argument ktery by sel proti te jeho uvaze.

Tak se chci zeptat:
Maji tabulkove databaze na novych projektech smysl?
Migroval nekdo z vas existujici reseni z oraclu nebo jine tabulkove databaze na neco jineho?
Souhlasite, ze rychlost/pomalost rotacnich disku je jediny duvod proc takove databaze existuji?

Diky za nazory

625

Vývoj / Re:Čisté OP Smalltalk, Objective-C

« kdy: 06. 09. 2018, 13:38:09 »

3. Má zmysel učiť sa smalltalk? čo mi to prinesie oproti bežným objektovým jazykom. Je vývoj v Smalltalku rýchlejší alebo kde je jeho hlavná výhoda.

Jo, a ještě jedna věc: Implementrace Pharo má výborný debugger, ve kterém je možno rovnou doplňovat metody (což jde skvěle dohromady s TDD, kdy při testu vyletí chyba na neexistující metodu), nebo "jen" opravovat chybu, vyčíslovat výrazy, opakovaně znovuspouštět metodu, dokud to nejede. Někdo možná řekne: "To je zbytečné." Ale když podvacáté v nějakém jazyku opravujete chybu, pořád to není ono, a vy musíte 20krát znovu aplikaci (nebo alespoň její kus) přeložit a dolézt znovu na místo chyby, tak vás to začne PĚKNĚ SRÁT. Nevím o jiném jazyku/implementaci (to neznamená, že neexistuje), který by tohle uměl.

Smalltalk ani Pharo neznam takze si nejsem uplne jisty jestli je to totez, ale podle me tohle umi kazdy jazyk kde je REPL.
Takze nejspis vetsina dialektu lispu, s jistymi ustupky asi python, javascript, haskell a kdyz budu mit hodne fantazie tak i shell. Ostatne od Java 9 mame i jshell takze i tam by se o tom dalo mluvit.
Prakticky to pouzivam jen v clojure a emacs lispu takze u ostatnich si nejsem jisty jaky tooling je k dispozici a jak pohodlne se s tim pracuje, ale kdyz musim nekdy pracovat bez REPLu tak se mi chce brecet.

626

Vývoj / Re:Typový system versus unittesty

« kdy: 21. 08. 2018, 12:40:41 »

Kód: [Vybrat]

*../idr/test> :t mysubstr
mysubstr : (p : Nat) -> (n : Nat) -> Vect (p + (n + more)) t -> Vect n t
*../idr/test> mysubstr 1 2 [10,20,30,40]
[20, 30] : Vect 2 Integer
*../idr/test> mysubstr 3 2 [10,20,30,40]
(input):1:15-16:When checking argument xs to constructor Data.Vect.:::
        Type mismatch between
                Vect 0 elem (Type of [])
        and
                Vect (S more) t (Expected type)
        Specifically:
                Type mismatch between
                        0
                and
                        S more

<3

Trvalo mi asi 10 minut nez jsem to pochopil, a pak jsem musel dalsich 10 minut rozdychavat ten naval endorfinu 

627

Vývoj / Re:Typový system versus unittesty

« kdy: 20. 08. 2018, 16:38:22 »

Ja jako programator nemuzu ve vysokourovnovem jazyce optimalizovat na nizke urovni.

Můžete. I u toho vysokoúrovňového jazyka můžete mít zaručené, že pole ten jazyk ukládá jako jednotlivé prvky v paměti vedle sebe. Takže když použijete pole primitivních hodnot, nejde se vám do řádku cache několik hodnot. Když použijete spojový seznam, bude každá položka uložená v paměti někde jinde a procesor bude při průchodu kolekcí pořád jen čekat, než se nahrají data z paměti. A tohle je třeba rozdíl mezi java.util.ArrayList a java.util.LinkedList. Připadají vám Java, Scala nebo Clojure jako dostatečně vysokoúrovňové jazyky? Ano, Java je jen assembler nad bajtkódem, ale stejně…

ArrayList v jave bude vedle sebe ukladat jen reference. Kdyz chci hodnotu tak stejne musim hledat nekde v halde.

628

Vývoj / Re:Typový system versus unittesty

« kdy: 20. 08. 2018, 16:13:43 »

Zde bych si dovolil nesouhlasit.

Právě expresivnost jazyka nám, minimálně teoreticky, dovoluje agresivně optimalizovat. Tudíž se docela dobře na tu úroveň cache můžeme dostat.

Příklad: mám kolekci objektů, u které si kompilátor z typové signatury odvodí, že jsou imutable, tak mohu nejenom neřešit zámky, ale klidně můžu tu kolekci umístit na stacku, nebo ji inlinovat/rozkopírovat. Mě, jako uživatele to nezajímá, a kompilátor má volné ruce.

Puvodne jsem tam mel napsany cancy o tom jak kompilator to zoptimalizuje daleko lip nez ja bych kdy dokazal.
Ale pak sem si predstavil jak mi tu nekdo napise, ze to ze ja sem lama neznamena, ze ostatni to taky neumi, a moje ego mi nedovolilo to postnout ;-).

Ale myslenka zustava stejna. Ja jako programator nemuzu ve vysokourovnovem jazyce optimalizovat na nizke urovni.
Musim spolehat na kompilator. A asi je to vetsinou dobre (v mem pripade urcite  :-D)

629

Vývoj / Re:Typový system versus unittesty

« kdy: 20. 08. 2018, 15:24:27 »

Myslel jsem, ze na tom scitani uz jsme se dohodli ze performance rozdil nebude.

Nikoli, to byla pouze vaše chybná domněnka, kterou jsem vyvrátil.

Kde? Asi jsem prehledl...

Mozna neco prehlizim. Priklad?

Procesor nemůže pracovat s daty přímo, pracuje s tím, co má v registrech nebo nejbližší cache. Ta cache není moc velká, data do ní se tahají z pomalejší vzdálenější cache, z ještě pomalejší RAM nebo z ještě pomalejšího swapu. Aby procesor na data zbytečně nečekal, pokouší se odhadnout, jaká data budou potřeba, a ty načítá dopředu. Pokud tedy bude způsob procházení kolekce pro procesor předvídatelný, dokáže data včas přednačítat a jejich zpracování bude mnohem rychlejší, než když bude procesor každou chvíli na data čekat.

Navíc dnešní procesory jsou vícevláknové, a zrovna sumace se dá dobře paralelizovat – každé vlákno sečte část kolekce a na závěr se sečtou dílčí součty. Akorát z výše uvedeného důvodu je potřeba, aby každé vlákno zpracovávalo ucelený blok kolekce – tj. první vlákno třeba prvních 16 prvků, druhé vlákno dalších 16 prvků atd. To iterátor neumožňuje, ten by cpal jednotlivé prvky vláknům napřeskáčku (a ještě by se musel mezi vlákny zamykat).

To je ale dost nizkourovnova zalezitost. Myslim, ze v jazycich vyssi urovne s tim stejne moc neudelame, protoze jsme tak daleko abstrahovali od HW, ze nemuzeme optimalizovat na urovni l1 a l2 cache.
To je dan kterou platime za expresivnost jazyku.

To aby to selhalo pri prekladu na 486 a fungovalo jinde prece nezalezi na tom jestli 486 existuje nebo ne.

Ale ono to nemá selhat při překladu na 486. Má to selhat při překladu kdekoli, pokud by to např. na 486 selhalo při běhu. BoneFlute přece chtěl, aby se jakákoli chyba odhalila už při překladu, ne až při běhu testů.

Jmeno toho vlakna naznacuje, ze jde o srovnani toho co jde a nejde udelat typy vs unit testy.
Takze nevim jak BoneFlute, ale za me:
Az uvidim unit test ktery pri behu na Xeonu zahlasi ze dana funkce selze na 486 zacnu resit jak je mozne, ze tohle nedokaze typovy system.

630

Vývoj / Re:Typový system versus unittesty

« kdy: 20. 08. 2018, 14:29:49 »

A optimalizaci prochazeni kolekce to nepotrebuje. Tu zajisti ten iterator.

Nezajistí, protože iterátor neví, jak je výhodné procházet kolekci z pohledu sumační funkce. Vždycky je to něco za něco. Buď můžete mít obecné API, které můžete používat opakovaně, ale za cenu horší optimalizace. A nebo můžete mít kód, který jde až na dřeň toho, co jde z hardwaru vyždímat, pak ale musíte rezignovat na abstrakci a univerzální rozhraní.

Iterator zajisti optimalni prochazeni kolekce. Myslel jsem, ze na tom scitani uz jsme se dohodli ze performance rozdil nebude.
Mozna neco prehlizim. Priklad?

BoneFlute uz tu popisoval jak to zaridit pri kompilaci na te 486.
Namitka byla pokud vim, ze 486 neni v dobe prekladu k dispozici.
Takze kdyz zjistim, ze mam pozadavek aby to bezelo na 486 tak si nejakou sezenu a zkusim to na ni zkompilovat.
Stejne jako u toho testu, ktery zkusim na nejake pustit.

Ale BoneFlute přece chce, aby bylo vše kontrolované v době překladu, tedy ty informace v typech musí být už v době překladu. Bez ohledu na to, zda nějakou 486 máte nebo nemáte k dispozici, a dokonce bez ohledu na to, zda nějaká 486 už byla či nebyla vytvořena. Když to tam mít nebudete, musíte v typu povolit něco jako „neznámé“, a tím povolíte to, čemu se chtěl BoneFlute vyhnout.

To aby to selhalo pri prekladu na 486 a fungovalo jinde prece nezalezi na tom jestli 486 existuje nebo ne.