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 ... 68 69 [70] 71 72 ... 206
1036
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 19. 10. 2019, 19:52:39 »
Tady v diskusi říkám zadání tomu, co jsem jako zadání napsal.

Což byla pěkně nedomyšlená pitomost na úrovni odpovědi na Racchekův dotaz.

A jak se říká někomu, kdo si přečte zadání a vzápětí napíše něco, co je s ním zjevně v rozporu, a je mu to úplně jedno? Jak se říká někomu, kdo ostatním pořád vnucuje zapisovat INNER JOIN pomocí OUTER JOINu ale ten příkaz opakovaně píše špatně?

Jděte se schladit. V jednom příkladu jsem nedospecifikoval některé stavy, ale účelem bylo upozornit na styl přemýšlení, nikoliv do diskuse napsat definitivní select.

Opakovaně píšu na první otázku odpověď: SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE allowed > 0. V tomto vidíte nějakou chybu?

V těch dalších příkladech je zanedbáno víc věcí, např. když jsme se bavili o VIEW, nemůžu odkazovat na tbl2.id_data (protože výstupem z view už není reference na původní tabulky). Přesto jsem to napsal schematicky, aby bylo zřejmé, co mám na mysli.

Dále jsem zanedbal situaci, kdyby byl sloupec allowed NULLABLE - ale to by bylo významné jen v případě inverze dotazu. Tam jste správně doplnil, že by to bylo potřeba ošetřit - ale to bylo opět mimo scope diskuse. Pointou bylo upozornit, proč je výhodné si postavit select jako outer join, protože přinese univerzalitu (např. ve formě view). Blbinka jako ošetření joinu nebo nullable je už jen technický detail.

Jestli chcete, můžete se dál točit na detailech jako jsou překlepy nebo zjednodušení v zápisu pro účely fóra. Já preferuju diskusi o tom, jak se má k problému přistupovat a proč je jaký postup výhodný. Bohužel, právě tento kontext Vám uniká a úzce se soustředíte na vybraný detail. Ostatně, na toto jsme spolu narazili i při jiných tématech.

1037
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 19. 10. 2019, 18:41:32 »
I kdyby zadání bylo nereálné, neznamená to, že ho můžete tiše ignorovat, vymyslet si své vlastní zadání a tím se řídit. Takovým postupem rozhodně nedojdete k výsledku, se kterým bude zadavatel spokojený. Pokud je termín „vedoucí“ definován v zákoně, můžeme klidně použít pro náš účel jiný termín, třeba „nadřízený“. Mít definované lidi, kteří aktuálně mají podřízené, smysl dává – např. pokud chcete, aby své podřízené o něčem informovali, mimořádně rozdělili prémie o den dřív nebo vytipovali podřízené na školení, nedává smysl informovat o tom někoho, kdo žádné podřízené nemá.

Podle toho, čemu říkáte "zadání". Pokud jsou to business-požadavky, tak to ještě není zadání. Je známá věc, že business požadavky bývají dost nepřesné, zejména tutéž věc Vám v každé firmě popíše jiný člověk jinak. Každý to vnímá z úhlu svých pracovních povinností. Tedy zadavatel obvykle nedává žádné požadavky, ale spíš popis z jeho pohledu.

Na analytikovi (u malých projektů na programátorovi) je umět tyto požadavky "přečíst" a domyslet všechny situace, na které zadavatel ve svém popisu zapomněl. Obvykle zadavatelé zapomínají na z jejich pohledu nedůležité stavy. Hezký příklad je to rozesílání metodických pokynů - když na jeden den vypadnete z definice "nadřízeného", druhý den novým podřízeným nepředáte požadované informace. Zadavatel nebude chápat, proč se to stalo, když je "zřejmé", že toto neměl na mysli - a Vy to budete fixovat nějakým šíleným hackem nad daty.

To, co jste popsal, je přístup programátorské lopaty (dnes se tomu eufemisticky říká "junior").

1038
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 18. 10. 2019, 18:51:10 »
Jak jsem psal, takový předpis se snadno může změnit....
Takže když změní platební předpis a přidají tam tuto kontrolu, tak kvůli tomu budeš překopávat strukturu databáze a měnit definici toho, kdo je vedoucí?
Teda, s tebou v jednom SW teamu bych fakt pracovat nechtěl - a šéf by Tě nepochválil, že věc na hodinu Ti trvá týden....
Citace

Tento přístup je bohužel typický nešvar internetových návodů. Z velké části jsou examply a rady takové, že se vůbec nesoustředí na návrh, ale jen na magii se selecty. Spousta "dobrých rad" nechává logiku na aplikaci a ze SQL se jen tahají data. O transakcích a konzistenci dat se kde kdo ani nestará, v malém množství se to nepozná - a tak programátoři nemívají žádné návyky.

Nerad generalizuji, ale když mám pohovor s uchazečem a hlásí se ke znalosti SQL, tak se ještě ptám, jestli zná něco jiného než MySQL. Pokud ano, většinou s databázemi umí o řád lépe, než internet-návodoví-samouci na MySQL (Xampp peklo a podobné).

Je určitě potřeba dávat nováčkům rady, a právě toto je to místo. To, co Filip radil byla úzce, specificky funkční rada, bez zamyšlení se nad kontextem. Takové rady pak przní další generace.

1039
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 18. 10. 2019, 17:59:01 »
No jo, když vy si pořád pletete modelování databáze (strukturu tabulek) a dotazování. Tak ještě jednou: SELECT opravdu není součástí modelování databáze. Pokud mi nevěříte, najděte si, jaký je rozdíl mezi DDL a DML, a všimněte si, že SELECT nepatří pod DDL.

Houby si pletu. Vím s jistotou, že pokud můžete modelovat data buďto v souladu s definicí, nebo mimo ni, je vždy preferovaný soulad. Váš INNER JOIN nepřináší nic navíc, pouze omezuje možnosti manipulace s daty.

1040
Hardware / Re:Synology vs. QNAP
« kdy: 18. 10. 2019, 17:57:32 »
A co jsou prosím ty "enterprise" funkce které nemaji vyšši řady Synology ?

Katastroficky se vyžhavují zdroje (i u vyšších řad, s redundantními), iSCSI tak možná na domácí hraní.
Některé vady disků nejsou dobře detekovány a pole se rozpadne a nejde sesynchronizovat (ať už je to na klasickém svazku, nebo btrfs).
O bezpečnosti nemluvě.

a to já klidně napíšu  - zákldní a levné modely 2-4 diskové běží 10 a víc let bez problémů..   některé nejsou na UPS a výpadky občas jsou... vždycky to naběhlo a jede to dál. Dokonce i disky jsou v pořádku (celkově mluvím asi o 25kusech).
Nikdy jsem žádný model nemusel reklamovat (ani zdroj). Divný co ?

Já Vám zase můžu ukázat plejádu reklamací, nebo půjčit kousky, co do tří měsíců bezpečně oddělají disky (asi kvůli napájení, protože chlazení funguje).

Proto to v podnikovém prostředí nemůže obstát.

1041
Server / Re:SPF záznam + include a parametr MX
« kdy: 18. 10. 2019, 11:21:26 »
Tak fixnuto v bode 2]:

ad 2] ...v=spf1 mx:domain.tld ipv4:...

Přesně tak, protože _spf.domain.tld in txt "v= spf1 mx ip4:ip1 ip4:ip2 ... ip4:ipX ?all říká, že mají být zahrnuty MX záznamy pro _spf.domain.tld, ale zjevně měl někdo na mysli zahrnou MX záznamy pro domain.tld.

V tu chvíli je ale MX zbytečně uvedeno i v prvním záznamu. Takže podle potřeby buďto uvést MX jen v prvním řádku, nebo naopak jen v druhém řádku uvést mx:domain.tld.

1042
Server / Re:Dostupnost dat z ukradených HDD ze Synology v RAID5
« kdy: 17. 10. 2019, 12:26:13 »
Nevím, jak to šifrování mají udělané.. ale předpokládám, že je tam všude nějaký linux, potom cryptsetup a nastavit sám. Reálně jsem to zkoušel jen na notebooku - klíč stáhne grub a doma bootuje bez hesla :-)

To asi není to, co člověk hledá, když si pořídí Synology.

1043
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 17. 10. 2019, 12:22:13 »
Já bych ještě citoval Filipa:

Citace
Další poučka říká, že není vhodné databázi modelovat těsně podle pravidel daných realitou, pokud jsou ta pravidla daná rozhodnutím.

Toto pravidlo Filip porušil hned v začátku této diskuse. Nerespektoval realitu databáze, ale respektoval pravidlo určené rozhodnutím. Tím mám na mysli "tbl2 nemusí obsahovat odpovídající záznamy" (realita) vs. "hledáme jen allowed > 0" (rozhodnutí specifické pro jeden jediný pohled).

1044
Server / Re:Dostupnost dat z ukradených HDD ze Synology v RAID5
« kdy: 17. 10. 2019, 12:12:10 »
To je pravda (pokud uvažujeme opravdu Enterprise) do určité míry - nutno brát v potaz např. krádeže laptopů atp., kde je šifrování jediným (?) efektivním řešením. Souhlasíte?

Ano, naprosto.
Tam to řeší 1) TPM, 2) zadání klíče nebo PINU uživatelem, který s laptopem pracuje interaktivně. (Zatímco NASKA leží někde v koutě).

1045
Windows a jiné systémy / Re:Úprava Windows Exploreru
« kdy: 17. 10. 2019, 11:24:46 »
nejak rozumne zmodifikovat

Tak už samo o sobě toto sousloví je protimluv. Miliony nerozumných lidí, a jeden rozumný? :-D

1046
Server / Re:Dostupnost dat z ukradených HDD ze Synology v RAID5
« kdy: 17. 10. 2019, 10:21:44 »
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ů.

1047
Server / Re:Dostupnost dat z ukradených HDD ze Synology v RAID5
« kdy: 17. 10. 2019, 09:56:37 »
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?

1048
Server / Re:Dostupnost dat z ukradených HDD ze Synology v RAID5
« kdy: 17. 10. 2019, 09:46:05 »
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é.

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

1050
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

Stran: 1 ... 68 69 [70] 71 72 ... 206