reklama

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.


Příspěvky - Miroslav Šilhavý

Stran: [1] 2 3 ... 136
1
To musí být krásný a pohodlný život mít bezcenná data :-D

Ve firmě je daleko větší riziko, že data vynese někdo zevnitř, než že ukradne média.
Ostatně i doma je větší riziko nějakého malwaru, který data krade nebo přepisuje.

Na Synology by to šlo udělat přes iSCSI extent a šifrování nechat na cílovém OS. (Z něj to případně sdílet dál do sítě). Nutno ale počítat s propadem výkonu, iSCSI bude pomalejší než sdílení souborů.

2
Pokud je šifrování ochranou proti fyzické krádeži (proti čemu jinému taky?), tak může být klíč někde na http/ssh v LAN. Aneb dokud je disk na svém místě, vše funguje. Pokud jej opustí, fungovat přestane :-) Možná může být i na veřejném netu s whitelistem IP adresy. A logováním+notifikací, pokud se zkusí stáhout odjinud :-)

Teoreticky ano. A jak to uděláte prakticky na Synology / QNAPU, což jsou nejčastější domácí nasky?

3
A proto disky / data obvykle šifrujeme. I když, pravda, ne vždy a všude je to přímočaré řešení.

Disky obvykle nešifrujeme. Protože to vyžaduje při každém náběhu klíč a to je proti uživatelskému dojmu. Synology se rebootuje a data nejsou, dokud je někdo neodemkne. To není moc řešení.

Poměrně dobře lze šifrovat koncová zařízení (PC, mobily, ...), kdy přístup ke klíči je chráněn např. v TPM a heslem. Uživatel u zařízení "sedí" a ani mu nepřijde, že zadáním hesla / pinu odšifrovává. U datového storu pro domácnost to ale nevidím jako moc použitelné.

4
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 16. 10. 2019, 20:28:24 »
Já jsem žádné zlepšováky nenavrhoval, právě naopak – já jsem psal o standardním zápisu INNER JOINu pomocí INNER JOINu. Naopak jsem proti zlepšováku Miroslava Šilhavého s tím, že pro INNER JOIN použije zápis pomocí OUTER JOINu a spojovací podmínku přidá k filtrovacím podmínkám do WHERE.

Až na to, že žádná podmínka se nemusí přidávat. Stačí tam pouze WHERE allowed > 0. Kde je ta přidaná podmínka?

Jsem rád, že jste konečně zaregistroval, jak byla dána podmínka. Ano, přesně takhle. Proto je také přesně tahle podmínka ve WHERE. A nefunguje to jen náhodou, jako ve vašem případě, ale vždycky, pro jakoukoli podmínku. Co když se podmínka změní na allowed IS NULL? V mém postupu se jenom změní podmínka ve WHERE a bude to dál fungovat. Vy byste v takovém případě (možná) zjistil, že jste použil špatný JOIN a že ho musíte opravit.

Ano, přesně tak. Mohu chtít vyselektovat záznamy WHERE allowed IS NULL, což se bude v OUTER JOINU platit ve dvou případech: a) pokud nedojde k joinu, b) pokud k joinu dojde a ve sloupci allowed bude NULL. Je už na programátorovi, aby si určil, jakou situaci hledá. Podle toho naformuluje podmínku buďto jako prosté WHERE allowed IS NULL, což by dost možná dávalo smysl (práva nejsou upravena ani existencí řádku, nebo ani hodnotou allowed), případně by mohl podmínku rozšířit na WHERE tbl2.id_data IS NOT NULL AND allowed IS NULL.

S Vaším inner joinem se může jít klouzat, nedokáže dohledat řádky, které v tbl2 nemají odpovídající záznam.

5
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 16. 10. 2019, 19:59:57 »
ano je to tu zaspamovane a neda sa to uz citat.

Toto je zrovna hned v prvním postu:

Citace
Potřeboval bych provést SELECT dotaz nad jednou tabulkou tbl1.id_data, který je podmíněn jinou tabulkou tbl2,
tedy z tbl1.id_data vybrat pouze to, co v tbl2 je jako allowed >0
S tím, že tbl2.id_data nemusí obsahovat všechny data v tbl1.id_data

6
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 16. 10. 2019, 13:19:38 »
Zadání vám klidně může připadat hloupé, pak je ale potřeba s tím zadáním polemizovat, ne si potichoučku řešit něco jiného. Takže za sebe bych to uzavřel, že než začnete řešit, jaký typ JOINu je nejlepší, je nejprve potřeba si pořádně přečíst zadání.

To je o tom, jestli chcete být programátorská lopata, která nechce rozumět reálnému prostředí a co jí není vyspecifikováno do puntíku, tak to ignoruje. Nebo jestli chcete program (včetně SQL) opravdu navrhovat. Pak musíte přemýšlet o krok dál.

Zadání bylo naprosto přesně zadané: struktura dat byla dána tím, že "v tbl2 může a nemusí existovat odpovídající záznam", zatímco podmínka dotazu byla dána "allowed > 0". Naopak vy jste ze zadání naprosto nadbytečně dovodil, že OUTER JOIN se dá redukovat na INNER JOIN.

7
Windows a jiné systémy / Re:Úprava Windows Exploreru
« kdy: 15. 10. 2019, 12:31:35 »
No já se přiznám, i když tím asi mnohé teď zklamu, já ten explorer chtěl trochu "přisprostit".

...áno, na to jsou programy... Zejména při psychiatrických nemocnicích. :)

8
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 14. 10. 2019, 21:53:24 »
Pořád se slepě řídíte strukturou tabulek a neberete v úvahu význam dat. Pokud záznamy s neexistující vazbou nemají žádný význam, nemá smysl vytvářet nad nimi pohled, abyste je následně při každém použití toho pohledu musel odfiltrovat. Já jsem nepsal o pohledech, které přidávají jednu podmínku, ale o pohledech, které reprezentují různá data. Např. pokud je vedoucí zaměstnanec definován tím, že má podřízené, nemá smysl vytvářet si pohled s vedoucími, který bude obsahovat i ty, kteří žádné podřízené nemají, a ty z něj pak při každém použití odfiltrovávat.

Přesně naopak. V aplikaci můžu chtít zobrazit všechny vedoucí, co mají podřízené zaměstnance. Ale také můžu chtít (a je to dost běžné) na jiném místě zobrazit i ty, co (už) žádné podřízené nemají. Tedy jak existence, tak neexistence navázaného záznamu je významná. Struktura dat je pro oba záměry shodná, liší se jen v podmínce filtru.

9
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 14. 10. 2019, 21:15:41 »
Pokud dávají smysl oba dva přístupy, udělám dva pohledy. Vy za každý vytvořený pohled platíte, nebo proč je pro vás tak důležité, že je ten pohled jeden a ne dva? Navíc se ty dva pohledy používají v různých situacích, takže se mi to krásně oddělí. Dost možná ty pohledy budou mít i jiné sloupce nebo dokonce připojené jiné další tabulky.

Pokud mám interpretovat určitou vazbu dat, je výhodné mít jeden pohled, třeba i se všemi sloupci, co se nabízejí. V následném selektu pak sloupce omezím jen na ty, které potřebuji. Tím, že v pohledu jsou k dispozici, nic neztratím, ani na výkonu.

Pokud potřebuji mít připojené další tabulky, není nic neobvyklého nad existující pohled postavit další, s dalším joinem.

A proč na to nechci mít dva oddělené pohledy? Inu protože pohledy mají zvyšovat přehlednost - čím méně jich je, tím snáz se revidují. Pokud mi dva pohledy opakují tu stejnou vazbu a jen přidávají podmínku, nedává to moc smysl. Ale kdybych to přeci jen chtěl mít, tak si nejprve udělám pohled interpretující strukturu dat, a teprve nad něj postavím speciální pohledy s filtry. V praxi se setkávám s pohledy s filtry jen v případě, kdy slouží k omezení přístupu k datům (uživatel nedostane práva na samotné tabulky, ale dostane práva jen na zafiltrovaný pohled).

Typicky, mám-li hlavičku dokladu a k ní navázaných 0-nekonečno položek dokladu, pak použiju OUTER JOIN a uložím to jako view. Nad ním pak mohu stavět agregáty (např. count položek). Ze stejného pohledu mi vypadnou jak doklady bez položek, tak doklady s položkami. Po agregaci u bezpoložkových dokladů získám count=0. Nebo použiju agregáty nad parcelami dat. Tento přístup je mnohem výhodnější, než abych v aplikačním kódu zvlášť selektoval doklady s položkami, zvlášť volal agregační funkce, a zvlášť selektoval doklady bez polože.

V případě stromu oprávnění potřebuji od zkoumaného uzlu směrem nahoru vyhodnocovat přístupové oprávnění. Pokud není určeno (OUTER JOIN navrátí v klíči NULL), je to indikátor k tomu přejít k dalšímu nadřazenému uzlu a vyhodnotit dědění práv. Pokud bych měl mít jedno view na existující práva a druhé na neexistující práva, musel bych joinovat tyto dvě views proti sobě. Pokud to mám v jednom provedu JOIN téhož view sama na sebe.

Prostě příkladů, kdy se to hodí je bezpočet a naopak málo případů je, kdy to může být škodlivé.

Na druhou stranu si uvědomuji, že spousta programátorů není schopna napsat select s více než třemi joiny, neumějí joinovat tabulku sama na sebe, zpracovávat parcely dat atd. atd. Právě proto si myslím, že je dobré radit jaké možnosti SQL nabízí a trpělivě vysvětlovat, že SQL optimalizace je vždy úspěšnější, než logiku programovat v aplikaci. Příklad Raccheka je přesně z toho ranku, kdy se dá poradit jednoduché řešení (INNER JOIN), ale i ukázat, že existuje i jiný, a možná zajímavý přístup k věci.

INNER JOIN bych používal zejména tam, kde se neočekává, že odpovídající záznam neexistuje - např. zmíněné číselníky, nebo pravá strana dynamické vazby (tbl1 LEFT JOIN tbl_vazba INNER JOIN tbl_hodnoty - první join nemusí nastat, ale pokud nastane, tak pravý už je obligatorní).

10
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 14. 10. 2019, 20:09:52 »
ale vrátilo mi to i záznamy, které v tbl2 vůbec neexistují.
ano o tom je left outer JOIN. vitajte v SQL realite :)
a ano nechcete mat NULL na vystupe preto to napisete tak aby tam nebol.

To je samozřejmě blbost. Je-li podmínka allowed > 0, nemůže to navrátit sloupce, které obsahují NULL. Nenajoinované záznamy tam mají NULL, takže se neobjeví.

11
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 14. 10. 2019, 17:09:26 »
Pro neexistenci záznamu platí to samé, co pro NULL. Není to stejná hodnota, jako kterákoli jiná, je speciální –ostatně i proto se při OUTER JOINu neexistující záznamy mapují právě na NULL, což je jiná speciální hodnota. Pokud chcete v SELECTu říct, že vás neexistující záznamy nezajímají, uděláte to právě pomocí INNER JOINu. Tím si zajistíte, že se ty neexistující záznamy ve výsledné sadě ani neobjeví, tím pádem není nutné je mapovat na NULL a tím pádem ani nemusíte NULL hodnotu řešit.

:) jenže to jsme pořád u toho samého. Pokud si "SELECT * FROM tbl1 LEFT JOIN tbl2" vyčleníte do VIEW, můžete pak s tím samým VIEW pracovat všemi způsoby. Třeba tím, že do WHERE doplníte allowed > 0, nebo že tbl2.id_data IS NULL.

Je pochopitelně dost účelné mít jedno VIEW a pracovat s ním jen v podmínce.

12
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 14. 10. 2019, 16:41:26 »
Mně na tom teda poněkud vadí, že je ten dotaz špatně. Chtěl jsem záznamy, které v tbl2 existují a mají tam allowed IS NULL, ale vrátilo mi to i záznamy, které v tbl2 vůbec neexistují.

Pokud dáte podmínku WHERE allowed > 0, pak Vám to tyto záznamy přirozeně nevrátí.

Pokud často píšete dotazy, ve kterých neexistence záznamu nebo NULL hodnota má stejný význam, jako nějaká jiná hodnota, tedy vyskytují se vám tam konstrukce … IS NULL OR … , je to známka toho, že máte špatně navrženou strukturu databáze. NULL není jedna z mnoha hodnot, NULL je speciální hodnota, výjimečná – proto se s ní nepracuje pomocí běžných operátorů = nebo !=, ale má speciální operátory; proto je „nakažlivá“ a když se objeví u běžných operátorů, je na výstupu zase NULL

Jedná se o (primární / vzdálený) klíč. Ten může mít buďto hodnotu a dojde k joinu, nebo nedojde k joinu a pak záznam neexistuje. NULL v klíči má jasně daný význam. U ostatních sloupců, mimo klíčů platí to, co píšete.

13
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 14. 10. 2019, 10:12:32 »
A pak někdo do toho WHERE dá takovouhle podmínku:
Kód: [Vybrat]
SELECT * FROM tbl1 LEFT OUTER JOIN tbl2 USING (id_data) WHERE tbl2.allowed IS NULL

Ano, ale přesně o to jde, aby mohl udělat. Tedy vyselektovat si záznamy, ke kterým není právo "allowed" explicitně dané.

Jako další příklad toho, co může dávat smysl je dotaz:
SELECT  * FROM tbl1 LEFT OUTER JOIN tbl2 USING (id_data) WHERE tbl2.id_data IS NULL OR tbl2.allowed = 0

14
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 14. 10. 2019, 09:29:11 »
Aha, takže to vaše „dotaz má být co nejvíce univerzální“ znamená, že tam ty podmínky pokaždé budete psát úplně od začátku. Čím dál lepší.

Co prosím? Já tvrdím, že správně napsaný skelet dotazu je takový, kde se podmínka "metá" jen do WHERE a nemusí se nic dalšího měnit. Takový skelet lze zobecnit do VIEW a pak pracovat jen nad ním.

15
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 14. 10. 2019, 08:58:16 »
Takhle napsané to vypadá, že oba JOINy se stejnou podmínkou vrátí stejný výsledek. Jenže to není pravda, u OUTER JOINu musíte do filtrovacích podmínek přidat i tu podmínku, která z něj udělá INNER JOIN. Obecně samozřejmě každý INNER JOIN jde napsat pomocí OUTER JOINu tím, že přidáte další podmínky. Obšem jak bylo vidět v této diskusi, není to vždy snadné…

Aha, tak zde je ta chyba, kterou děláte. V tomto případě žádnou podmínku navíc nepotřebujete. Stačí bohatě
SELECT * FROM tbl1 LEFT OUTER JOIN tbl2 USING (id_data) WHERE tbl2.allowed > 0.

Pokud nedojde k joinu, pak nebude ani splněná podmínka tbl2.allowed > 0.

Stran: [1] 2 3 ... 136

reklama