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 ... 72 73 [74] 75 76 ... 206
1096
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 05. 10. 2019, 22:10:46 »
Protože buď tabulky spojíte a pak sadu filtrujete, nebo můžete tabulku spojit s filtrovanou tabulkou – a v té mnou uvedené formulaci už je to spíš to druhé.

Během optimalizace dotazu dojde query planner ke stejnému prováděcímu plánu. Jak už jsem psal výše, pro planner je totožné INNER JOIN a LEFT JOIN WHERE right.id IS NOT NULL (nebo right.id > 0, protože to implikuje IS NOT NULL). To je taková hodně základní optimalizace.

Řeknu to možná lapidárně: pokud někde vidím INNER JOIN, očekávám vazbu 1:1-N. Pokud vidím LEFT JOIN, očekávám 1:0-N. Tato čitelnost je důležitá, zejména když se na SQL příkazy dívá někdo cizí, nebo i sám po nějaké době.

1097
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 05. 10. 2019, 21:21:26 »
Vážně by mne zajímalo, jakou ještě lepší strukturu, než tuhle, byste si pro INNER JOIN představoval.

Pokud psal, že v tbl2 může, ale nemusí být odpovídající záznam, zdá se, že obě situace jsou zcela validní. V takovém případě je lepší použít OUTER JOIN a podmínku psát do WHERE. Přesně tam patří podmínky, je to mnohem čitelnější než zahazovat řádky v rámci JOINU. Optimizér si s tím poradí úplně stejně. Vhodnější je to i kvůli tomu, že podmínka se může měnit podle vstupu (např. filtrovací formulář). V tu chvíli je šikovné měnit jen WHERE sekci a neměnit joinování.

Podle Vaší logiky by bylo přípustné i SELECT ... FROM tbl1 INNER JOIN tbl2 ON tbl1. id_data = tbl2.id_data AND allowed > 1. I to by dalo stejný výsledek, ale to už je ultraprasárna.

1098
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 05. 10. 2019, 20:59:40 »
Která varianta zápisu příslušného JOINu se použije je detail, podstatné je vědět, co Racchek chce. Už to chápete?

Ano, já to chápu celou dobu, ale v obou případech je vhodnější použít LEFT OUTER JOIN, protože to odpovídá struktuře dat.

Tj. oba dotazy bych psal takto:
SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE tbl2.allowed > 0
nebo
SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE tbl2.allowed > 0 OR tbl2.allowed IS NULL

Nechť si Racchek vybere podle požadavku, ale ať tam proboha necpe INNER JOIN, když tomu struktura neodpovídá. Myslím, že je důležité si utvořit správné návyky a určitou štábní kulturu.

1099
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 05. 10. 2019, 19:56:20 »
Jsou to významově dva různé dotazy, dávají jinou sadu výsledků, a nejprve si tazatel musí rozhodnout, kterou sadu výsledků chce, teprve pak je možné říci, který dotaz k těm výsledkům vede.

Nejsou, SELECT * FROM tbl1 INNER JOIN tbl2 USING (id_data) WHERE tbl2.allowed > 0
vrátí absolutně to samé jako SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE tbl2.allowed > 0.
To druhé je ale čistší vzhledem k zadanému popisu dat (v pravé tabulce může a nemusí být odpovídající záznam).


1100
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 05. 10. 2019, 18:26:30 »
Napsal „vybrat pouze to, co v tbl2 je jako allowed >0“, to by vedlo na INNER JOIN. Pak ale doplnil, že tbl2 nemusí obsahovat všechny záznamy z tbl1 – že uvedl tuhle informaci by vedlo na OUTER JOIN, ale je možné, že ji doplnil jen z neznalosti „pro jistotu, co kdyby to na řešení mělo vliv“.

No právě protože "co kdyby" je dané jako premisa (tbl2 nemusí obsahovat záznamy), je určitě lepší praxe provést OUTER JOIN a omezení dát do WHERE. Do JOINU patří definice struktury dat, do WHERE podmínky. Pokud by použil INNER JOIN, tak by část podmínky de facto přesunul do klauzule JOIN. To se nedá doporučit, SQL by mělo být čitelné a podmínky by měly být zejm. ve WHERE. Kdyby se do budoucna rozmyslel a podmínku chtěl přeformulovat (užít např. IS NULL / IS NOT NULL), nefungovalo by to, protože řádky by zahodil JOIN.

JOINY by měly následovat strukturu dat, i když v konkrétním případě to může být zbytečné.

Co se týče výkonu, tak každé rozumné SQL si na úrovni optimizéru vyhodnotí query plan v obou případech stejně (OUTER JOIN USING id+ WHERE id IS NOT NULL  je totožné jako prostý INNER JOIN USING id). Jde tedy hlavně o čitelnost a správný návyk, jak psát SQL. (id > 0 zároveň implikuje id IS NOT NULL).

1101
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 04. 10. 2019, 18:11:12 »
Otazka ktera mela padnout - pokud druha tabulka neobsahuje allowed pro urcity prvek z prvni tabulky, povazuje se to za hodnotu allowed 0 nebo 1 ? Nebo je nutno take vedet, ze tato vlatnost nebyla nastavena?

Správná připomínka.

Z hlediska SQL se to považuje za NULL.

Myslím, že sémanticky správný je LEFT JOIN.
Následuje filtr WHERE, kde může být allowed > 0, nebo IS NULL, nebo nějaká jiná podmínka.

Pokud je podmínka WHERE allowed > 0, pak je zcela jedno, jestli se jedná o LEFT nebo INNER join. Ve chvíli, kdy by byla podmínka např. WHERE allowed = 0 OR allowed IS NULL, pak už by se rozdíl mezi LEFT a INNER projevil.

1102
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 04. 10. 2019, 17:37:10 »
proč left join?

Left join tam musí být, viz zadání úkolu: "S tím, že tbl2.id_data nemusí obsahovat všechny data v tbl1.id_data"

1103
Software / Re:Sledování tisku
« kdy: 04. 10. 2019, 14:25:34 »
Doporucujem 2 cesty:

Doporučím ještě třetí cestu:
Neřešit to.

ČB tiskárny mají levné náklady na tisk a sebeplýtvavější zaměstnanec nemůže způsobit žádnou podstatnou ztrátu. Pokud tam jsou špatně zvolené tiskárny (barevné, drahý tisk), vyřešit toto.

V praxi stačí nastavit v politikách domény automatickou instalaci tiskáren a přednastavit ČB tisk a economode. Nejvíc plýtvání je z lenosti, že si uživatelé nechají zapnutý barevný tisk. Když jim tam bude automaticky skákat ČB, přepínají na barvu jen výjimečně.

1104
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 04. 10. 2019, 12:35:15 »
ale da sa aj subselect:

Ale fuj, to bude mnohem pomalejší. Na tento příklad je jediným správným řešením LEFT JOIN + WHERE.

1105
Software / Re:Sledování tisku
« kdy: 04. 10. 2019, 10:41:49 »
Poradit neumím, ale jak se v takovém případě počítá a vychází ROI?

1106
A rozšiřující dotaz. K čemu by mi vlastně všichni ti asistenti měli být dobří? (Kdyby teda uměli česky)

Právě na to byste se toho asistenta mohl zeptat.

1107
Mě jde o to k čemu mě je u každého druhého výrobku prohlášení "podporuje asistenta google, Alexa, Siri ..." Jako Čechovi.

Typická marketingová lež. Kdybyste byl anglicky hovořící cizinec u nás, k něčemu Vám to je. Ale takhle? Přesto to tam napsat musí, mají to v materiálech od výrobce :), a kdo to nenapíše, ztrácí.

Myslím, že laik se dnes nemá šanci rozhodnout bez porady s někým z oboru, argumenty výrobců jsou "precizně mlhavé."

1108
Hardware / Re:Je zahřívání SSD důvodem k reklamaci?
« kdy: 02. 10. 2019, 17:52:01 »
Ne, já nic nezaměňuju. Já celou dobu píšu na dítě a vy pořád oponujete, že je to na rodiče. Jsem rád, že jste konečně změnil názor a souhlasíte, že je to na dítě.

Jste pěkně umíněný. Přečtěte si ten zákon pořádně:

1. Sleva na dani je pro každého rodiče, který má dítě.
2. Pokud rodiče žijí ve společné domácnosti, smí si uplatnit slevu jen jeden z nich.

Zrovna v tomto případě je textace zcela jednoznačná a ze zákona vyplývá to, co jsem nastínil. Pokud by zákonodárce chtěl  právě jednu slevu na dítě, pak by to napsal rovnou do prvního odstavce a nerozděloval to na pravidlo vs. výjimku.

1109
Hardware / Re:Je zahřívání SSD důvodem k reklamaci?
« kdy: 02. 10. 2019, 15:04:20 »
Daňové zvýhodnění není dávka. Není to něco, co by mohlo nebo nemohlo být předmětem exekuce – je to částka, o kterou se vám sníží daň. Není na rodiče, je na dítě: „daňové zvýhodnění na vyživované dítě“.

Ano, přesně tak! Je to daňové zvýhodnění (pro poplatníka) na vyživované dítě.
Vy to zaměňujete za daňové zvýhodnění pro vyživované dítě.

Ale to není předmět, co chci řešit.

Já spíš nechápu, že při výkladu jednoho zákona se držíte upjatě textu (byť důvodová zpráva říká, že zákonodárce měl na mysli harmonizaci s ES), nepřipouštíte žádnou úvahu nad smyslem ustanovení.

V druhém případě řešíte jen smysl ustanovení (byť není tak jednoznačný), ale zase ignorujete text.

Buďto tedy musíte připustit, že se dá vše vyložit různými způsoby (což je můj názor), nebo si musíte sjednotit postupy výkladu.

1110
Hardware / Re:Je zahřívání SSD důvodem k reklamaci?
« kdy: 02. 10. 2019, 14:29:11 »
Dítě podpořit v daňovém zákonu přímo nemůže, protože dítě neplatí daně a není samo ekonomicky činné. Záměr je jasný – pomoci dítěti tím, že se na daních uleví těm, kdo se o dítě starají. Jenže daně neplatí domácnost ani rodina, platí je každá osoba zvlášť, takže bylo potřeba nějak určit, kdo přesně z těch, kteří se o dítě starají, má tu úlevu dostat.

Zase střílíte vedle. Jsou dávky, které jsou adresné na dítě, a které mj. nesmí zabavit ani exekutor (nepatří rodiči, ale dítěti). Daňové zvýhodnění _není_ na dítě, je na rodiče, a exekutor ho bez okolků zabaví.

Stran: 1 ... 72 73 [74] 75 76 ... 206