Příspěvky

106

Hardware / Re:PC sestava pro grafickou práci (Adobe)

« kdy: 23. 06. 2021, 22:38:11 »

V roku 2021 mu radíte stroj s Intelom?, srsly?

Na Adobe určitě Intel ano.

107

Hardware / Re:PC sestava pro grafickou práci (Adobe)

« kdy: 23. 06. 2021, 17:04:17 »

Díky. Rozpočet zjistím. Zajímalo by mě, které PC komponenty jsou pro práci s grafickým softwarem klíčové?

Překvapivě CPU, RAM, GPU, SSD.
Ale aby to nebylo nekonkrétní, Adobe vydává seznam požadavků, vč. podporovaných GPU, např. pro Photoshop:
https://helpx.adobe.com/cz/photoshop/system-requirements.html

108

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

« kdy: 23. 06. 2021, 14:03:50 »

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.

S trochou nadsázky by se dalo říct, že "stejně blbě" jako NoSQL databáze by to mohl udělat i nástroj (ostatně, ORM), a pak by opravdu nebyly RDBMS potřeba.

109

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

« kdy: 23. 06. 2021, 10:40:31 »

Tato diskuze ztratí veškerý smysl ve chvíli, kdy bude jen na uživateli, jaký model použije.

No já vidím takový fundamentální problém. Objektové databáze mohou teoreticky dosahovat stejných výkonů, jako relační. Jenže, aby toto opravdu nastalo, bylo by potřeba objekty a vlastnosti popsat tak definitivně, že by si takový popis svojí složitostí nezadal s relačními databázemi.

Jestli má tato diskuse smysl, tak podle mě naopak jedině ve chvíli, kdy se bavíme o rozdílech, mezi kterými lze volit.

Ono je ve skutečnosti jedno, jestli stejné vazby a principy manipulace s daty popíšete v SQL, nebo objektově. Bude se lišit řeč zápisu, ale jinou řečí budete popisovat totéž. Jestli mají objektové databáze nějakou výhodu, tak je to právě v tom, že pro spoustu úloh se dá zápis zjednodušit o popis toho, co RDBMS vyžadují (řekněme "zbytečně") a naopak se zaměřit na popis vlastností, které se v RDBMS zapisují složitě.

110

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

« kdy: 23. 06. 2021, 09:42:05 »

...

Tak jistě, to co tady píšete, je pravda.
V praxi není problém v tom, že by jeden nebo druhý přístup byl lepší. Většinou to hapruje na tom, že výběr technologie se nečiní kvalifikovaně, provádí ho někdo jiný, než ten, kdo má představu o budoucnosti projektu. Dost často ho dělá i ten, který nezná oba přístupy a jejich výhody a nevýhody.

Dohady v diskusích vnímám spíš tak, že spousta lidí (a já mezi ně patřím) považuje za bezpečnější a potentnější přístup, aby programátor nejprve na slušné úrovni ovládl RDBMS a pochopil, že skládat jehličky do větviček a do stromku nemá jen nevýhody, ale i výhody. Aby v budoucnu mohl kvalifikovaně posoudit, na co se hodí jaká technologie. Mezistupeň v poznání jsou ORM, u kterých taky pochopí další výhody a nevýhody. Tento postup je dialektický.

Proti tomu velmi často najdete programátory, kteří RDBMS neznají - maximální poznání u nich končí u joinu v mysql a jeho výkonnostních problémů. Jestli vyžadují ACID neumějí zodpovědět, ve skutečnosti ani fakticky neznají důležitost takové otázky, maximálně definici z papíru. S takovými je pak těžko diskutovat, radit a rozebírat jejich otázky typu "jakou databázi mám zvolit". Kdyby ty základní zkušenosti měli, nepoložili by takovou fundamentální otázku. Když ty znalosti nemají, je (myslím si) lepší začít od rozumných základů poznání.

To si můžete povšimnout i zde, na rootu, že když se někdo orientuje a potřebuje prodiskutovat jen nějaký technický detail nebo zkušenost, diskuse jsou věcné. Zvrtnou se ve většinou jen ve chvíli, kdy se ukáže, že na začátku asi stojí nějaký chybný úsudek. Většinou to pak končí tím, že tazatel je zklamán, že na špatnou otázku ve špatně nastavené situaci nedostane dobrou odpověď, která by vyřešila všechna trápení světa.

111

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

« kdy: 22. 06. 2021, 20:03:29 »

Jáááááj, to jsem nevěděl, že tohle se svojí db nemůžu dělat  tak snad abych takovou funkčnost ze svých projektů odebral no....   

Ale jo, jen se ta databáze kurevsky nadře ve srovnání s relační.

112

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

« kdy: 22. 06. 2021, 19:29:05 »

...

Chtěl jsem napsat něco podobného. Někdo myslel na dobrý, jednoduchý prodej. Jenže za týden si manažer vzpomene, že chce statistiku stromků na skladě, podle druhu stromu a velikosti. Jenže v návrhu objektu někdo zapomněl na krabici nalepit tyto informace zvenčí. A tak se otevírá jedna krabice za druhou, aby se někdo nakoukl, co je vevnitř. A manažer se diví, proč je na to potřeba tří směn, než mu někdo takovou informaci dodá.

:-)

113

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

« kdy: 22. 06. 2021, 12:00:42 »

Možná je to víc o estetice (a ta je subjektivní) a až potom k tomu hledáme technické argumenty.

Já, doufám, ani ne. Považuji všechny ty styly (co jsme si tu řekli) za technicky rovnocenné. Technicky mi vadí snad jen, pokud se v jedné databázi najde mix stylů - s tím už se pak opravdu špatně pracuje snad každému.

Díky za odkaz.

114

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

« kdy: 22. 06. 2021, 11:42:41 »

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é.

115

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

« kdy: 22. 06. 2021, 11:06:24 »

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ší.

116

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

« kdy: 22. 06. 2021, 09:52:30 »

...

Mně přijde USING poměrně šikovné, protože už zápisem vidím, jestli se spojovací podmínka (více) přirozená, nebo komplikovanější. Ale to je asi jen věc zvyku. Většina SQL se bez USING () obejde, takže to nepovažuji za mantru.

Identifikátory nemusejí být tabulka_id, ale zapsané i opačně: "id_tabulka. To docela eliminuje problém s dlouhými názvy (kdy se člověk dozví, že se jedná o identifikátor až na konci).

Jako výhodu také vidím práci s pohledy. Při definici pohledu se pak jednodušeji přebírají identifikátory do výběru.

Kód: [Vybrat]

CREATE VIEW ... AS
    SELECT
        ...
        , id_tabulka
    FROM
        tabulka INNER JOIN druha_tabulka USING (id_tabulka)

Při vytváření pohledu to pak získá možnost pohlídat, jestli je takový zápis jednoznačný. Pokud se jedná o INNER JOIN, tak to projde, pokud se jedná o OUTER JOIN, upozorní mě to a mnohdy předejde chybě. Pokud bych používal vždy plný zápis

Kód: [Vybrat]

SELECT tabulka.id AS tabulka_id

připravím se o tuto výhodu a musím si dát dvojitý pozor, o jaký join se jedná a co je vlevo a co vpravo.

Proti tomu mně střídmost v pojmenování identifikátorů nepřijde tak důležitá, protože IDE stejně našeptávají a klíče naznačují.

Ale o tom se opravdu nehádám jako o jediné pravdě, všemi způsoby to jde, a jsou různá pro a proti.

117

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

« kdy: 21. 06. 2021, 23:51:35 »

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ší.

118

Hardware / Re:Malý externí USB box pro 2× NVMe SSD s možností RAID1

« kdy: 12. 06. 2021, 22:02:00 »

Ja bych tady byl opatrny - osobne bych do solid state reseni, ktere neumi TRIM, a to jakoze SD/eMMC za random usb prevodnikem to nebude umet, fakt nesel. Ale TRIM je obecne problem i u SATA prevodniku - zatim se me ale nedostal doruky takovej, ktery to umi - vyrobci maj vetsinou problem i udelat fw ktery zvladne UASP na vice nez jedne platforme.

Jj, není to ideální, ale aspoň trochu se to snaží blížit tomu, co pan kolega hledá. Asi se shodneme, že moc výrobců, kteří se snaží o kvalitu / spolehlivost o USB ani nezavadí, prostě to jsou disjunktní segmenty trhu.

119

Hardware / Re:Malý externí USB box pro 2× NVMe SSD s možností RAID1

« kdy: 12. 06. 2021, 20:46:56 »

Realita je takova, ze technicke deni neurcuje Miroslav Silhavy. Smirte se s tim.

Já s tím smířený jsem, ale tohle téma jsem shodou okolností nedávno docela zkoumal. Včetně čipů, které používají raid řadiče. Závěr byl jednoznační: NVMe má své přednosti, pokud existuje (přímá) PCIe linka z procesoru počítače až na disk. Pak získáte ukrutně nízkou latenci.

Jakmile je v cestě "něco", tak už NVMe nemá žádnou výkonnostní výhodu, protože "to něco" zruší právě tu možnost PCIe linky. Tím "něčím" je buďto čip raidu, nebo USB převodník. NVMe RAID lze řešit buďto softwarově (intel matrix a podobné), nebo pomocí PCIe bifurcation, ale bojí má své nevýhody (dívám se na to z pohledu serverů). Proto se výrobci ani moc nesnaží vymýšlet raidy pro NVMe disky, protože by byly paradoxně méně výkonné, než SAS varianta.

Pár výrobců má trojné čipy, které podporují SATA/SAS/NVMe, ale když se podíváte do specifikací, NVMe má už přímo na čipu nízký výkon. Je poměrně jednoduché domyslet, proč tomu tak je. Zatímco na základní desce máte hodně silný CPU, máte plnohodnotnou sběrnici, máte k dispozici ukrutný takt, tak čip obsluhující RAID ničeho takového nemůže dosáhnout. Díky tomu tu svoji stranu PCIe (tedy NVMe) má dost oslabenou.

Mnohokrát větší pravděpodobnost máte, že naleznete aspoň přibližně takové zařízení, jako hledáte, ale osazené M.2 SATA disky, nebo U.2 SAS (taky formát malé kartičky).

Docela zajímavá je ta varianta s Thunderbolt PCIe, kterou tu zmiňoval k3dAR. Leč, to se nebude tvářit jako USB flash disk, ale jako PCIe zařízení, a bude to vyžadovat (kromě thunderboltu samotného) i instalaci ovladačů.

Jestli hledáte spolehlivější přenosné úložiště, není to žádná výhra, ale asi nejblíž k tomu jsou SD karty s podporou ECC, případně SD karty bez ECC, ale s průmyslovou odolností. SD karta se pak dá připojit pomocí USB adaptéru - de facto je to o trochu větší USB klíčenka.

120

Hardware / Re:Malý externí USB box pro 2× NVMe SSD s možností RAID1

« kdy: 11. 06. 2021, 23:21:36 »

(neznam TB3, ale pisou ze by melo byt kompatibilni s USB-C)

Thunderbolt 3 umí právě přenést přímo PCIe sběrnici.
USB to neumí.

V tomto to kompatibilní s USB není.