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 - Filip Jirsák

Stran: 1 2 [3] 4 5 ... 228
31
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 12. 10. 2019, 11:21:39 »
Ne. Struktura dat je dána databází (její zamýšlenou interpretací). Struktura se nemění dotaz od dotazu. Ve správném návrhu by měla být vyjádřena i správně postavenými FOREIGN KEYS.
Opakuji ještě jednou – tady je struktura dat taková, že se zabýváme jenom záznamy existujícími v tbl2.

Existence záznamu je tacitní podmínkou dotazu. Pokud musí existovat allowed > 0, implikuje to existenci záznamu v tbl2.
Děláte přesně to, před čím jste varoval – snažíte se JOIN převádět na WHERE. Tyhle tacitní podmínky právě popisují způsob spojování tabulek. Proto se v SQL dotazu píšou zvlášť a je na ně speciální syntaxe – JOIN.


Vy jste mu zodpovědel dotaz jen pro jeho jeden speciální případ, ale už jste vůbec nepřemýšlel, že v praxi se podmínky parametrizují.
Právě naopak, já jsem popsal takový dotaz, kde jsou ve WHERE všechny podmínky a není tam nic jiného, než podmínky. Ty si může tazatel parametrizovat a upravovat jak je libo, a nemusí pořád myslet na to, že tam musí přidávat ještě spojovací podmínku – protože tu má správně uvedenou u JOINu.

Panu kolegovi, který se učí, a který potřebuje vytvořit správné návyky, jste poradil pěknou blbost, která mu jednou zkomplikuje život.
Nezlobte se na mne, ale blbosti tu píšete vy. Neustále naznačujete, že INNER JOIN by se měl používat jenom tam, kde obě tabulky obsahují identickou sadu entit, akorát ke každé jedné entitě nesou jinou sadu vlastností. Že se INNER JOIN vůbec nemá implementačně lišit od OUTER JOINu, nýbrž že je to jenom komentář pro databázového specialistu, který mu říká „obě tabulky mají stejný počet záznamů, které si navzájem odpovídají“, resp. „vlastně by to měla být jen jedna tabulka, ale z nějakého důvodu je rozdělená na dvě“. V obou tabulkách by tedy mělo být nastavené FOREIGN KEY na tu druhou tabulku. Pokud by byl INNER JOIN přes více tabulek, muselo by to platit pro všechny a FOREIGN KEY by zřejmě měly mít každá s každou.

Pak by mne ale zajímalo, jak odůvodníte, proč jsou ty záznamy ve více tabulkách, proč to není jedna tabulka.

Pouze ale jeden z těchto dotazů je sémanticky správně.
Ano, ten první. Všimněte si, že je to přesný přepis zadání: „z tbl1.id_data vybrat pouze to, co v tbl2 je jako allowed >0“. Když si tu českou větu přeložíte do angličtiny, máte už ten SQL dotaz vlastně hotový.

32
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 12. 10. 2019, 10:08:51 »
JOINY mají odpovídat struktuře dat, nikoliv podmínkám dotazu. CROSS JOIN by těmto datům neodpovídal, proto by byl
taky špatně. Kritéria spojení byste přesouval do podmínky dotazu.
Ano, a tady je struktura dat taková, že se zabýváme jenom záznamy existujícími v tbl2. Existence záznamu není podmínkou dotazu, protože takové záznamy se do výsledné sady před filtrováním vůbec nedostanou. Ostatně tazatel o tom přesně takhle uvažoval, proto dokonce to spojování tabulek ani nezmínil – připadalo mu to samozřejmé.

Prostě Váš návyk omezovat joiny podle podmínky dotazu je nezdravý, tak se SQL dělat nemá.
Ale já to tak nedělám. To jenom vy jste pořád nepochopil, jaká je struktura dat.

33
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 12. 10. 2019, 10:05:21 »
Spojovací kritérium je odvislé od struktury dat.
Není. Spojovací kritérium je závislé na významu dat. Autoři standardu SQL opravdu nebyli tak hloupí, aby vytvořili dva různé příkazy (INNER JOIN a OUTER JOIN), které by z hlediska implementace byly identické, pouze by odkazovaly na (nevýznamnou) strukturu databáze. Navíc by jejich rozlišení databáze stejně nedokázala nijak zkontrolovat, takže byste je ve spoustě případů měl špatně.

Tu nám tazatel popsal. V tbl2 mohou a nemusí být záznamy odpovídající tbl1. To je spojovací kritérium.
Nikoli, tazatel napsal, že ve výsledné sadě mají být jen ty záznamy, které mají v tbl2 záznam. To je spojovací kritérium.
ium zůstane platné za všech okolností, i když se podmínka dotazu změní.

S tímto spojením pak můžete pokládat dotaz, který tazatel položil (najít záznamy, které mají odpovídající záznam v tbl2 a zároveň allowed > 0)
Jenže tazatel položil jiný dotaz. Velda se tady o tom diskuse, klidně se vraťte na začátek tématu a ten dotaz si znovu přečtěte. Tazatel napsal „z tbl1.id_data vybrat pouze to, co v tbl2 je jako allowed >0“. První odpovídající to pochopili tak, jak to tazatel myslel – záznamy neexistující v tbl2 se vůbec neberou v úvahu, protože ani nebudou výsledkem spojení těch dvou tabulek, a podmínkou pro zobrazení ve výsledné sadě je tbl2.allowed > 0.

S vaším inner joinem se můžete jít klouzat, při změně podmínky budete muset přeformulovat i joiny.
Kdyby jenom JOINy, se změnou podmínky budete muset často připojit jiné tabulky… S tím vaším přístupem, kdy chcete mít univerzální dotaz na všechno, ve kterém budete jenom měnit podmínky, byste měl udělat CROSS JOIN všech tabulek v databázi a pak si v podmínkách poskládat, co zrovna potřebujete.

34
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 12. 10. 2019, 09:52:31 »
Filip! v prvej otazke tohoto threadu bolo spomenute ze:
1. mas tabulku 1 s ID
2. mas tabulku 2 kde su niektore ID s tabulky 1
preto LEFT JOIN... tam neni o com s inner joinom.
Prosím, neopakujte znovu chyby, které už tu byly dávno vysvětlené. To, co jste napsal vy, je velmi nepřesný přepis původního dotazu. Z původního dotazu totiž nebylo zřejmé, jak se má s neexistujícími záznamy z druhé tabulky zacházet. Proto jsem se na to zeptal, a Racchek na to odpověděl – ve výsledné sadě mají být jen ty prvky, které mají záznam v druhé tabulce (a ten samozřejmě má správnou hodnotu). Sémanticky se tedy jedná o INNER JOIN. Druhá věc je, jestli ho napíšete normálně jako INNER JOIN, nebo – pokud máte averzi na INNER JOINy jako Miroslav Šilhavý – ho klidně můžete napsat jako CROSS JOIN a všechny podmínky dát do WHERE, aby to bylo dostatečně obecné.

35
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 12. 10. 2019, 09:45:39 »
To, co říká Filip, dělá spousta lidí - podmínku zaměňuje s joinovacím kritériem.
Ano, jedním z nich je například Miroslav Šilhavý, který se neustále spojovací kritérium snaží cpát do podmínek.

36
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 09. 10. 2019, 22:01:25 »
já preferuji a kolegy učím, že v případě, že v druhé tabulce záznam být nemusí, mají si vytvářet dotazy outer joinem
Když v druhé tabulce záznam být musí, bude INNER JOIN dělat to samé, co OUTER JOIN. Jinými slovy, podle vás je INNER JOIN zbytečný. Přemýšlel jste někdy o tom, proč ho autoři do jazyka SQL zařadili, a to dokonce jako výchozí?

37
V současnosti bych asi zvolil OpenJDK 11, protože je to LTS a bude podporovaná 3 roky. Většina kritických oprav bude v upstreamu.
LTS verze je Oracle JDK 11, Oracle OpenJDK 11 už vydáváno není. Kritické opravy se asi dostávají do upstreamu, ale pokud je chcete, musíte použít ty alternativní buildy OpenJDK (od Amazonu, RedHatu apod.) a nebo Oracle JDK (Java SE). Nebo sám sestavit ze zdrojáků…

38
Java 8,9,10 můžete naprosto v pohodě používat. JRE i JDK si můžete v klidu stáhnout z Oracle webu. Ovšem Oracle Java 11,12,13,... již ke spuštění vaší aplikace pokud si ji nezaplatíte používat nesmíte.
Nikoli, nezávisí to na verzi, ale na době vydání. Od určitého data platí nová licence pro Java SE od Oracle, takže pod starou licencí můžete používat staré verze Java SE 8 s bezpečnostními chybami, novější opravené verze už jsou k dispozici jen pod novou licencí. Ale to se týká komerčního buildu Oracle Java SE pod komerční licencí. A ani u té není pravda, že se za vše musí platit – pro vývoj a testování je zdarma (osobní použití teď z hlavy nevím, kolem toho byly nějaké zmatky). Java SE je založená na OpenJDK, ale Oracle k tomu přidává svoje nástroje zaměřené zejména na enterprise sféru.

Vedle toho existují buildy založené čistě na OpenJDK, Oracle dělá svoje buildy vždy jen pro aktuální verzi (ty by měly být shodné s OpenJDK částí Java SE). Další dodavatelé, jak jsem psal, dodávají svoje vlastní buildy OpenJDK – tam už mohou být některé patche jiné, než co je v Oracle OpenJDK a Java SE.

nezbývá nic jiného než použít nějakou implementaci OpenJDK
Všechno, co se dnes používá, jsou různé implementace OpenJDK. Rozdíl je jenom v JVM, dneska se reálně používají jen dvě různé – HotSpot (+ GraalVM), což je implementace, která je součástí zdrojáků OpenJDK a je součástí Java SE. Druhá implementace JVM je od IBM, a některé buildy OpenJDK nabízejí tuto JVM jako alternativu k HotSpotu.

nutno u toho dodržovat GPLv2
Což není nijak obtížné, obvykle JDK jenom spouštíte ale nijak neupravujete, takže dodržet GPLv2 s classpath výjimkou je triviální, prostě to normálně používáte.

39
Pořád z toho nejsem moudrej. Máme aplikaci napsanou programátorem v Java 8 JDK před cca 2ma roky. Teď řešíme jestli tuhle aplikaci, kvuli ktere musime Java 8 JDK nainstalovat aby běžela, můžeme vůbec oficiálně používat? A pokud ne, co dělat? Platí se za každou instalaci takové aplikace? Děkuji za stručnou odpověď pokud ji někdo zná ...
Předpokládám, že řešíte licencování Javy a nikoli té aplikace.

Nezáleží na tom, kdy ta aplikace byla napsána. Oracle OpenJDK můžete používat, jak chcete – ale verze 8 už není podporována, nebude dostávat bezpečnostní záplaty. Oracle OpenJDK dostává záplaty jen pro aktuální verzi, v současné době tedy pro verzi 13 – a každý půlrok je potřeba přejít na nejnovější hlavní verzi. Pokud ta vaše aplikace běží i na novějších verzích Javy, je nejlepší přejít na to aktuální verzi 13.

Další možnost je používat jiné buildy OpenJDK – někteří poskytovatelé nabízejí bezpečnostní patche i pro OpenJDK 8. Některé jsou k dispozici i zdarma – osobně věřím nejvíc Amazon Correto, další je třeba AdoptOpenJDK nebo Zulu OpenJDK.

Další možností jsou komerční buildy s dlouhodobou podporou – Oracle java SE, RedHat OpenJDK, IBM poskytuje podporu pro AdoptOpenJDK atd.

40
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 07. 10. 2019, 17:05:00 »
To si nemyslím. Pro ladění je daleko výhodnější si vytvořit VIEW s LEFT OUTER JOINEM. Když si pak vyselektujete všechny záznamy, daleko líp si představíte, co navrací. INNER JOINEM se připravíte o možná nerelevantní, ale možná taky o relevantní hodnoty a nevyladíte ani zblo.
Pro ladění si používejte, co chcete. Já píšu o tom, co má být v produkčním kódu, který bude číst a udržovat i někdo jiný (nebo vy za půl roku).

41
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 07. 10. 2019, 15:57:11 »
To je velmi krátkozraké uvažování při návrhu selectu.
Racchek může ve své práci potřebovat následně vyselektovat třeba opak. Pokud to udělá OUTER JOINEM, jen vymění podmínku - což se hodí zejména ve scriptech.

Proto tvrdím, že pokud někdo navrhuje dotaz, měl by ho udělat co nejuniverzálnější. Následně se dá takový dotaz uložit jako VIEW a pak už vstoupí do hry jen to samotné WHERE.
Tohle je ukázkový příklad antipatternu „předčasná optimalizace“. Kód má být především správný, pak přehledný, srozumitelný a udržovatelný. Což v tomto případě znamená INNER JOIN, protože u něj to každý vidí na první pohled, že jde o INNER JOIN.

Navíc jste si bůhví proč vybral jako možnou modifikaci vybral zrovna ten jeden (nepravděpodobný) dotaz. Vzhledem k tomu, že v případě jediného zatím požadovaného dotazu je tam INNER JOIN, dá se předpokládat, že i případný „opačný“ dotaz bude zase INNER JOIN. Protože ty záznamy, pro které neexistuje podřízený záznam, jsou při spojení určitým způsobem nezajímavé, a budou nezajímavé pořád, ať se na ně díváte zleva nebo zprava. Takže v případě vytváření dalších dotazů tam pořád bude nutné přidávat tu podmínku pro INNER JOIN, pořád na to bude muset někdo myslet a hrozí, že ji přidá špatně. I pro další práci je tedy lepší mít ten INNER JOIN, protože tam je spojení tabulek pěkně definováno přímo u JOINu a do WHERE už se píšou jenom podmínky filtrující výslednou sadu. A pokud někdo náhodou bude potřebovat něco speciálního a tedy použít OUTER JOIN, holt si ten jeden příkaz napíše. Ostatně proto je zase vhodná syntaxe JOINu, kdy prostě jenom před klíčové slovo JOIN napíše LEFT nebo RIGHT a nemusí hledat mezi podmínkami ve WHERE, kde že je ta JOINovací podmínka vložená.

42
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 07. 10. 2019, 15:07:33 »
Moje tvrzení se stále týkala výsledku JOINU.
Pokud se chcete bavit o tom, jak se k výsledku dostat, těžko můžete začít od toho, co máte ve výsledku. Navíc jste psal o významu hodnoty NULL. Jenže u OUTER JOINu je význam hodnoty NULL doplněné místo neexistujících řádků jediný – výsledná sada záznamů musí v SQL obsahovat v každém řádku všechny sloupce, je tedy potřeba něco doplnit místo neexistujících řádků, a NULL je pro to vhodná hodnota.

Chápu, měl jsem to napsat přesněji, tak příště.
Díky.

Ale i kdyby: stále k tomu platí racchekovo zadání, že v tbl2 nemusí záznam existovat. A s tím si prostě v INNER JOINU neporadíte, na to nemá žádný vliv to, jestli v tabulce tbl2 ve sloupci allow může být NULL nebo ne.
Poradím si s tím snadno – když ty záznamy neexistují, asi nemají žádný význam, a je tedy v pořádku, že se do výsledné sady záznamů příslušný záznam vůbec nedostane. Všimněte si, že je to přesně to, co Racchek potřeboval, jak později napsal.

43
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 07. 10. 2019, 00:16:08 »
O záznamu s hodnotou NULL jsem nikdy nemluvil, to jste si musel domyslet jako projekci Vašich myšlenek.
V tom případě to byl někdo jiný téhož jména.

NULL může reprezentovat implicitní nastavení

NULL je v takovýchto případech naprosto správná hodnota, od toho je.

44
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 06. 10. 2019, 23:58:33 »
Domníval jsem se, že jsme oba ve stejné diskusi a že není nutné opakovat v každém postu celý kontext.
Není nutné opakovat celý kontext. Jenom je nutné neplést si dvě různé věci, „neexistenci záznamu“ a „záznam, který má v jednom sloupci hodnotu NULL“. Z této diskuse je vidět, že až to začnete rozlišovat, ozřejmí se vám mnoho věcí.

45
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 06. 10. 2019, 23:46:41 »
To jste mě špatně pochopil. Myšlena byla právě neexistence záznamu
Nepochopil jsem vás špatně. Vy jste to špatně napsal. Neexistence záznamu je něco úplně jiného, než záznam, který má v jednom sloupci hodnotu NULL.

Stran: 1 2 [3] 4 5 ... 228

reklama