Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Nejde třeba použít Postgres která umí fungovat i jako NoSQL, JSON a timeseries databáze (nemám zkušenost)? Kombinujete to někdo takto u Postgres?Jde. Já mám v tomto aktuálně dobrou zkušenost u MSSQL. Ostatní na tom budou stejně.
IKEA?Ten neznám, sem s ním
V objektovém obchodu s vánočními stromky ukážete na stromek, který chcete, vezmete, zaplatíte, odejdete.
V relačním obchodu jsou v jednom rohu opřené kmínky, každý z nich má číslo a v sobě díry pro větve, kdy každá díra má malinkaté čisílko. O kus vedle je na zemi hromada větví, každá větev má číslo a na sobě mnoho malých čisílek - vy si musíte vyhrabat ty s odpovídajícími čísly z vybraného kmínku. Ještě o kus dál je veliká krabice s jehličím, kdy každá jehlička má opět číslo - vy opět hledáte jehličky odpovídající čisílkům na větvích. Když to všechno dohledáte, stromek sestavíte, zaplatíte, odejdete.
To řeším tak, že tomu systému přidám hint. Takže když mám pole struktur, tak defaultně mi z toho vytvoří defaultní relaci. Ale mohu dodat informaci, že lepší je tato startegie. Výhoda SQL je ten matematickej aparát, kterej problém extrahuje do několika málo strategií (v základu šesti). S čímž se přirozeně lépe pracuje, než s "libovolností" u jiných řešení.Protože zatímco v SQL máš danej formát rozpadnutí na relace, kterej je pro danou "logickou strukturu" jeden,Což je super věc. Protože následně můžeš udělat nástroj, který ti rozpadnutí na relace udělá za tebe. Takže máš výhody obou světů.
Tak jednoduché to není. Síla RDBMS je ve výkonu, a totéž se dá řešit různými způsoby s odlišným dopadem na výkon v různých situacích. Informace může být v tabuli, může být napojena vazbou, může být uložena jako pole (nebo obdobný komplexní typ) v tabuli... Míru rozpadnutí do vazeb nástroj nerozhodne, protože to rozhodnutí se opírá o předpokládaný způsob užití a požadavek výkonu při různých operacích.
pak by opravdu nebyly RDBMS potřeba.RDBMS je potřeba. Přece to engine nebudu psát znova!
Protože zatímco v SQL máš danej formát rozpadnutí na relace, kterej je pro danou "logickou strukturu" jeden,Což je super věc. Protože následně můžeš udělat nástroj, který ti rozpadnutí na relace udělá za tebe. Takže máš výhody obou světů.
Jaká Schrodingerova kočka? Jakej důkaz? Důkaz čeho? Se obávám, že ti vůbec nerozumím.Co takhle?
A dukaz pro to mas? Nebo to je tve prani aby to tak bylo? Pripadne bych prosil zdroj. Protoze ty jsi z toho udelal Schrodingerovu kocku ted.
Co vsak ale musim udelat (resp. jeste pred 3 lety (v javascriptu pravek?) jsem musel udelat) v te dobe v nejpopularnejsim frameworku na svete, v Reactu, je tenhle strasny a sileny hoven:Je to tak. V čem je problém? React ctí funkcionální paradigma. Má to své výhody i nevýhody. Určitě by se nějaká ta syntax dala vylepšit. Ale skutečnost, že vytvoří nový celý objekt je očekávané a požadované chování.
...
Tzn. musel bych kompletne vytvorit znovu cely objekt, aby to bylo jak to React vyzaduje.
Jak jako ze vytvori? To TY MUSIS VYTVORIT cely novy chain objektu od korenoveho az po ten nejvice nested kteremu jsi modifikoval value.
A jak jako ze cti funkcionalni paradigma, co to s tim ma spolecneho? To ze nezaobali state, a neumi si automaticky nasledne zjistit co presne se mu zmenilo, nema nic co spolecneho s funkcionalnim paradigmatem, to je proste jen strohost a spartanskost te knihovny.
Btw tak jak se to dela ve vue, tak z pohledu vyvojare to tak bylo i u desktopovych UI. Stacilo naprimo zmenit nejake field a hotovo. To k cemu nutu react je uplne brutalni overkill. Porad nemuzu uverit svym ocim, nechapu proc tohle chteji vsichni pouzivat.
Jako s tim Reactem se realne nejak neda dela DDD, protoze bych pro modifikaci kazdeho jednoho fieldu v domene snad musel mit udelany vyse uvedeny straslivy setState
Stacilo naprimo zmenit nejake field a hotovo.Tohle my nechceme dělat. A na tobě je zjisit proč to nechceme dělat, jaké k tomu máme důvody.
Nasledne, co ocekavam ze muzu udelat:Kód: [Vybrat]myDomain.zaznamyPotravin
.filter(zaznam => zaznam.datum === '1.2.2021' && zaznam.potravina.nazev === 'ryze')
.forEach(zaznam => zaznam.mnozstvi = 50);
A dojde k automatickemu promitnuti teto zmeny do vykreslene instance komponenty TabulkaZaznamu:
Co vsak ale musim udelat (resp. jeste pred 3 lety (v javascriptu pravek?) jsem musel udelat) v te dobe v nejpopularnejsim frameworku na svete, v Reactu, je tenhle strasny a sileny hoven:Je to tak. V čem je problém? React ctí funkcionální paradigma. Má to své výhody i nevýhody. Určitě by se nějaká ta syntax dala vylepšit. Ale skutečnost, že vytvoří nový celý objekt je očekávané a požadované chování.
...
Tzn. musel bych kompletne vytvorit znovu cely objekt, aby to bylo jak to React vyzaduje.
.... 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 .... ?
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
git rebase --rebase-merges
možná udělá to co chcete. Já to tedy používám v situaci kdy chci nějaké merge pushnout do masteru a zjistím že mezitím do masteru ještě pushnul někdo jiný - a pak chci jen své merge posunout a ne je "klasicky rebasnout".
Mám Thunderbird a imap.seznam.cz:993 SSL/TLS (heslo, zabezpečený přenos) mi funguje u mailu na seznamu i vlastní doméně. Odchozí pošta to samé, akorát port 465. Autorizace v obou případech celým mailem a heslem.A google účet ti jde? Co máš za verzi TB?
I tak by se musel naučit:
- SQL
- principy normalizace/deduplikace/optimalizace (jak se tomu souhrně nadává?)
- procedůry
- git/správu zdrojáků
- programovací jazyk
- testovat svůj kód
- návrhové vzory (to z jedné knížky nedá)
- pochopit princip spousty technologií
- naučit se mrtě knihoven
A nechceš si napsat prototyp, ať se máme nad čím bavit?Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.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.Nevím, jestli přímo ve Smalltalku, ale určitě by to bylo zajímavé.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.
