Příspěvky

271

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 06. 10. 2019, 13:12:41 »

Jasně, a ta moje teze se projevuje tím, že jsem byl <a href="https://forum.root.cz/index.php?topic=21909.msg317937#msg317937" rel="nofollow" class="bbc_link" target="_blank">první, kdo tu explicitně napsal

To sice ano, ale pak jsi to hned zabil nesmyslným trváním na tom, že jeden způsob negace je lepší.

. Ale to bychom pak <tt class="bbc_tt">INNER JOIN</tt> nepotřebovali,

Potřebovali.
 Protože je třeba odlišit variantu záznam existuje, ale je NULL a záznam
 neexistuje, což je případ, který se vyskytuje hodně zřídka a je normální DB navrhovat tak, aby pokud možno toto nebyl rozdíl - protože defakto oba stavy jsou reálně pochopitelné jako "neurčeno" a

- pokud mají sémantickou odlišnost, pak musí být explicitně vysvětlena, struktura není samovysvětlující. Navíc se s takovou databází pracuje špatně, právě kvůli výsledným problémům s negací. V takovém případě je daleko vhodnější sémantickou hodnotu: záznam je,ale je "nejasný" zachytit nikoli hodnotou NULL, ale nějak jinak.Samozřejmě asi se dá najít speciální příklad, kdy takový návrh bude mít opodstatnění, ale to je takový výjimka, že točit se na něm při řešení evidentně triviálního případu je poněkud demagogické.
- a pokud nemají sémantickou odlišnost, pak je chyba návrhu, že jedna skutečnost může být postihnuta různými stavy v DB.
Proto nepovažuji Miroslavovy dotazy za chybu - prostě předpokládal standardně rozumně navrženou databázi. Pokud naopak na těchto drobných odlišnostech bazíruješ, tak by to mělo být pro Tebe důvod k zamyšlení, nad jak kvalitními strukturami DB jsi zvyklý pracovat.

A pokud tedy opravdu na distinkci výše nezáleží, pak použití INNER/OUTER JOINu je na programovacím stylu. Jak Tvůj argument (že v raritním případě může dojít k sémantické odlišnosti), tak Miroslavova (že se to lépe upravuje při změně sémantiky) je validní, ale Miroslavův argument je daleko více "z praxe".

Já jsem ale neuváděl tenhle případ. Já jsem uváděl příklad „bydlí v Praze“ × „bydlí mimo Prahu“.

Ne, ty jsi uváděl "Bydlí v Praze" a tvrdil jsi, že jediná přirozená negace je "Bydlí mimo Prahu". Což prostě v totmo případě opravdu není pravda. Když odpovím na "Bydlíš v Praze?" "Ne", tak tím nijak nevylučuji to, že jsem digitální nomád a nebydlím nikde.

Já jsem jenom uváděl příklady, že v přirozeném jazyce znamená negace často něco jiného než prostý doplněk množiny.

Ne, jen ses o to snažil a ten příklad se Ti fakt nepovedl. A na základě toho špatného příkladu si vyvozoval obecný princip, "že není správné použít přesnou negaci", který měl zpětně podpořit ten Tvůj špatnej příklad.

272

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 06. 10. 2019, 10:59:07 »

1) Původní zadání je nejednoznačný - právě proto, že normální lidi nemyslej v nulách a jedničkách, tak tím mohou myslet obojí.
Tabulka s allowed může znamenat "právě Ti, co mají dovoleno" (to bývá častější), ovšem i "Ti, co mají právo nějak upraveno oproti jinde získanému standardnímu stavu".
V prvním případě pak dává smysl negace s INNER JOINEm, v druhém s LEFT JOINEM.
 
2) Dobrej programátor proto neiplementuje půl dne něco nejasnýho, ale nejprve se zeptá. Filipova teze, že se to myslelo určitě takhle, a kdo to pochopil jinak je blbej - to je přesně případ programátorský arogance, kterej vede na zbytečnou práci.

3) Když už bych si měl z těch variant vybrat, tak na tezi, že LEFT JOIN umožňuje zachytit obě sémantiky, takže je lepší použít ho a podle dohovoru s klientem popř. poupravit detail má něco do sebe. INNER JOIN bejvá výkonnější, ale dneska si to databáze stejně zoptimalizujou.

4) Ovšem pokud se to vztáhne na reálný problém "kdo kde bydlí", tak opravdu ti, co nebydlí nikde, nebydlí ani v Praze. Tendle příklad se Ti Filipe fakt nepovedl.

5) "Když dostanou zadání „vytvoř dva dotazy, jeden s allowed = 0 a druhý s allowed > 0“
je hezká ale trochu chabá snaha se z toho nepovedeného příkladu vykroutit. O sémantice negace se v zadání vůbec nemluvilo.
A protože Tebou "axiomovaný" způsob jen jeden z dvou možných způsobů negování původního dotazu, tak jde o krásný případ důkazu kruhem: Negace vypadá takto a proto je správné moje chápání negace a proto negace vypadá takto.

273

Bazar / Re:1U 12C/24T, 144GB RAM, 128GB SSD

« kdy: 23. 09. 2019, 12:09:31 »

A co tam je přesně za CPU? (předpokládám, že Xeony, když to má SMT, ale generace?)

274

Hardware / Re:Tip na 12+ LFF server

« kdy: 03. 09. 2019, 19:38:00 »

Podle:https://h20195.www2.hpe.com/v2/getdocument.aspx?docname=c04123238existují pro G8 různý skříně až s 25 SFF dírama.
To je co se týče skříně - ta Tvoje požadavky splňuje.
Druhá věc je řadič. HP 420 i 430 má co vím standardně 2 SAS 4-lanes porty. Takže připojí 8 disků.V některejch serverech je co vím SATA expander přímo v backplane, do některejch bys
buďto ten SAS expander musel dokooupit.
Disky přes SAS expander se nepřipojuje jinejma konektorama, jen prostě SAS expander
se připojí na řadič a z něho by měli jít normální klasický SAS kabely do disků.Řadič vidí standardně všechny připojené disky, není důvod, proč by v takovémpřípadě nemělo jít použít šifrování na řadiči apod.
Druhá možnost je pořídit si separátní víceportovej řadič (popř. druhej řadič,pokud by bylo možno pole rozdělit na dvě). To bude mít lepší výkon(SAS expander bude sdílet konektivitu k diskům), ale bude dražší.

Snad nekecam....

275

Odkladiště / Re:Přípojky dílny na zahradě

« kdy: 07. 08. 2019, 20:22:10 »

" Pri urcitem tlaku sepne kompresor a zacne tlacit:"No a pak jsou dvě otázky?

1) Stačí mi na další práci ten tlak, kdy kompresor sepnul?
Ano - pracuju dál.Ne - pak mám problém i při malé nádobě, pak je na místě seřídit kompresor tak, aby spustil dříve.
2) Stačí kompresor doplňovat dále odebíraný vzduch?Ano - pracuju dálNe - pak mám problém i při malé tlakové nádobě.
Nějak nevidím, jak mi menší tlaková nádoba pomůže....

276

Odkladiště / Re:Přípojky dílny na zahradě

« kdy: 07. 08. 2019, 14:45:26 »

Pokud to rychle odcerpam (coz neni problem treba pri ofukovani), tak se kompresor zapoti aby to dotlakovaval zpatky a pry ho snadno znicim.

Přiznám se, že ne zcela chápu. Pokud jsem schopen odčerpávat více, než je schopen kontinuálně dodávat kompresor, tak jsem schopen odebírat i přesně to, co dodává kompresor. Takže vždy můžu "zařídit", aby jel kompresor nonstop a tedy - pokud mám takovej kompresor, co to nezvládne, kompresor odvařit.
Takže buďto prostě musím mít kvalitní kompresor, nebo se musím "krotit a hlídat", žádnej menší zásobník mi nepomůže.
U většího zásobníku ale - pokud nějak vyřeším regulaci kompresoru, aby nemohl běžet nonstop tak dlouho - si mohu zásobník natlakovat a pak mít větší zásobu, než mi vzduch dojde.

277

Vývoj / Re:Python 3 threading Objasnenie

« kdy: 02. 08. 2019, 13:00:29 »

Python má GIL, v jednu dobu může běžet jen jeden thread, pokud teda funkce (musí to bejt knihovní, nenapsaná, v Pythonu) ten GIL explicitně "neuvolní" na nějakou déle trvající operaci, na kteoru ho nepotřebuje (např. při čekání na IO).

Jen hádám, ale tuším, že problém bude tady - že ty knihovny co používáš si drží GIL a pak se jen ztrácí čas při přepínání kontextu. Jednoduše to zjistíš, když se koukneš (např. top), jestli to vůbec někdy využije více než jedno jádro.

Další možnost je ta, že někdy (vlastně jsem moc nezjišťoval kdy, prostě jsem ji při paralelním výpočtu pro jistotu zrušil vždy) python automaticky nastavuje processu afinitu na jedno jádro. Takže také zkus také zkontrolovat todle (ale myslím, že to problém nebude).

278

Hardware / Re:Architektura procesoru RISC - je to budoucnost?

« kdy: 17. 06. 2019, 19:00:26 »

RISC procesor má omezenou instrukční sadu - tedy jeho instrukce jsou jednoduché. Proto se u nich daleko snáž implementují takové věci jako superskalární provádění instrukcí (více instrukcí za takt), reordering (když jedna instrukce čeká např. na paměť, tak se dělají nějaké další, které na ni nezávisí) a pipelining (rozdělení zpracování instrukce na více kroků, kdy když se od první instrukce zpracovává druhý krok, od druhé se už zpracovává první). Daní za to je to, že program ve zdrojovém kódu je podstatně větší, než u CISC instrukční sady.

U CISC instrukční sady jsou tyto techniky podstatně složitější až skoro nemožné implementovat: instrukční sada je příliš složitá a navíc narozdíl od RISC sady má zpravidla instrukce pracující nejen s registry, ale s pamětí (a to i s nepřímou adresací), což defakto znemožňuje detekci nezávislých instrukcí a navíc dělá provádění některých instrukcí tak dlouhých, že nejde rozumně navrhnout pipeline.
 Proto moderní CISC procesory dělají vnitřní překlad na tzn. mikroinstrukce - defakto na RISC instrukční sadu. Tím kombinují výhody CISC procesorů  (menší paměťová náročnost programů - což vede k rychlejšímu provádění programů, protože se daleko lépe využívají cache paměti) a RISC procesorů (snadná paralelizace).

RISC procesory tedy měli svůj boom spíše v minulosti, kdy ten překlad CISC-RISC byl příliš složitý. (V době, kdy pentia běhala kolem 100Mhz, měla Alfa tuším snad 600Mhz). Dnes jsou CISC procesory výkonnější. Platí za to větší spotřebou, protože mají navíc jednotky na překlad mikroinstrukcí, proto se v malých jádrech zaměřených na spotřebu (mobily etc...) uchytila RISC architektura.

279

Vývoj / Re:Návrh relační databáze

« kdy: 25. 04. 2019, 15:09:19 »

Urvustop: Pokud jde o konkrétní implementaci jednoho cizího klíče do JSONu, kde je problém? V čem je to cesta do pekel? Ten trigger bude mít naprosto jasnou sémantiku, je to obecné, bez problémů rozšiřitelné řešení, pro další vývoj naprosto transparentní (nijak se nelišící od "nativních" FK). Kde je ta cesta do pekel?

===

Fór je v tom, že tato situace nemá dobré řešení. Něco musíš oželit. A furt radši jednou napíšu vlastní implementaci foreign key, abych pak s databází pracoval naprosto standardně, než používal antipatterny typu EAV, nebo ukládání vlastností do políček number01, number02, number03, ani se ti databáze nerozpadá na padesát milionů tabulek, kde řešíš klasické problémy s mnohonásobnými dědičnostmi.

Řešení s JSON a explicitně napsaným triggerem neporušuje žádné databázové paradigma. Řeší problém "řídkých dat" pomocí nástroje na ukládání řídkých dat - a jen si dopíšeš jednu operaci, kterou (zatím) současná verze postgresu neumí.

Jiné zde navržené postupy zpravidla ohýbají relační databáze a práce s takovým systémem bude dřív či později na palici. Protože se snaží nacpat řídké struktury do

plných matic, což prostě rozumným způsobem nejde a ať se to "vobčůrá" jakkoli, tak to bude vždycky jen "vobčůraný". Ať uděláš s kladivem cokoli, na šroubování to bude pořád hodně nešikovnej nástroj.

Filip, Kit:
Grafové a jiné nosql databáze jsou sice dobré, ale do té doby, než s nima chce člověk pracovat v součinnosti s věcma, které má v SQL databázi. Např. proto se prosazují "in-databaze" fulltexty, protože fulltext mimo databázi může být nakrásně rychlejší, lepší a nevím co, ale když chceš kromě fulltextu filtrovat ještě podle dalších X kritérií, tak je to na palici. Navíc rozdělení dat do dvou databází musíš řešit takové lahůdky, jako synchronizace transakcí atd. atd....
A protože se na většinu věcí SQL hodí hodně dobře, zpravidla je lepší cesta používat nosql rozšíření SQL databází - např. ten json sloupec - než data dělit do dvou různých databází, anebo se zcela zbavovat možností SQL (a ukládat vše do noSQL databáze).

280

Vývoj / Re:Návrh relační databáze

« kdy: 25. 04. 2019, 14:22:46 »

Já bych v takovémto případě velmi silně přemýšlel nad kombinací SQL a noSQL přístupu. Tedy objekty všechny v jedné tabulce, a ty variabilní vlastnosti uložené jako json.

Nevím, jak přesně umí MSSQL s json, ale v postgresql se s tím krásně pracuje, včetně indexace.

Jediné, co mne teď napadá, že to z běžných věcí neumí, jsou cizí klíče (na položky jsonu), ale to jde v případě potřeby dopsat trigerama.

281

Hardware / Re:Barevná laserová tiskárna na doma

« kdy: 18. 12. 2018, 22:54:13 »

Vcelku dobrý zkušenosti, ale s malým vzorkem, mám s tiskárnama Brother.
Jedna tiskárna slušně zatížená (potiskla tak 15.000 stran), jedna málo, a obě
bez problémů a s levnejma tonerama.

Doma mám dražší canony (toner na 6000 stran apod.), nejprve ČB a teď
barevnej a zatím spokojenost, ale tisknu málo. Ale na tisk fotek to není....

282

Server / Re:Indexování histogramů v DB

« kdy: 09. 11. 2018, 13:49:19 »

Nechcem ziadne vendor lok riesnie, potrebujem aby som to dokazal implementovat na akejkolvek relacnej databaze.

Tak to máš smůlu, protože pro SQL to je vyloženě nevhodná úloha, jelikož to potřebuje multidimenzionální index.
Máš dvě možnosti, buďto se funkcionality (alespoň co se týče real-time výpočtu) vzdát, anebo použít nějaké rozšíření SQL, kde vždycky bude vendor lock-in.

Osobně bych Ti radil to druhé, protože vendor-lock na postgres ničemu nevadí: je to opensource databáze a navíc z opensource nejlepší.
Tedy jestli někdy budeš chtít migrovat, tak není důvod migrovat na jakoukoli jinou opensource databázi. A jestli někdy budeš migrovat na nějakou proprietální drahou databázi, tak přepsat tendle kousek kódu je to nejlevnější, co budeš řešit...
PS: Samozřejmě můžeš udělat nějaké "heuristické algoritmy", např. najít si nejlepší shodu pro každou barvu a ořezané výsledky seřadit dle vypočítané shody už na omezeném datasetu, ale pokud to chceš dělat pořádně a rozumně rozšiřitelně a použitelně, tak se těmdle polovičatejm řešením vyhni.

283

Studium a uplatnění / Re:Zkušenosti se společností OKsystem

« kdy: 10. 09. 2018, 11:42:49 »

Nikdy jsem tam nedělal, ale znám několik lidí, co tam dělaj - sice převážně na neprogramátorskejch pozicích - a jsou tam spokojený.

284

Hardware / Re:Zkušenosti se 4k monitory 40"+

« kdy: 07. 09. 2018, 12:33:26 »

Ten philips mám, burn-in je při zkoumání znatelný, ale při běžné práci o něm nevím. Anžto mám "zatemníno", tak problém s lesklostí není, ale chce to dát pozor na to, kde monitor bude. Oproti předchozí skladně 24" 1920x1200 + 20" 1600x200 výrazný krok vpřed, takže doporučuju.

285

Hardware / Re:Pořízení obřího monitoru pro vývoj

« kdy: 03. 06. 2018, 17:59:22 »

Doma mám 4k, v práci 24" + FullHd notebooku. Doma se mi pracuje lépe. A to nedělám žádný monstrózní projekty, jen prostě se mi líp přeskakuje mezi oknama co zrovna používám a nemusím řešit, co pod čím zrovna mám....