Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: racchek 04. 10. 2019, 10:53:03

Název: MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: racchek 04. 10. 2019, 10:53:03
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

Díky za pomoc

Kód: [Vybrat]
tbl1
-------
id_data
-------
100
101

tbl2
-------
id_data|allowed
100    |0
101    |1
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Ondra Satai Nekola 04. 10. 2019, 11:15:05
inner join + filtr
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: robin martinez 04. 10. 2019, 11:32:03
Kód: [Vybrat]
SELECT * FROM tbl1 AS t1

INNER JOIN tbl2 AS t2
USING id_data

WHERE t2.allowed
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: e3k 04. 10. 2019, 12:19:30
>>>S tím, že tbl2.id_data nemusí obsahovat všechny data v tbl1.id_data
v tom pripade nepojde o INNER JOIN ale o LEFT OUTER JOIN

ale da sa aj subselect:

Kód: [Vybrat]
select * from tbl1 as t1
where t1.id_data NOT IN (select t2.id_data from tlb2 as t2 where t2.allowed = 0)
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: gill 04. 10. 2019, 12:55:24
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.

proč left join?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 04. 10. 2019, 17:09:29
Kód: [Vybrat]
SELECT tbl1.* FROM tbl1
  INNER JOIN tbl2 ON tbl1.id_data = tbl2.id_data
  WHERE t2.allowed>0
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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"
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: RDa 04. 10. 2019, 17:56:34
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?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 05. 10. 2019, 17:29:54
Myslím, že sémanticky správný je LEFT JOIN.
Co je sémanticky správně musí napsat Racchek. 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“.

Pro Raccheka – ke spojení několika tabulek do jednoho dotazu se v SQL používá klauzule JOIN, která má různé varianty. Je to úplný základ relačních databází, bez znalosti JOINu nemá smysl se s relační databází o cokoli pokoušet. Pokud se chcete naučit základy používání relačních databází, kupte si o tom nějakou knížku, vyšlo jich dost.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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).
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kamil Podlešák 05. 10. 2019, 19:04:00
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.
Pro každý solidní optimizér je to jedno, výsledný query plan je stejný. Samozřejmě, ne každá databáze má solidní optimizér, takže LEFT JOIN je rozhodně jistější.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 05. 10. 2019, 19:31:26
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.
Ne, tady jde především o sémantiku. O to, jestli chce Racchek provést sémanticky INNER JOIN – tedy ve výsledné sadě nebudou záznamy, které nemají záznam v tbl2, nebo chce provést sémanticky OUTER JOIN – tedy ve výsledné sadě budou takové záznamy, které v tbl2 vůbec nejsou, nebo tam jsou a allowed mají větší než nula. 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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).

Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 05. 10. 2019, 20:54:11
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).
Četl jste komentář, na který reagujete? Napíšu o SQL dotazech, ale o tom, co Racchek požaduje.

Vstupní data:

Kód: [Vybrat]
SELECT * FROM tbl1
-------
id_data
-------
100
101
102

SELECT * FROM tbl2
-------
id_data|allowed
100    |0
101    |1

Racchekovo zadání je sporné. Nevíme, zda pro výše uvedený příklad požaduje tuhle sadu výsledků („tbl2.id_data nemusí obsahovat všechny data v tbl1.id_data“):
Kód: [Vybrat]
-------
id_data
-------
101
102

Nebo tuhle sadu výsledků („vybrat pouze to, co v tbl2 je jako allowed >0“):
Kód: [Vybrat]
-------
id_data
-------
101

To první je OUTER JOIN, to druhé je INNER JOIN. 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?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 05. 10. 2019, 21:15:10
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.
Ano, je důležité si utvořit správné návyky a určitou štábní kulturu. Takže pokud Racchek má požadavek vybrat z tbl1 ty záznamy, které jsou v tbl2 a mají tam allowed > 0 má krystalicky čistý učebnicový příklad na INNER JOIN, tak by ho tak také měl napsat. Tomu vašemu příkladu s INNER JOINem psaným pomocí OUTER JOINu, který je navíc špatně, ať se zdaleka vyhne. (Ten váš příklad by vyžadoval splnění jednoho předpokladu, který ale v zadání uveden není.)

Vážně by mne zajímalo, jakou ještě lepší strukturu, než tuhle, byste si pro INNER JOIN představoval.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: e3k 05. 10. 2019, 21:40:16
a zatím co Rachek ma uz dávno napsaný svůj úkol Filip a Miroslav dále diskutují.
Jak se jmenuje tvůj profesor Rachek! proč není na root.cz? jak máme zabezpečit pedagogisticky péče bez jeho komentáře?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 05. 10. 2019, 22:01:35
Pokud psal, že v tbl2 může, ale nemusí být odpovídající záznam, zdá se, že obě situace jsou zcela validní.
To ovšem platí pro každý JOIN. Rozhodující pro volbu INNER/OUTER JOIN je to, zda neexistence záznamu v podřízené tabulce znamená, že záznamy ve výsledné sadě být nemají, nebo zda znamená, že jsou data pro ten záznam neznámá (a mají tedy být nahrazena NULL hodnotami).

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.
Stará syntaxe skutečně psala všechny podmínky do WHERE. Nová syntaxe s klíčovým slovem JOIN ale rozlišuje podmínky na ty, které se používají pro spojení tabulek, a na ty, které filtrují výslednou sadu záznamů. Ta hranice není úplně ostrá, takže se najdou případy, kdy mohou být logické obě varianty. Což ale není tento případ, tady je podle zadání jistě podmínka omezující výslednou sadu jenom allowed > 0 – všimněte si, že je uvedena v zadání samostatně, žádná jiná podmínka u ní už není. Jenom jako poznámku na konec přidal Racchek informaci, že tbl2 nemusí obsahovat všechny záznamy z tbl1, což je informace o tom, že je nutné řešit, zda použít INNER JOIN nebo OUTER JOIN. Akorát už nenapsal, která varianta platí.

Vaše tvrzení, že je to mnohem čitelnější, myslím dobře vyvrací ta skutečnost, že jste právě kvůli té vaší variantě zápisu udělal v dotazu chybu. Výhoda zápisu INNER JOIN přes klíčové slovo (INNER) JOIN je v tom, že už nemusíte specifikovat, jak se pozná, že podřízený záznam neexistuje. Ta podmínka plyne přímo z INNER JOINu a databáze ji tam přidá sama – a na rozdíl od vás správně.

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.
Ne, nic takového jsem já nepsal. Nicméně pokud by zadání bylo formulované jako „vybrat z tbl1 všechny záznamy, kde v tbl2 existuje odpovídající záznam s allowed > 0“, považoval bych to za ten hraniční případ, kdy jsou možné obě varianty. 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é.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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ě.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: gill 05. 10. 2019, 22:12:33
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"

jak jste z toho tvrzení vyvodil, že výsledek ty řádky obsahovat má?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 05. 10. 2019, 22:13:47
jak jste z toho tvrzení vyvodil, že výsledek ty řádky obsahovat má?

On je obsahovat nebude. Pokud dáte WHERE tbl2.allowed > 0, tak se ty řádky vynechají.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 05. 10. 2019, 22:24:41
...výhodou LEFT JOINU je i to, že se dá dotaz invertovat jen změnou podmíny:
SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE allowed > 0

a k tomu je opakem:
SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE allowed = 0 OR allowed IS NULL

Jak vidíte, první část se nemění, mění se pak jen podmínka. Toho s INNER JOINEM nedosáhnete.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: gill 05. 10. 2019, 22:28:17
jak jste z toho tvrzení vyvodil, že výsledek ty řádky obsahovat má?

On je obsahovat nebude. Pokud dáte WHERE tbl2.allowed > 0, tak se ty řádky vynechají.

potom nepotřebujete left join
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 05. 10. 2019, 22:31:59
potom nepotřebujete left join

Viz výše příklad s obrácením funkce. Left join je rozhodně lepší zápis, čitelnější a vyjadřuje strukturu dat. Výsledek bude stejný, ale kdokoliv se na to podívá, pochopí líp, co od toho očekávat.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 06. 10. 2019, 01:11:26
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.
O optimalizaci dotazu tady ale nikdo nemluví. Jde o sémantiku dotazu, o to, jak ho chápe vývojář.

Ř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ě.
To je ale váš problém, že SQL dotazy čtete jinak, než všichni ostatní. Znamená to, že od zápisu INNER JOIN očekáváte něco, co vám nemůže zajistit, a když pro zápis INNER JOINu používáte OUTER JOIN, musíte správně napsat tu podmínku, která z toho udělá INNER JOIN. Což se vám zrovna tady v diskusi ještě nepovedlo. Řečeno s Cimrmanem – ten váš kód je sice hůř čitelný, ale zato v něm děláte chyby.

...výhodou LEFT JOINU je i to, že se dá dotaz invertovat jen změnou podmíny:
SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE allowed > 0

a k tomu je opakem:
SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE allowed = 0 OR allowed IS NULL

Jak vidíte, první část se nemění, mění se pak jen podmínka. Toho s INNER JOINEM nedosáhnete.
Až na to, že normální lidi považují k dotazu „dej mi všechny záznamy, které mají podřízený záznam allowed > 0“ za inverzní „dej mi všechny záznamy, které mají podřízený záznam s alowed = 0“ (za předpokladu, že alowed > 0 a alowed = 0 jsou k sobě inverzní).

Viz výše příklad s obrácením funkce. Left join je rozhodně lepší zápis, čitelnější a vyjadřuje strukturu dat. Výsledek bude stejný, ale kdokoliv se na to podívá, pochopí líp, co od toho očekávat.
Když je to tedy lepší a čitelnější zápis, proč ho tu pořád píšete špatně?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 06. 10. 2019, 04:48:54
O optimalizaci dotazu tady ale nikdo nemluví. Jde o sémantiku dotazu, o to, jak ho chápe vývojář.

(...)

Až na to, že normální lidi považují k dotazu „dej mi všechny záznamy, které mají podřízený záznam allowed > 0“ za inverzní „dej mi všechny záznamy, které mají podřízený záznam s alowed = 0“ (za předpokladu, že alowed > 0 a alowed = 0 jsou k sobě inverzní).

Ha! Tak jsme u podstaty věci. Pane kolego, tak toto je školácká chyba na úrovni druhé, třetí lekce práce se SQL.
Musíte s NULL počítat! (Pro začátečníky připomenu, že SELECT 1=1 navrátí TRUE, zatímco SELECT NULL=NULL nenavrátí TRUE, ale opět NULL.)

Kupř. když v tomto případě máme:
allowed > 0 znamená: přístup povolen,
allowed = 0: přístup zakázán,
allowed IS NULL: přístup neurčen,

pak SQL pak platí, že:
inverzní k"povolen" je "zakázán + neurčen",
inverzní k "zakázán" je "povolen + neurčen",
inverzní k "neurčen" je "povolen + zakázán".

Aby toto mohl vývojář opominout, musel by být sloupec allowed nastavený NOT NULL a nemohlo by platit že záznam v pravé tabulce může či nemusí existovat.

Tím bych naši diskusi uzavřel. Je zřejmé, že SQL rozumíte, doplníte si za domácí úkol studium NULL a to, jak je s ním potřeba v SQL počítat a co to znamená "sémantika".
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 06. 10. 2019, 08:47:01
Ha! Tak jsme u podstaty věci. Pane kolego, tak toto je školácká chyba na úrovni druhé, třetí lekce práce se SQL.
Omlouvám se, nebylo mým cílem nachytat vás na švestkách. Ale chytil jste se krásně.

pak SQL pak platí, že:
Já jsem ale nepsal o SQL. Psal jsem o tom, jaké je obvykle zadání, jak to vnímají lidé, jak to obvykle plyne z logiky věci. Když budete mít zadání „vypište všechny uživatele, kteří bydlí v Praze“, bude k tomu obvykle inverzní zadání „vypište všechny uživatele, kteří bydlí mimo Prahu“, ne „vypište všechny uživatele, kteří bydlí mimo Prahu nebo nebydlí vůbec“. Abyste se v tom neztratil, tu podmínku jsem vám přímo slovně napsal.

Musíte s NULL počítat! […] Aby toto mohl vývojář opominout, musel by být sloupec allowed nastavený NOT NULL a nemohlo by platit že záznam v pravé tabulce může či nemusí existovat.
Výborně, takže to, že allowed může být nullable, vás napadlo.

Tím bych naši diskusi uzavřel. Je zřejmé, že SQL rozumíte, doplníte si za domácí úkol studium NULL a to, jak je s ním potřeba v SQL počítat.
Pane kolego, domácí úkol tady bude dělat někdo jiný, totiž vy. Když už teď víte, že allowed může být nullable, a také víte, že NULL hodnotám je potřeba věnovat zvláštní péči, projdete si všechny ty INNER JOINy zapsané pomocí OUTER JOINu, které jste do diskuse napsal. Teď už snad konečně uvidíte tu školáckou chybu, kterou jste ve všech svých příkladech udělal. Tu chybu opravíte a zapamatujete si, že je dobré používat nástroje k tomu, k čemu jsou určené – takže když je sémantika příkazu INNER JOIN, je rozumné to napsat pomocí INNER JOINu a ne to znepřehledňovat OUTER JOINem, zejména, když neumíte správně napsat podmínku, která ten INNER JOIN definuje.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 06. 10. 2019, 09:02:37
Já jsem ale nepsal o SQL. Psal jsem o tom, jaké je obvykle zadání, jak to vnímají lidé, jak to obvykle plyne z logiky věci. Když budete mít zadání „vypište všechny uživatele, kteří bydlí v Praze“, bude k tomu obvykle inverzní zadání „vypište všechny uživatele, kteří bydlí mimo Prahu“, ne „vypište všechny uživatele, kteří bydlí mimo Prahu nebo nebydlí vůbec“. Abyste se v tom neztratil, tu podmínku jsem vám přímo slovně napsal.

Co na to říct? Opak "bydlí v Praze" je "neplatí, že bydlí v Praze", tedy "nebydlí v Praze".
Do "nebydlí v Praze" i v běžné řeči patří ti, co nebydlí nikde (např. turisté), nikoliv jen obyvatelé ostatních obcí v ČR.

Už poměrně chápu, proč jsme se ve vedlejší diskusi nemohli shodnout na výkladu zákona.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 06. 10. 2019, 10:15:41
Co na to říct? Opak "bydlí v Praze" je "neplatí, že bydlí v Praze", tedy "nebydlí v Praze".
Do "nebydlí v Praze" i v běžné řeči patří ti, co nebydlí nikde (např. turisté), nikoliv jen obyvatelé ostatních obcí v ČR.
Logika přirozeného jazyka je jiná, než programátorská logika. Když marketingu vyjde, že lidi v Praze je potřeba oslovit jiným dárkem, než lidi ve zbytku ČR, bude chtít dvě opačné sady záznamů – obyvatele Prahy a obyvatele z jiných obcí, než je Praha. Bezdomovce, u kterých neznají adresu, opravdu řešit nebudou. Když bude ředitel firmy chtít seznam vedoucích, kteří mají plat přes 50 tisíc, vzpomene si později, že chce i seznam vedoucích, kteří mají méně než 50 tisíc. Nebude chtít seznam vedoucích, kteří mají méně než 50 tisíc, a všech ostatních zaměstnanců.

Mimo jiné proto byla do databází zavedena hodnota NULL, protože v reálném životě se běžně stává, že můžete záznamy rozdělit do několika disjunktních skupin, a pak máte záznamy, které nepatří do žádné skupiny. A ty záznamy, které nepatří nikam, se neberou v úvahu u množinových operací jako je doplněk. Proto se NULL chová tak divně s operátory, že když použijete operátor a jeho negaci, pro NULL hodnoty není splněna ani jedna podmínka, třeba x = 0 OR x != 0 pro NULL hodnoty není vyhodnoceno jako pravdivý výraz.

je to právě proto, aby bylo snadné psát v SQL dotazy z reálného života a nebylo nutné používat ty vaše komplikované konstrukce.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 06. 10. 2019, 10:18:19
Logika přirozeného jazyka je jiná, než programátorská logika. Když marketingu vyjde, že lidi v Praze je potřeba oslovit jiným dárkem, než lidi ve zbytku ČR, bude chtít dvě opačné sady záznamů – obyvatele Prahy a obyvatele z jiných obcí, než je Praha. Bezdomovce, u kterých neznají adresu, opravdu řešit nebudou.

Hm, měl jsem pocit, že sem chodí spíš programátoři, než markeťáci. Pokud někdo tvoří SQL, musí se umět vyjadřovat i přijímat informace exaktně, ne jako vechtr. Možná jsem se zmýlil.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 06. 10. 2019, 10:25:32
Hm, měl jsem pocit, že sem chodí spíš programátoři, než markeťáci. Pokud někdo tvoří SQL, musí se umět vyjadřovat i přijímat informace exaktně, ne jako vechtr. Možná jsem se zmýlil.
Programátoři ovšem musí psát programy podle zadání, ne podle toho, jak se jim to hodí. Když dostanou zadání „vytvoř dva dotazy, jeden s allowed = 0 a druhý s allowed > 0“, nemohou se jen tak rozhodnout, že ty dotazy nejsou programátorsky inverzní a předělat je.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 06. 10. 2019, 10:28:51
Programátoři ovšem musí psát programy podle zadání, ne podle toho, jak se jim to hodí. Když dostanou zadání „vytvoř dva dotazy, jeden s allowed = 0 a druhý s allowed > 0“, nemohou se jen tak rozhodnout, že ty dotazy nejsou programátorsky inverzní a předělat je.

To nerozporuju.

Celou dobu tvrdím, že zápis přes OUTER JOIN je univerzální vzhledem k informacím co máme, protože podmínku, ať ji vymyslíte, jak ji vymyslíte, půjde dát pouze do WHERE. Pokud použijete INNER JOIN, bude to fungovat jen v případech, které popisujete Vy.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 06. 10. 2019, 10:59:07
1) Původní zadání je nejednoznačný - právě proto, že normální lidi nemyslej v nulách a jedničkách, tak tím mohou myslet obojí.
Tabulka s allowed může znamenat "právě Ti, co mají dovoleno" (to bývá častější), ovšem i "Ti, co mají právo nějak upraveno oproti jinde získanému standardnímu stavu".
V prvním případě pak dává smysl negace s INNER JOINEm, v druhém s LEFT JOINEM.
 
2) Dobrej programátor proto neiplementuje půl dne něco nejasnýho, ale nejprve se zeptá. Filipova teze, že se to myslelo určitě takhle, a kdo to pochopil jinak je blbej - to je přesně případ programátorský arogance, kterej vede na zbytečnou práci.

3) Když už bych si měl z těch variant vybrat, tak na tezi, že LEFT JOIN umožňuje zachytit obě sémantiky, takže je lepší použít ho a podle dohovoru s klientem popř. poupravit detail má něco do sebe. INNER JOIN bejvá výkonnější, ale dneska si to databáze stejně zoptimalizujou.

4) Ovšem pokud se to vztáhne na reálný problém "kdo kde bydlí", tak opravdu ti, co nebydlí nikde, nebydlí ani v Praze. Tendle příklad se Ti Filipe fakt nepovedl.

5) "Když dostanou zadání „vytvoř dva dotazy, jeden s allowed = 0 a druhý s allowed > 0“
je hezká ale trochu chabá snaha se z toho nepovedeného příkladu vykroutit. O sémantice negace se v zadání vůbec nemluvilo.
A protože Tebou "axiomovaný" způsob jen jeden z dvou možných způsobů negování původního dotazu, tak jde o krásný případ důkazu kruhem: Negace vypadá takto a proto je správné moje chápání negace a proto negace vypadá takto.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 06. 10. 2019, 11:48:16
Filipova teze, že se to myslelo určitě takhle, a kdo to pochopil jinak je blbej - to je přesně případ programátorský arogance, kterej vede na zbytečnou práci.
Jasně, a ta moje teze se projevuje tím, že jsem byl první (https://forum.root.cz/index.php?topic=21909.msg317937#msg317937), kdo tu explicitně napsal, že to zadání je nejednoznačné, napsal jsem oba dva možné významy a také které řešení se pro který případ použije.

3) Když už bych si měl z těch variant vybrat, tak na tezi, že LEFT JOIN umožňuje zachytit obě sémantiky, takže je lepší použít ho a podle dohovoru s klientem popř. poupravit detail má něco do sebe. INNER JOIN bejvá výkonnější, ale dneska si to databáze stejně zoptimalizujou.
Můžete se na to dívat tak, že INNER JOIN je jen speciální případ OUTER JOINu. Ale to bychom pak INNER JOIN nepotřebovali, že… Protože se ale INNER JOIN sémantika v reálném světě vyskytuje docela často, a napsat ji pomocí OUTER JOINu není úplně triviální, jak ukazují četné neúspěšné pokusy Miroslava Šilhavého, máme pro ten speciální případ také speciální syntaxi.

Ovšem pokud se to vztáhne na reálný problém "kdo kde bydlí", tak opravdu ti, co nebydlí nikde, nebydlí ani v Praze. Tendle příklad se Ti Filipe fakt nepovedl.
Já jsem ale neuváděl tenhle případ. Já jsem uváděl příklad „bydlí v Praze“ × „bydlí mimo Prahu“. Ten, kdo nebydlí nikde, nebydlí ani v Praze ani mimo Prahu.

5) "Když dostanou zadání „vytvoř dva dotazy, jeden s allowed = 0 a druhý s allowed > 0“
je hezká ale trochu chabá snaha se z toho nepovedeného příkladu vykroutit. O sémantice negace se v zadání vůbec nemluvilo.
A protože Tebou "axiomovaný" způsob jen jeden z dvou možných způsobů negování původního dotazu, tak jde o krásný případ důkazu kruhem: Negace vypadá takto a proto je správné moje chápání negace a proto negace vypadá takto.
Negace nebyla v zadání, negaci sem přitáhl až Mirek Šilhavý. Já jsem jenom uváděl příklady, že v přirozeném jazyce znamená negace často něco jiného než prostý doplněk množiny. Často pozitivní ani negativní množina neobsahuje NULL hodnoty, s těmi se zachází speciálně – proto je to tak implementováno i v SQL.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 06. 10. 2019, 11:56:01
INNER JOIN bejvá výkonnější, ale dneska si to databáze stejně zoptimalizujou.

Udělal jsem na to schválně test (na PostgreSQL). Podle očekávání ve všech třech případech si to SQL zoptimalizovalo na tutéž náročnost:

root=# EXPLAIN SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE allowed > 0;
                        QUERY PLAN
----------------------------------------------------------
 Nested Loop  (cost=0.00..2.07 rows=1 width=8)
   Join Filter: (tbl1.id_data = tbl2.id_data)
   ->  Seq Scan on tbl2  (cost=0.00..1.02 rows=1 width=8)
         Filter: (allowed > 0)
   ->  Seq Scan on tbl1  (cost=0.00..1.02 rows=2 width=4)
(5 rows)


root=# EXPLAIN SELECT * FROM tbl1 INNER JOIN tbl2 USING (id_data) WHERE allowed > 0;
                        QUERY PLAN
----------------------------------------------------------
 Nested Loop  (cost=0.00..2.07 rows=1 width=8)
   Join Filter: (tbl1.id_data = tbl2.id_data)
   ->  Seq Scan on tbl2  (cost=0.00..1.02 rows=1 width=8)
         Filter: (allowed > 0)
   ->  Seq Scan on tbl1  (cost=0.00..1.02 rows=2 width=4)
(5 rows)


root=# EXPLAIN SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE tbl2.id_data IS NOT NULL AND allowed > 0;
                        QUERY PLAN
-----------------------------------------------------------
 Nested Loop  (cost=0.00..2.07 rows=1 width=8)
   Join Filter: (tbl1.id_data = tbl2.id_data)
   ->  Seq Scan on tbl2  (cost=0.00..1.02 rows=1 width=8)
         Filter: ((id_data IS NOT NULL) AND (allowed > 0))
   ->  Seq Scan on tbl1  (cost=0.00..1.02 rows=2 width=4)
(5 rows)
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 06. 10. 2019, 13:12:41
Citace
Jasně, a ta moje teze se projevuje tím, že jsem byl <a href="https://forum.root.cz/index.php?topic=21909.msg317937#msg317937 (https://forum.root.cz/index.php?topic=21909.msg317937#msg317937)" rel="nofollow" class="bbc_link" target="_blank">první, kdo tu explicitně napsal
To sice ano, ale pak jsi to hned zabil nesmyslným trváním na tom, že jeden způsob negace je lepší.

Citace
. Ale to bychom pak <tt class="bbc_tt">INNER JOIN</tt> nepotřebovali,
Potřebovali.
 Protože je třeba odlišit variantu záznam existuje, ale je NULL a záznam
 neexistuje, což je případ, který se vyskytuje hodně zřídka a je normální DB navrhovat tak, aby pokud možno toto nebyl rozdíl - protože defakto oba stavy jsou reálně pochopitelné jako "neurčeno" a

- pokud mají sémantickou odlišnost, pak musí být explicitně vysvětlena, struktura není samovysvětlující. Navíc se s takovou databází pracuje špatně, právě kvůli výsledným problémům s negací. V takovém případě je daleko vhodnější sémantickou hodnotu: záznam je,ale je "nejasný" zachytit nikoli hodnotou NULL, ale nějak jinak.Samozřejmě asi se dá najít speciální příklad, kdy takový návrh bude mít opodstatnění, ale to je takový výjimka, že točit se na něm při řešení evidentně triviálního případu je poněkud demagogické.
- a pokud nemají sémantickou odlišnost, pak je chyba návrhu, že jedna skutečnost může být postihnuta různými stavy v DB.
Proto nepovažuji Miroslavovy dotazy za chybu - prostě předpokládal standardně rozumně navrženou databázi. Pokud naopak na těchto drobných odlišnostech bazíruješ, tak by to mělo být pro Tebe důvod k zamyšlení, nad jak kvalitními strukturami DB jsi zvyklý pracovat.

A pokud tedy opravdu na distinkci výše nezáleží, pak použití INNER/OUTER JOINu je na programovacím stylu. Jak Tvůj argument (že v raritním případě může dojít k sémantické odlišnosti), tak Miroslavova (že se to lépe upravuje při změně sémantiky) je validní, ale Miroslavův argument je daleko více "z praxe".

Citace
Já jsem ale neuváděl tenhle případ. Já jsem uváděl příklad „bydlí v Praze“ × „bydlí mimo Prahu“.
Ne, ty jsi uváděl "Bydlí v Praze" a tvrdil jsi, že jediná přirozená negace je "Bydlí mimo Prahu". Což prostě v totmo případě opravdu není pravda. Když odpovím na "Bydlíš v Praze?" "Ne", tak tím nijak nevylučuji to, že jsem digitální nomád a nebydlím nikde.

Citace
Já jsem jenom uváděl příklady, že v přirozeném jazyce znamená negace často něco jiného než prostý doplněk množiny.
Ne, jen ses o to snažil a ten příklad se Ti fakt nepovedl. A na základě toho špatného příkladu si vyvozoval obecný princip, "že není správné použít přesnou negaci", který měl zpětně podpořit ten Tvůj špatnej příklad.

Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 06. 10. 2019, 13:25:50
Ne, ty jsi uváděl "Bydlí v Praze" a tvrdil jsi, že jediná přirozená negace je "Bydlí mimo Prahu". Což prostě v totmo případě opravdu není pravda. Když odpovím na "Bydlíš v Praze?" "Ne", tak tím nijak nevylučuji to, že jsem digitální nomád a nebydlím nikde.

Já jsem tedy vycházel z prosté úvahy. Mám sloupec "allowed" (povoleno), který může být 0 (nepovoleno) nebo >0 (povoleno). Pokud daný sloupec neexistuje (je NULL), nenaváže se, pak "povoleno" není určeno => tedy "není povoleno" = "je zakázáno".

Pokud by byl sloupec nazván "disallowed", "prohibited" či "restricted", pak bych NULL hodnotě přiřkl význam opačný => "není zakázáno" = "je povoleno".

Uznávám, že tato úvaha nemusí v praxi platit, např. pokud by se uplatňovala vícestupňová evalvace práv (pokud nenajdu oprávnění na své úrovni, podívám se o úroveň výš, výš, až nahoru) - v tom případě by měl NULL svůj význam. Ale i v tom případě OUTER JOIN poslouží líp, než INNER JOIN.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kamil Podlešák 06. 10. 2019, 15:31:14
INNER JOIN bejvá výkonnější, ale dneska si to databáze stejně zoptimalizujou.

Udělal jsem na to schválně test (na PostgreSQL). Podle očekávání ve všech třech případech si to SQL zoptimalizovalo na tutéž náročnost:
Sorry že se do toho pletu, ale


Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 06. 10. 2019, 16:02:06
To sice ano, ale pak jsi to hned zabil nesmyslným trváním na tom, že jeden způsob negace je lepší.
Odkazujete na komentář, kde jsem znova zopakoval, že zadání musí upřesnit tazatel.

Potřebovali. Protože je třeba odlišit variantu záznam existuje, ale je NULL a záznam
 neexistuje
Než bylo do SQL zavedeno klíčové slovo JOIN, nikdo to podle vás nepotřeboval?

Proto nepovažuji Miroslavovy dotazy za chybu - prostě předpokládal standardně rozumně navrženou databázi.
Přečtěte si ty dotazy ještě jednou a pozorněji – zejména se zaměřte na to, který sloupeček testuje na NULL.

A pokud tedy opravdu na distinkci výše nezáleží, pak použití INNER/OUTER JOINu je na programovacím stylu. Jak Tvůj argument (že v raritním případě může dojít k sémantické odlišnosti), tak Miroslavova (že se to lépe upravuje při změně sémantiky) je validní, ale Miroslavův argument je daleko více "z praxe".
Já si myslím, že o praxi vypovídá to, proč JOIN bez upřesnění je zkratka zrovna pro INNER JOIN. Že by to bylo proto, že je to nejčastější použití? Snadnost úpravy při jedné specifické změně sémantiky je irelevantní, existují miliony jiných změn sémantiky, kvůli kterým budete muset třeba přidávat další tabulku do dotazu nebo dotaz úplně předělat.

Ne, ty jsi uváděl "Bydlí v Praze" a tvrdil jsi, že jediná přirozená negace je "Bydlí mimo Prahu". Což prostě v totmo případě opravdu není pravda. Když odpovím na "Bydlíš v Praze?" "Ne", tak tím nijak nevylučuji to, že jsem digitální nomád a nebydlím nikde.
Já vím, co jsem uváděl – a vy si to můžete přečíst.

Ne, jen ses o to snažil a ten příklad se Ti fakt nepovedl. A na základě toho špatného příkladu si vyvozoval obecný princip, "že není správné použít přesnou negaci", který měl zpětně podpořit ten Tvůj špatnej příklad.
Můj příklad se povedl, nepovedl se váš příklad, který vznikl jako volná variace na téma mého příkladu. Nevyvozoval jsem z toho ani vámi uváděný obecný princip, pouze jsem upozorňoval na to, že přístup Mirka Šilhavého „všichni se na to dívají jako programátoři, a pokud explicitně uvedete příklad, kdy se na to někdo dívá jinak, stejně se na to dívá špatně, protože by se na to měl dívat jako programátor“.

Ale vidím, že celý váš komentář sestává jen z toho, co jsem údajně měl napsat, ale ve skutečnosti jsem to nenapsal. Vyvracet to znova u každého vašeho komentáře mi připadá zbytečné, považujme to za výchozí stav a tím pádem je zbytečné, abych na vaše komentáře reagoval.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 06. 10. 2019, 16:05:33
Já jsem tedy vycházel z prosté úvahy. Mám sloupec "allowed" (povoleno), který může být 0 (nepovoleno) nebo >0 (povoleno). Pokud daný sloupec neexistuje (je NULL), nenaváže se, pak "povoleno" není určeno => tedy "není povoleno" = "je zakázáno".
Mít strukturu databáze, kde hodnoty >= 1 znamenají „povoleno“ a hodnoty 0 a NULL znamenají zakázáno, není dobrý nápad. Každý stav by měl být reprezentován právě jednou hodnotou.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: robin martinez 06. 10. 2019, 16:31:04
...
Mít strukturu databáze, kde hodnoty >= 1 znamenají „povoleno“ a hodnoty 0 a NULL znamenají zakázáno, není dobrý nápad. Každý stav by měl být reprezentován právě jednou hodnotou.

presne tak
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 06. 10. 2019, 17:07:57
 :'(
Citace
Odkazujete na komentář, kde jsem znova zopakoval, že zadání musí upřesnit tazatel.
A to, že jsi jednou napsal rozumnou věc jako znamená, že jsi v dalších příspěvcích nemohl začít tvrdit blbiny???
Citace
Snadnost úpravy při jedné specifické změně sémantiky je irelevantní,
Pokud je to změna sémantiky, která se dá očekávat, protože je v tomto smyslu nejasné zadání, tak to rozhodně irelevantní není. Dobrý programátor toto kritérium při designu programu zohledňuje: je to jedna z poměrně klíčových vlastností dobrého kódu.

Citace
Já vím, co jsem uváděl – a vy si to můžete přečíst.
Evidentně furt nevíte, co jste napsal za nesmysl. Prostě pokud někdo řekne, že chce všechny pražáky, a pak řekne,že ty ostatní, tak rozhodně nechce explicitně vyloučit ty, co nikde nebydlí. To jste jednoznačně popíral a to je prostě nesmysl.A pokud jste to popírat nechtěl, tak se holt smiřte s tím, že se neumíte vyjadřovat a pochopili jsme to tu prostě jinak, nežjste chtěl. Vzhledem k tomu, že je nás víc, tak asi nebude chyba na přijímači.
Btw. i Vaše ostatní příklady byly nesmyslné: např. příklad s vedoucím, tak tam jednou bude chtít vedoucí, co mají plat nad 50. A podruhé bude chtít ostatní vedoucí. Tedy všechny vedoucí, kteří nespadli do první kategorie - např. tedy i tyu kterých není plat znám. Rozhodně by Vás šéf nepochválil, kdybyste mu jednoho šéfa, u kterého není v IS plat znám,nedodal. To, že nebudou chtít běžné zaměstnance je nesmyslný argument - být vedoucím a mít plat je ortogonální kritérium,selekce podle jednoho nemá s tím druhým nic společného.

A koneckonců i v případě samotné Prahy jste vlastně sám se sebou ve sporu, protože přiznáváte, že: "Bezdomovce, u kterých neznají adresu, opravdu řešit nebudou.". ŘEŠIT NEBUDOU. Tedy nikoli, že jim nechtějí dát dárek - tedy že explicitně chtějí null hodnoty vyloučit, jak tvrdíte.

Obecně jsou dvě možnosti: buď si člověk možnost "třetí hodnoty" uvědomuje, pak ji zpravidla řeší explicitně. Daleko častější je ovšem to, že si tuto možnost vůbec neuvědomuje, a negací nějakého kritéria myslí: "Všechny ostatní".

Citace
proč JOINbez upřesnění je zkratka zrovna pro INNER JOIN. Že by to bylo proto, že je to nejčastější použití? Snadnost
Vzhledem k tomu, že standard SQL je všechno, jen ne úsporný - a preferuje ukecanost a relační čistotu před praktičností, tak to je špatný argument. Např. většina políček v db je dnes not null, a přeci je to nutné explicitně uvádět.

A btw..., když si tak horoval za pravou sémantiku SQL dotazů, tak zrovna sémantika NULL je v SQL pěkně zmršená(jeden z mnoha problémů např. https://www.oreilly.com/library/view/sql-and-relational/9781449319724/ch04s04.html)Furt (https://www.oreilly.com/library/view/sql-and-relational/9781449319724/ch04s04.html)Furt) se tu oháníte "pravou sémantikou SQL" a jak se jí mají lidé držet. Jenže ona ta "původní sémantika" SQL byla vytvořená
teoretikama a pro praxi se příliš nehodí.

Citace
Mít strukturu databáze, kde hodnoty >= 1 znamenají „povoleno“ a hodnoty 0 a NULL znamenají zakázáno, není dobrý nápad. Každý stav by
měl být reprezentován právě jednou hodnotou.
Opět směšuješ NULL a neuvedeno. Pro NULL to je zcela pravda. Ale v případě oprávnění, kde daná osoba může mít oprávnění pocházející z více zdrojů, je struktura, kde jsou existující oprávnění uložené, a ty co nejsou, prostě nejsou, naprosto normální a správná. A v takovém případě - pokud existuje i způsob jak určit "defaultní právo", tak má smysl i rozlišovat stav 0 = zakázáno.
Takže tady zmiňuješ sice správnou zásadu, ale na nesprávném místě.
A btw. i to explicitní NULL by v takové db struktuře mělo smysl, pokud by ta tabulka s právama obsahovala ještě něco dalšího a šlo by o denormalizaci: což je opět věc, kde se střetává teoretizování s realitou.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: racchek 06. 10. 2019, 17:15:28
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.
Ano, je důležité si utvořit správné návyky a určitou štábní kulturu. Takže pokud Racchek má požadavek vybrat z tbl1 ty záznamy, které jsou v tbl2 a mají tam allowed > 0 má krystalicky čistý učebnicový příklad na INNER JOIN, tak by ho tak také měl napsat. Tomu vašemu příkladu s INNER JOINem psaným pomocí OUTER JOINu, který je navíc špatně, ať se zdaleka vyhne. (Ten váš příklad by vyžadoval splnění jednoho předpokladu, který ale v zadání uveden není.)

Vážně by mne zajímalo, jakou ještě lepší strukturu, než tuhle, byste si pro INNER JOIN představoval.

Ano, přesně takto jsem to myslel. Vezmi sadu z tbl1.id_data, přičemž v tbl2.id_data musí existovat a zároveň tbl2.allowed>0
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 06. 10. 2019, 19:54:14
Ano, přesně takto jsem to myslel. Vezmi sadu z tbl1.id_data, přičemž v tbl2.id_data musí existovat a zároveň tbl2.allowed>0

Pak je bude fungovat INNER JOIN, ale LEFT JOIN bude správnější, protože umožní obrátit výběr (selektovat záznamy, které mají allowed=0 nebo nemají odpovídající záznam v tbl2).
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 06. 10. 2019, 20:00:38
Mít strukturu databáze, kde hodnoty >= 1 znamenají „povoleno“ a hodnoty 0 a NULL znamenají zakázáno, není dobrý nápad. Každý stav by měl být reprezentován právě jednou hodnotou.

NULL může reprezentovat implicitní nastavení (právo nebylo explicitně definované ani jako allow, ani jako disallow).
Správější by bylo tedy nikoliv "zakázáno", ale "nepovoleno".

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

Můžu pak pokládat dotazy:
1. Kdo má povoleno? (allow = 1)
2. Kdo nemá povoleno? (variatněn: allow = 0 OR tbl2.id_data IS NULL nebo jen tbl2.id_data IS NULL)
3. Kdo má zakázáno? (allow = 0)

Všechny tyto tři dotazy můžete položit pouze v případě LEFT OUTER JOINU. S INNER JOINEM zvládnete obsloužit pouze otázky 1. a 3.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 06. 10. 2019, 20:37:28
Pak je bude fungovat INNER JOIN, ale LEFT JOIN bude správnější, protože umožní obrátit výběr (selektovat záznamy, které mají allowed=0 nebo nemají odpovídající záznam v tbl2).
Já bych se spíš soustředil na to, aby ten dotaz vracel ty záznamy, které má. Vzhledem k tomu, jak dlouho vám trvalo, než jste zjistil, kde máte chybu, bych nedoporučoval obcházet sémantický INNER JOIN zapsaný v SQL pomocí OUTER JOINu a přidané podmínky jenom proto, že pak dotaz snáze zmodifikujete do jiného arbitrárně vybraného dotazu.

Vzhledem k tomu, že nevíte vůbec nic o řešení doméně, totiž „obrácený výběr“ klidně může znamenat záznamy, které existují a mají allowed=0.

S INNER JOINEM zvládnete obsloužit pouze otázky 1. a 3.
S INNER JOINem samozřejmě zvládnu obsloužit i otázku 2. Už zase si pletete NULL hodnotu v datovém sloupci a neexistující záznam. To máte z toho vašeho čarování s JOINy – kdybyste se smířil s tím, že JOIN slouží ke spojení tabulek a varianta INNER nebo OUTER rozhoduje o tom, jak se bude zacházet se záznamy, které v některé tabulce neexistují, tyhle chyby byste nedělal. Neexistující záznam je něco jiného, než neexistující hodnota v záznamu, před čímž vy neustále svým OUTER JOINem zavíráte oči.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 06. 10. 2019, 20:39:48
S INNER JOINem samozřejmě zvládnu obsloužit i otázku 2. Už zase si pletete NULL hodnotu v datovém sloupci a neexistující záznam. To máte z toho vašeho čarování s JOINy – kdybyste se smířil s tím, že JOIN slouží ke spojení tabulek a varianta INNER nebo OUTER rozhoduje o tom, jak se bude zacházet se záznamy, které v některé tabulce neexistují, tyhle chyby byste nedělal. Neexistující záznam je něco jiného, než neexistující hodnota v záznamu, před čímž vy neustále svým OUTER JOINem zavíráte oči.

Nehovořím o datovém sloupci, ale o klíči, přes který se to spojuje. Id_data v joinované tabulce nikdy nebude NULL, kromě případu, že k joinu nedojde.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 06. 10. 2019, 23:12:43
Miroslav:
Citace
NULL může reprezentovat implicitní nastavení.... NULL je v takovýchto případech naprosto správná hodnota, od toho je.
To bych se hádal. Null znamená "nevím", "není jisté", "není definované". Proto se také chová tak jak se chová. "Nemá explicitně definované právo" není "nevím", to je přesně definovaný stav.
Použití NULL je IMHO v takovém případě nevhodné - např. proto, že to zesložiťuje dotazy (dotaz na explicitně nedefinovaná práva vypadá jinak než dotaz na zakázaná). V takovémto případě je IMHO nejlepší využít (not null) ENUM typu s hodnotami(ANO, NE, NEDEFINOVÁNO).
Ono vůbec, jak jsem psal, NULL je poměrně problematický rys SQL jazyka a je lepší se mu co to jde vyhýbat.

Filip:
Citace
....Vzhledem k tomu, jak dlouho vám trvalo, než jste zjistil....
Neschopnost myšlenku opustit.
Citace
S INNER JOINem samozřejmě zvládnu obsloužit i otázku 2.
A jak? Teda pokud nepoužijete nějaké except, což je jen zakuklený outer join.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 06. 10. 2019, 23:18:34
V takovémto případě je IMHO nejlepší využít (not null) ENUM typu s hodnotami(ANO, NE, NEDEFINOVÁNO).
Ono vůbec, jak jsem psal, NULL je poměrně problematický rys SQL jazyka a je lepší se mu co to jde vyhýbat.

V praxi je problematické právě to NEDEFINOVÁNO. Znamenalo by to ke každému nedefinovanému oprávnění ukládat záznam. Např. když založíte nového uživatele, musel byste ke všem uzlům v systému přidat záznam NEDEFINOVÁNO. Proti tomu NULL vznikne na pravé straně LEFT JOINU, pokud nenajde odpovídající záznam. Proto je potřeba s ním počítat. (OUTER JOINY by ostatně nemohly ani existovat, pokud by neměly nematchující sloupce doplnit NULLY).

Osobně proti NULLŮM nic nemám. Tam, kde může být definováno NOT NULL, je to jednodušší. Ne všude to jde. Pak to chce trochu cviku na jejich výskyt nezapomenout, a už to člověku ani nepřijde jako složitost.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 06. 10. 2019, 23:30:25
Nehovořím o datovém sloupci, ale o klíči, přes který se to spojuje. Id_data v joinované tabulce nikdy nebude NULL
Hezky jste si vyvrátil svůj předchozí komentář. vy v tom tedy máte děsný hokej… Datový sloupec allow může ve vašem příkladu nabývat hodnot 0, 1 a NULL. id_data nikdy NULL nebude. Spojuje se přes id_data, takže přes to připojíte řádek z druhé tabulky, a v něm může být allow=NULL, což je třeba ten váš případ implicitního nastavení. Samozřejmě může nastat i případ, že se žádný řádek nepřipojí, protože v druhé tabulce neexistuje – to je ale jiný případ, než vámi popisovaný případ allow=NULL.


kromě případu, že k joinu nedojde.
Ne, pořád si to pletete. Neexistence řádku a NULL hodnota v některém datovém sloupci jsou dvě různé věci. Dokonce i kdybyste měl řádek plný samých NULL hodnot (i to jde vyrobit), pořád je to něco jiného, než neexistující řádek. Nenechte se mást tím, že při OUTER JOINu doplní databáze NULL hodnoty na místo těch dat, pro která nemá řádky z druhé tabulky.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 06. 10. 2019, 23:37:28
Citace
S INNER JOINem samozřejmě zvládnu obsloužit i otázku 2.
A jak? Teda pokud nepoužijete nějaké except, což je jen zakuklený outer join.

Jak získám záznamy, které mají v tbl2 záznam s hodnotou allow = 0 nebo allow IS NULL? No jednoduše:

Kód: [Vybrat]
SELECT * FROM tbl1 JOIN tbl2 USING (id_data) WHERE allow = 0 OR allow IS NULL
Zaznamenal jste, že Miroslav Šilhavý určil pro implicitní nastavení hodnotu NULL, že? Aby mohl mít záznam hodnotu allow=NULL, musí existovat. Tudíž není ho INNER JOIN připojí.

Kdyby implicitní hodnota byla reprezentovaná neexistencí záznamu, to by bylo něco jiného.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 06. 10. 2019, 23:42:09
Zaznamenal jste, že Miroslav Šilhavý určil pro implicitní nastavení hodnotu NULL, že? Aby mohl mít záznam hodnotu allow=NULL, musí existovat. Tudíž není ho INNER JOIN připojí.

Kdyby implicitní hodnota byla reprezentovaná neexistencí záznamu, to by bylo něco jiného.

To jste mě špatně pochopil. Myšlena byla právě neexistence záznamu, která je ve výsledku joinu interpretována jako NULL. Vkládat řádek s hodnotou allow=NULL je pitomost, celý sloupec allow by bylo vhodné spíš deklarovat jako NOT NULL.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 06. 10. 2019, 23:49:48
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.

Celou tuto diskusi vedeme o podmínce, která se aplikuje na výsledek INNER / OUTER JOINU.
Celá tato diskuse je od začátku o tom, že v tbl2 nemusí existovat odpovídající záznam.
Celá tato diskuse je následně o tom, jestli se dá neexistence záznamu (reprezentovaná NULLEM ve výsledku joinu) interpretovat jako zákaz.

Domníval jsem se, že jsme oba ve stejné diskusi a že není nutné opakovat v každém postu celý kontext.
Uznávám, moje chyba.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 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í.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 07. 10. 2019, 00:03:48
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í.

O záznamu s hodnotou NULL jsem nikdy nemluvil, to jste si musel domyslet jako projekci Vašich myšlenek. Já řeším pouze otázku INNER / OUTER JOINU v kontextu toho, že v tbl2 může a nemusí příslušný záznam existovat. Pokud jsem hovořil o sloupci allow, jedině jakožto výsledném sloupci (outer) joinu.

Ukládat NULL do sloupce allow v tabulce tbl2 by byla hovadina. Pokud jste tímto směrem vedl argumentaci, pak zbytečně a můžeme toto téma opustit a znovu se věnovat pouze té otázce joinu a jeho interpretaci různých situací.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 07. 10. 2019, 00:18:42
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.

Moje tvrzení se stále týkala výsledku JOINU. V implicitním nastavení nemáte patřičný záznam v tabulce tbl2 a tudíž se ve výsledku joinu objeví hodnota NULL. A je v takovém případě zcela na místě.

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

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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 07. 10. 2019, 15:11:16
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.

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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 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á.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 07. 10. 2019, 15:59:57
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.

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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Ondra Satai Nekola 07. 10. 2019, 16:02:29
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.

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.

INNER JOIN hlavně naprosto jasně komunikuje čtenáři účel. Takže není co řešit.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 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).
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: e3k 08. 10. 2019, 20:26:37
nechapem ten flamewar ohladom INNER a LEFT OUTER JOIN.
proste INNER je len skupina objektov ktore su v oboch tabulkach.
zadanie bolo ze v TBL2 nie su spomenute vsetky.
pokial treba mat vo vysledku vsetky objekty tak jedine LEFT OUTER JOIN. + to pravidlo ze co v pripade ked nebolo definovane spravanie pomocou TBL2.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 08. 10. 2019, 21:27:49
nechapem ten flamewar ohladom INNER a LEFT OUTER JOIN.

On to není úplně flamewar.
Diskuse je o tom, že jedno řešení je přesně podle požadavku.
Druhé řešení je univerzálnější pro ten konkrétní požadavek a připravené i pro další předpokladatelné situace.

Já zastávám názor, že ten, kdo projektuje dotazy, měl by myslet v širším kontextu a předcházet tak budoucím problémům.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Ondra Satai Nekola 09. 10. 2019, 10:08:21
nechapem ten flamewar ohladom INNER a LEFT OUTER JOIN.

On to není úplně flamewar.
Diskuse je o tom, že jedno řešení je přesně podle požadavku.
Druhé řešení je univerzálnější pro ten konkrétní požadavek a připravené i pro další předpokladatelné situace.

Já zastávám názor, že ten, kdo projektuje dotazy, měl by myslet v širším kontextu a předcházet tak budoucím problémům.

Vždyť už jsi rovnou budoucí problém napsal.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 09. 10. 2019, 10:14:35
Vždyť už jsi rovnou budoucí problém napsal.

To je věc názoru. Zdejší diskuse ukázala, že mnoha lidem nedošlo, že neexistence záznamu v tbl2 může mít nějaký interpretovaný význam - např. pokud by se hledaly položky v tbl1 s opačným významem.

Abych to snad zakončil: 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. Také doporučuju tyto základní, nebo časté operace vytknout do view a dál už pracovat výhradně nad ním. Je mnohem výhodnější, když základní strukturu programátor čte z hotového pohledu, než aby ji na každém dotazu vymýšlel znovu. Výhodnější je to i pro refaktorování, nemusí se pak revidovat spousta míst v kódu.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 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í?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Vilith 09. 10. 2019, 22:25:54
Možná někomu pomůže:

https://zooom.cz/sql-dotazy-join-vysvetleni-a-graficke-znazorneni/

případně https://www.codeproject.com/Articles/33052/Visual-Representation-of-SQL-Joins nebo https://o5k4r.files.wordpress.com/2014/02/joins.jpg
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: e3k 11. 10. 2019, 21:22:39
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í?
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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 12. 10. 2019, 08:59:14
2. mas tabulku 2 kde su niektore ID s tabulky 1
preto LEFT JOIN... tam neni o com s inner joinom.

Jojo, je to tak.

To, co říká Filip, dělá spousta lidí - podmínku zaměňuje s joinovacím kritériem. Ony dost často fungují totožně, ale čitelnější (a správnější) je v joinu vyjadřovat typ spojení, a ve where vyjadřovat, co požaduji za data.

Nevím, jestli tento zlozvyk přišel s internetovými návody, nebo jestli je to třeba důsledek MySQL-školy, kde MySQL spoustu věcí neumí, nebo umí bídně, a tak programátoři hledají obezličky..
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 12. 10. 2019, 09:51:27
Ano, jedním z nich je například Miroslav Šilhavý, který se neustále spojovací kritérium snaží cpát do podmínek.

Spojovací kritérium je odvislé od struktury dat. Tu nám tazatel popsal. V tbl2 mohou a nemusí být záznamy odpovídající tbl1. To je spojovací kritérium. Toto spojovací kritérium 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), ale můžete podmínku i libovolně přeformulovat (zejm. najít záznamy, které nemají odpovídající záznam v tbl2 nebo mají 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 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 (https://forum.root.cz/index.php?topic=21909.msg317995#msg317995) – 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é.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 12. 10. 2019, 10:04:35
klidně můžete napsat jako CROSS JOIN a všechny podmínky dát do WHERE, aby to bylo dostatečně obecné.

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.

Stejně tak špatně by bylo dávat i druhou podmínku do joinu, byť by to fungovalo:
SELECT * FROM tbl1 JOIN tbl2 ON (tbl1.id_data=tbl2.id_data AND allowed > 0)

V tomto případě byste se mohl WHERE vyhnout úplně a je to ta samá chyba - přesouvání podmínky dotazu do kritérií spojení.

Prostě Váš návyk omezovat joiny podle podmínky dotazu je nezdravý, tak se SQL dělat nemá. Na projektu, kde se musí nad dotazem (nebo view) vystřídat víc lidí, nebo je použitý ve více situacích, nebo se může podmínka dotazu měnit, je potřeba dodržovat určitá pravidla.

Umím pochopit, že jste se třeba ještě nedostal do prostředí, kde by byly takové nároky, ale pak si aspoň nechte poradit a nešiřte bludy.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 12. 10. 2019, 10:15:59
Ano, a tady je struktura dat taková, že se zabýváme jenom záznamy existujícími v tbl2.

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.

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

Existence záznamu je tacitní podmínkou dotazu. Pokud musí existovat allowed > 0, implikuje to existenci záznamu v tbl2.

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í. 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 12. 10. 2019, 10:23:14
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.

Na dotaz tazatele by navrátilo identické záznamy:
SELECT * FROM tbl1 INNER JOIN tbl2 USING (id_data) WHERE allowed > 0
SELECT * FROM tbl1 LEFT OUTER JOIN tbl2 USING (id_data) WHERE allowed > 0
SELECT * FROM tbl1 INNER JOIN tbl2 ON (tbl1.id_data=tbl2.id_data AND allowed > 0)
SELECT * FROM tbl1 CROSS JOIN tbl2 WHERE tbl1.id_data=tbl2.id_data AND allowed > 0
SELECT * FROM tbl1, tbl2 WHERE tbl1.id_data=tbl2.id_data AND allowed > 0
SELECT * FROM tbl1 FULL OUTER JOIN tbl2 ON (tbl1.id_data=tbl2.id_data) WHERE allowed > 0
SELECT * FROM tbl1 FULL OUTER JOIN tbl2 ON (tbl1.id_data=tbl2.id_data AND allowed > 0)
SELECT * FROM tbl1 INNER JOIN tbl2 ON (true) WHERE tbl1.id_data=tbl2.id_data AND allowed > 0

Pouze ale jeden z těchto dotazů je sémanticky správně.

(Uvědomuji si, že MySQL nezná FULL OUTER JOIN, uvedl jsem jen pro pořádek a pro ty, co používají nějakou rozumnější databázi.)

Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 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ý.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 12. 10. 2019, 11:41:22
Opakuji ještě jednou – tady je struktura dat taková, že se zabýváme jenom záznamy existujícími v tbl2.

Asi to neumím napsat, abyste mě pochopil. Nemyslím strukturu dotazu, ale strukturu databáze. Ta byla popsána tak, že v tbl2 může a nemusí záznam existovat.

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.

Jsou situace, kdy máte obecně definováno, že záznam musí existovat. Např. na dokladu uvedený odběratel (tabulka odběratelů však slouží více účelům), nebo vazba na číselníky (opět využívané z více míst). Tam je INNER JOIN na místě.

----

Pokud tedy tazatel napsal, že v tbl2 nemusí záznam být - pak je tato skutečnost nějak významná (něco vyjadřuje). Pokud tento stav zakryjete INNER JOINEM, můžete zaplakat nad výdělkem. Bohatě stačí, aby chtěl Racchek vybrat záznamy které mají allowed=0 NEBO nemají odpovídající záznam, a už je v háji a bude přepisovat nejen podmínku, ale i JOINY.

SQL je velmi chytře navržené, ne nadarmo jsou HAVING, WHERE a ORDER BY až na konci - v nich se máte rejpat. Co je nad nimi má být co nejvíc zobecněné.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 12. 10. 2019, 12:21:36
Asi to neumím napsat, abyste mě pochopil. Nemyslím strukturu dotazu, ale strukturu databáze. Ta byla popsána tak, že v tbl2 může a nemusí záznam existovat.
Já to chápu, problém vidím spíš v tom, že píšete obecně o jakési struktuře databáze, ale nenapsal jste, co konkrétně to znamená. Jak mají vypadat tabulky, jaké na nich mají být FOREIGN KEYS nebo jiná omezení?

Navíc to pokládám za nesmyslné, SELECT popisuje výsledná data, ne strukturu databáze. Může dávat smysl nad jednou dvojicí tabulek dělat INNER JOIN i OUTER JOIN, protože to má pokaždé jiný význam – i když struktura tabulek bude pořád stejná.

Jsou situace, kdy máte obecně definováno, že záznam musí existovat. Např. na dokladu uvedený odběratel (tabulka odběratelů však slouží více účelům), nebo vazba na číselníky (opět využívané z více míst). Tam je INNER JOIN na místě.
Nezapomněl jste na to, že INNER JOIN je symetrický a nerozlišuje levou a pravou tabulku? Co kdyby tazatel přeformuloval svůj požadavek na: „Chci všechny záznamy z tbl2, které mají allowed > 0, a k nim připojit odpovídající záznam z tbl1. Pro každý záznam z tbl2 existuje záznam v tbl1.“ Struktura tabulek zůstává stejná. Výsledná sada záznamů zůstává stejná. Množiny správných SQL dotazů pro obě varianty formulace zadání jsou identické. Jenom podle vašich pravidel je najednou správně INNER JOIN. Přitom zároveň tvrdíte, že rozhodnutí, zda INNER nebo OUTER JOIN závisí na struktuře tabulek, ne na sémantice dotazu (myslím toho formulovaného přirozeným jazykem, ne SQL).

Pokud tedy tazatel napsal, že v tbl2 nemusí záznam být - pak je tato skutečnost nějak významná (něco vyjadřuje).
Pokud by ta skutečnost byla významná, napsal by explicitně, jak se má zacházet s neexistujícími záznamy v tbl2. Racchek to ale napsal jako chápavý student – sám to nepovažoval za důležité, ale uvědomil si, že se v oblasti neorientuje natolik dobře, aby to dokázal sám posoudit. Proto uvedl i tuhle informaci, o které si myslel, že je nadbytečná (proto ji neformuloval úplně přesně). Uvedl ji jen pro jistotu, kdyby to náhodou mělo vliv, aby s tím mohli znalejší lidé pracovat a upozornit ho, že na tom záleží.

Pokud tento stav zakryjete INNER JOINEM, můžete zaplakat nad výdělkem. Bohatě stačí, aby chtěl Racchek vybrat záznamy které mají allowed=0 NEBO nemají odpovídající záznam, a už je v háji a bude přepisovat nejen podmínku, ale i JOINY.
Ano, když se změní pravidla spojování, musí se přepsat JOINy. Když bude chtít tbl1 spojit s tabulkou tbl3, bude také muset přepsat JOIN. Výhoda je, že jsou pravidla pro spojování uvedena jinde, než podmínky, takže se to navzájem neplete.

SQL je velmi chytře navržené, ne nadarmo jsou HAVING, WHERE a ORDER BY až na konci - v nich se máte rejpat. Co je nad nimi má být co nejvíc zobecněné.
Ano, SQL je chytře navržené, proto odděluje spojovací podmínky od filtrovacích. Akorát vy se bůhvíproč snažíte spojovací podmínku nacpat do filtrovacích, i když to tazatel v původním dotazu velmi viditelně oddělil. Resp. Racchek dotaz formuloval tak, že ani nic jiného, než INNER JOIN nepředpokládal – dokonce ani první diskutující nenapadlo, že by to mohlo být i jinak. Teprve pak se někdo začal zabývat tím dovětkem, že v tbl2 záznamy nemusí existovat, a začal řešit, zda to je nebo není důležité. Racchek tenhle dovětek mezi podmínkami vůbec neuváděl, evidentně to tedy nevnímal jako podmínku, ale jako přirozený důsledek spojení.

Dotaz je zobecněný, pokud JOINovací podmínky máte u JOINu a ne ve WHERE. Když nacpete JOINovací podmínku do WHERE, musíte na to myslet při každé změně WHERE, pořád si musíte hlídat, abyste tu podmínku do WHERE připojil správně. Dotaz je zobecněný tehdy, pokud ve WHERE necháte opravdu jen filtrovací podmínky. Když jsem potřeboval spojit tbl1 se záznamy z tbl2, které mají kategorie=1 (právě takhle bylo formulované zadání – že se spojuje s podmnožinou druhé tabulky), dal jsem i tu podmínku na kategorie=1 do JOINu. Aby všechny spojovací podmínky byly u JOINu a já nemusel hlídat, že je správně přilepuju ke každému možnému WHERE. Dokonce možná z toho JOINu následně vznikl pohled, tím už si nejsem jistý.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: e3k 12. 10. 2019, 21:11:38
odpověděl (https://forum.root.cz/index.php?topic=21909.msg317995#msg317995)
Ospravedlnujem sa ale Filip a Miroslav tu narobili taky bordel ze sa to da tazko citat.
Kazdopadne pri druhom zadani prikladu by uz INNER JOIN uplne stacil.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 13. 10. 2019, 10:31:00
.
Kazdopadne pri druhom zadani prikladu by uz INNER JOIN uplne stacil.

On už by při prvním zadání stačil INNER JOIN, o tom není vůbec pochyb. Jen je to špatně navržené.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 13. 10. 2019, 10:58:53
Jen je to špatně navržené.
Na tomhle dotazu se evidentně neshodneme. Jak by tedy podle vás vypadal správně navržený SELECT pro tohle zadání?

Chci všechny záznamy z tbl2, které mají allowed > 0, a k nim připojit odpovídající záznam z tbl1. Pro každý záznam z tbl2 existuje záznam v tbl1.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 13. 10. 2019, 11:04:29
Na tomhle dotazu se evidentně neshodneme. Jak by tedy podle vás vypadal správně navržený SELECT pro tohle zadání?

Ale my se v zásadě shodujeme, obě řešení dávají tentýž výsledek.
Pře je pouze o tom, jestli je dobré přemýšlet trochu dopředu a tvořit s k takovému přemýšlení návyk.

Chci všechny záznamy z tbl2, které mají allowed > 0, a k nim připojit odpovídající záznam z tbl1. Pro každý záznam z tbl2 existuje záznam v tbl1.

Chápu kam míříte, ale zkoušíte to trochu demagogicky. Hlavní entitou dotazu je tbl1, z ní se čerpají informace. V tbl2 je pouze přívěsek, který existovat může a nemusí. Takže nemůžete z tbl2 najednou udělat hlavní entitu.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 13. 10. 2019, 12:07:57
Pře je pouze o tom, jestli je dobré přemýšlet trochu dopředu a tvořit s k takovému přemýšlení návyk.
Nikoli, tohle je pouze vaše demagogie. Na tom, že je potřeba přemýšlet trochu dopředu, se shodneme. Neshodneme se na tom, co máme ve předu očekávat.

Chápu kam míříte, ale zkoušíte to trochu demagogicky. Hlavní entitou dotazu je tbl1, z ní se čerpají informace. V tbl2 je pouze přívěsek, který existovat může a nemusí. Takže nemůžete z tbl2 najednou udělat hlavní entitu.
Že je tbl1 hlavní entitou dotazu se z uvedené databázové struktury pozná jak? Když budu mít tabulku entit a vedle ní číselník, v té tabulce entit záznamy mohou existovat a nemusí, zatímco číselník bude vždy úplný.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: e3k 13. 10. 2019, 20:04:20
.
Kazdopadne pri druhom zadani prikladu by uz INNER JOIN uplne stacil.

On už by při prvním zadání stačil INNER JOIN, o tom není vůbec pochyb. Jen je to špatně navržené.
tak to fakt neviem jak by som to spravil INNER JOINOM ked v 2hej tabulke nie su vsetky ID prvej. pokial sa to da tak to musi byt riadny brain fuck.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 13. 10. 2019, 20:06:26
tak to fakt neviem jak by som to spravil INNER JOINOM ked v 2hej tabulke nie su vsetky ID prvej. pokial sa to da tak to musi byt riadny brain fuck.

Požadavek byl na to vyhledat záznamy v tbl1, které mají v tbl2 odpovídající záznam a tbl2.allowed > 0.
Tedy INNER JOIN i OUTER JOIN navrátí v tomto případě stejný výsledek.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 14. 10. 2019, 07:45:42
Požadavek byl na to vyhledat záznamy v tbl1, které mají v tbl2 odpovídající záznam a tbl2.allowed > 0.
Požadavek byl jiný, přečtěte si to v prvním příspěvku.

Tedy INNER JOIN i OUTER JOIN navrátí v tomto případě stejný výsledek.
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é…
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 14. 10. 2019, 09:27:49
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.
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ší.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 14. 10. 2019, 10:09:28
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.

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
Případně to udělá nad tím view – ideálně, když k tabulce ani nebude mít přístup. To už pak tu vaši chybu s použitím chybného JOINu ani v SELECTu neopraví. I když ve výsledku by to asi bylo dobře – konečně by opravil ten váš JOIN v pohledu na správný INNER JOIN.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 14. 10. 2019, 16:37:48
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é.
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í.

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
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
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 14. 10. 2019, 17:03:03
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

Pokud dáte podmínku WHERE allowed > 0, pak Vám to tyto záznamy přirozeně nevrátí.
Ta podmínka je o dva komentáře výš, sám jste ji ve svém předchozím komentáři citoval. Mám pro vás tip – když píšete komentář, na stránce níž jsou předchozí komentáře v diskusi. Abyste ze sebe neudělal hlupáka, bývalo by stačilo odrolovat o jednu obrazovku dolů.

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.
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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: e3k 14. 10. 2019, 20:07:43
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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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í.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 14. 10. 2019, 20:57:14
:) 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.
Když jsem psal o tom CROSS JOINu všech tabulek, myslel jsem to ironicky. To nebyl návod, že se k tomu máte snažit přiblížit…

Já osobně dělám pohledy na data, která dávají nějaký smysl. Pokud dává smysl spojit tbl1 s existujícími řádky v tbl2, udělám si na to pohled. Pokud dává smysl ty tabulky spojit, ale ignorovat neexistenci záznamů v tbl2 a prostě místo nich doplnit NULL hodnoty, udělám si na to pohled. 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. Kdyby to vše nacpal do jednoho pohledu, budu muset navíc v aplikaci k tomu jednomu způsobu použití muset všude přidávat podmínku (proč? přesně k tomu přece mají sloužit pohledy).Nedej bože, abych u jednoho způsobu použití potřeboval něco změnit – jiné sloupečky, připojit další tabulku… Pak stejně budu muset projít celou aplikaci, najít všechna místa, kde se ten pohled používá, zjistit, že je to způsob použití 1 nebo 2 a pak to budu moci konečně slavnostně rozdělit na dva různé pohledy.

Obzvlášť zábavné to vaše řešení bude tehdy, když optimalizátor nezvládne nad tím vaším view udělat predicate push a vy donutíte databázi přečíst celou velkou tabulku, ze které by vám normálně INNER JOIN vybral pár záznamů podle indexu.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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í).
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 14. 10. 2019, 21:47:41
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. Zároveň můžu mít nadefinováno, že každý zaměstnanec má svého vedoucího, to je pořád stejná struktura dat, pohled „zaměstnanci se svým vedoucím“ bude velmi podobný. Stejná struktura tabulek, stejná data, JOIN stejné tabulky do sebe sama – ale dva různé významy, dva různé pohledy, a možná dva různé JOINy, podle toho, jak bude vyřešen ředitel firmy, zda i u něj bude dodrženo pravidlo, že každý má vedoucího.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 14. 10. 2019, 22:57:22
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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: e3k 15. 10. 2019, 20:15:12
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.
sakra Filip vyser sa uz na to. proste mozes dostat listu zamestnancov ktory uz nemaju nadriadenych a tam bude NULL. NULL neni nic zle da sa s tym dalej pracovat. ide o to co chces robit.

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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 15. 10. 2019, 21:16:48
sakra Filip vyser sa uz na to. proste mozes dostat listu zamestnancov ktory uz nemaju nadriadenych a tam bude NULL. NULL neni nic zle da sa s tym dalej pracovat. ide o to co chces robit.
Myslím, že o tom, jak psát správně SQL dotazy, by neměli poučovat lidé, kteří mají problém zapamatovat si zadání o třech větách. Napíšu, že vedoucí je definován tím, že má podřízené, načež Miroslav Šilhavý začne řešit, co když vedoucí nemá podřízené. Napíšu, že každý zaměstnanec má svého nadřízeného (což může platit i pro ředitele, který může být v databázi nadřízeným sám sobě – může to být vhodné, protože pak není potřeba řešit výjimky, kdo mu bude schvalovat dovolenou apod. ) – a e3k objeví, že je možné to řešit i tak, že ne každý má svého nadřízeného.

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í.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 15. 10. 2019, 23:08:53
Citace
Napíšu, že vedoucí je definován tím, že má podřízené...
Promiň, ale toto je typický antipattern. Právě proto, že může být vedoucí oddělení, kde nejsou zaměstnanci (ale např. platově je v třídě vedoucích atd....) - spojuješ do jednoho příznaku dva nesouvisející fakty.
 
Stejnej nesmysl je vynucovat že každý má svého nadřízeného: kde jaksi Tvůj rovnák na vohejbák (že ředitel bude nadřízen sám sobě) nebude dobře fungovat, protože např. dotaz na počty podřízených jednotlivých lidí bude dávat (bez patřičných ošetření komplikujících dotazy a navíc snadno opomenutelných) špatné výsledky, protože ostatní vedoucí sami sebe nepovedou.

Stará známá poučka návrhu databází praví: "zachycujte realitu". Jakmile si začneš v struktuře DB vymejšlet "geniální zjednodušení", dřív nebo pozdějc si o ně "nabiješ hubu".

Takže se moc nedivím, že ostatní Tvé "zlepšováky" pro návrh db ignorovali a radši přemýšleli nad rozumnou strukturou databáze, tedy takovou, kde vztah "být nadřízen" zachycuje opravdu nadřízenost a vedoucí je opravdu vedoucí, a nikoli vedoucí, co má alespoň jednoho podřízeného.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: e3k 16. 10. 2019, 19:53:36
Myslím, že o tom, jak psát správně SQL dotazy, by neměli poučovat lidé, kteří mají problém zapamatovat si zadání o třech větách.
ano je to tu zaspamovane a neda sa to uz citat.

Napíšu, že vedoucí je definován tím, že má podřízené, načež Miroslav Šilhavý začne řešit, co když vedoucí nemá podřízené. Napíšu, že každý zaměstnanec má svého nadřízeného (což může platit i pro ředitele, který může být v databázi nadřízeným sám sobě – může to být vhodné, protože pak není potřeba řešit výjimky, kdo mu bude schvalovat dovolenou apod. ) – a e3k objeví, že je možné to řešit i tak, že ne každý má svého nadřízeného.
ja som skor riesil Vasu fobiu z NULL hodnot spomenutu niekde vyssie.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 16. 10. 2019, 20:19:44
Právě proto, že může být vedoucí oddělení, kde nejsou zaměstnanci (ale např. platově je v třídě vedoucích atd....) - spojuješ do jednoho příznaku dva nesouvisející fakty.
Ty dva nesouvisející fakty (vedoucí a platová třída) jste spojil vy.
 
Stejnej nesmysl je vynucovat že každý má svého nadřízeného
Někdy je to naopak velice praktické. Můžete organizačně (ne databázově) s tou rolí nadřízeného spojit určitá oprávnění, např. schvalování dovolené. A pak nedojde k situaci, že si ředitel nemůže vzít dovolenou, protože mu ji nemá kdo schválit.

nebude dobře fungovat, protože např. dotaz na počty podřízených jednotlivých lidí bude dávat (bez patřičných ošetření komplikujících dotazy a navíc snadno opomenutelných) špatné výsledky, protože ostatní vedoucí sami sebe nepovedou
Větší banalitu už tam nemáte?

Stará známá poučka návrhu databází praví: "zachycujte realitu".
A proto mi tu ve svém komentáři vysvětlujte, že mám ignorovat realitu a databázi raději navrhnout jinak.

Mimochodem, ten můj model databáze zachycující realitu je problematický z jiného důvodu. Další poučka říká, že není vhodné databázi modelovat těsně podle pravidel daných realitou, pokud jsou ta pravidla daná rozhodnutím. Protože se to rozhodnutí může změnit.  Takže pokud mi někdo řekne, že u nich ve firmě je nadřízený definován tím, že má podřízené, budu zvažovat porušení pravidla „modeluj realitu“ právě proto, že ta definice nadřízeného je daná rozhodnutím a může se změnit.

Takže se moc nedivím, že ostatní Tvé "zlepšováky" pro návrh db ignorovali
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.

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.
Když píšete o sobě, pište raději v první osobě než v druhé. Navíc vy jste ignoroval i to, co do puntíku specifikováno bylo.

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"
Ano, tím je dána struktura dat. Struktura dat se popisuje pomocí DDL, zatímco JOIN je součástí SELECTu, tedy DML. Je hloupé pokoušet se JOINem určovat strukturu dat, protože tím strukturu nezměníte.

zatímco podmínka dotazu byla dána "allowed > 0"
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.

Naopak vy jste ze zadání naprosto nadbytečně dovodil, že OUTER JOIN se dá redukovat na INNER JOIN.
Nikoli, ten INNER JOIN je v zadání napsaný: „vybrat pouze to, co v tbl2 je …“. To naopak vy jste zcela nadbytečně odvodil, že zrovna v tomhle konkrétním případě se i OUTER JOIN bude chovat stejně jako požadovaný INNER JOIN.

ja som skor riesil Vasu fobiu z NULL hodnot spomenutu niekde vyssie.
Zkuste příště řešit reálné věci a ne vaše výmysly. Žádnou fóbii z NULL hodnot nemám, jenom jsem připomněl, že NULL je speciální hodnota, která má svůj význam, a není vhodné její význam měnit.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 17. 10. 2019, 12:02:16
Citace
Ty dva nesouvisející fakty (vedoucí a platová třída) jste spojil vy.
To jsem jaksi nespojil já, to jaksi spojili platové předpisy v mnoha firmách. Třeba jen tak, že vedoucí nesmí mít platovou třídu menší než..... Tvuj "zlepšovák" takovouto situaci prostě nebude umět zkontrolovat, protože nebude umět správně podchytit, kdo má funkci vedoucího.

Citace
A pak nedojde k situaci, že si ředitel nemůže vzít dovolenou, protože mu ji nemá kdo schválit.
Evidentně o firemní struktuře (velké firmy) toho moc nevíš. Ředitel, jakožto statutár, si vůbec dovolenou nebere, protože není zaměstnanec firmy, ale pracuje dle smlouvy o výkonu funkce (mandatorní smlouvy). Právě proto, protože zaměstnanec je někomu podřízen, zatímco ředitel ne - a tedy mnoho paragrafů ze zákoníku práce zde vůbec nedává smysl - např. ředitel dovolenou nemá. Právě proto, že je nesmysl, aby si ji sám schvaloval.

Další věc je, že je naprosto normální, že dovolené neschvaluje pouze nadřízený, ale i další pověření lidé (např. zástupci nadřízených, ale běžní jsou i další schvalovatelé, např. sekretářky vedoucích), takže Tvoje jednoduché pravidlo pro schvalování dovolené je nesmyslné, v IS je třeba mít možnost explicitně jmenovat lidi, kteří dovolenou schvalují. Takže ty řídké případy, kdy statutár má zároveň pracovněprávní vztah (to se děje v podstatě jen u malých s.r.o., kde jednatel zároveň pro s.r.o. pracuje - a takové zpravidla nemívají IS) jde bez problémů vyřešit tímto mechanismem a není třeba databázi plevelit nesmyslnou rekurzivní výjimkou, že je člověk nadřízený sám sobě (přičemž to platí jen pro jednoho konkrétního člověka).

Zatřetí pak IS, který by zakázal schválit dovolenou člověku bez nadřízeného by byl vadný. I taková situace totiž může ve firmě nastat: např. zaměstnanec vracející se z mateřské dovolené, kdy zatím bylo jeho oddělení bylo zrušeno, takže není zařazen ve firemní struktuře. Pro takové lidi musí existovat nějak stanovený schvalovatel (a toto právo by samozřejmě měl mít i řiditel) - který pak kupodivu může schvalovat i dovolenou řiditeli v pracovněprávním poměru.

Takže Tvůj nastolený problém je umělý a naprosto neodpovídá požadavkům praxe z mnoha důvodů....

Citace
Větší banalitu už tam nemáte?
Jistě, špatný počet zaměstnanců v sestavách je banalita, zatímco schvalování dovolené pro člověka, který si dovolenou nebere, to je nutnost....Pokud Ti přijde jako banalita to, že v jakémkoli algoritmu vypisující stromovou strukturu firmy budeš muset řešit výjimku, aby se Ti algoritmus nezacyklil, tak bych tebou navržené databáze fakt nechtěl používat.
Citace
že mám ignorovat realitu a databázi raději navrhnout jinak.
Realita je, že člověk je nadřízený sám sobě? Odkdy?
Realita je taková, že člověk, jmenovaný do funkce vedoucího, není vedoucím, i když zrovna třeba v jeho oddělení zrovna teď nejsou zaměstnanci?
Máš "zajímavý" "smysl pro realitu".
Citace
Já jsem žádné zlepšováky nenavrhoval
No, nečekal, jsem, že to budu muset vysvětlovat polopatě, ale holt....Tvými zlepšováky jsem nemyslel Tvůj způsob zápisu dotazu, ale Tvůj způsob, jakým jsi chtěl zachycovat zaměstnaneckou strukturu ve firmě. Která byla nesmyslná - viz výš - a tedy není divu, že ostatní ve své argumentaci Tebou navrženou strukturu DB ignorovali a argumentovali rozumnou strukturou DB - proti čemuž jsi se poněkud arogantně ohrazoval.





Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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).
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 18. 10. 2019, 07:16:46
To jsem jaksi nespojil já, to jaksi spojili platové předpisy v mnoha firmách.
Jak jsem psal, takový předpis se snadno může změnit.

Tvuj "zlepšovák" takovouto situaci prostě nebude umět zkontrolovat, protože nebude umět správně podchytit, kdo má funkci vedoucího.
Tak, jak jsem to popsal, nebude co kontrolovat, protože do databáze bude přepsána ta definice. Podchycení toho,kdo má funkci vedoucího, bude dané právě implementací té definice.

Tvými zlepšováky jsem nemyslel Tvůj způsob zápisu dotazu, ale Tvůj způsob, jakým jsi chtěl zachycovat zaměstnaneckou strukturu ve firmě. Která byla nesmyslná - viz výš - a tedy není divu, že ostatní ve své argumentaci Tebou navrženou strukturu DB ignorovali a argumentovali rozumnou strukturou DB - proti čemuž jsi se poněkud arogantně ohrazoval.
Pokud máte nějaké zadání, můžete ho rozporovat, že je podle vás špatně, ale nemůžete si ho potichoučku úplně předělat. Struktura DB, kterou jsem popsal, přesně odpovídala zadání, které jsem také jasně napsal. Ostatní mohou zadání klidně rozporovat, mohou navrhnout jiné – ale pokud zadání akceptují ale navrhnou strukturu databáze, která je s tím zadáním v rozporu, je chyba na jejich straně.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 18. 10. 2019, 07:19:49
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).
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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 18. 10. 2019, 18:21:37
Citace
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
Pokud máte nějaké zadání, můžete ho rozporovat, že je podle vás špatně, ale nemůžete si ho potichoučku úplně předělat.
Pleteš si zadání a strukturu databáze. V zadání je např. schopnost IS zachytit to, že je někdo vedoucí. Nikoli to, jak má DB tuto skutečnost zachycovat. A právě dobrého programátora od špatného odlišuje to, jak dobře je to zadání schopen zobrazit pomocí struktury databáze.

Dobrá implementace zadání se mj. vyznačuje tím, že je schopna do sebe s co nejmenšími změnami integrovat změny a rozšíření zadání. Protože změny zadání jsou každodenní realita - málokteré zadaní tak, jak ho dostaneš, je opravdu správně - a právě takové výjimky (jako např. vedoucí bez podřízených), které ale v reálné praxi nastávají poměrně často, se v zadání zpravidla zapomínají.

Proto pokud kvůli takovým trivialitám, jako např. přidání možnosti vyhodit z oddělení posledního člověka, aniž by se Ti ztratila informace o tom, že je někdo vedoucí, musíš modifikovat strukturu databáze, tak je Tvá implementace zadání prostě špatná.I kdybys dostal explicitně zadáno, že vedoucí je právě ten, kdo má podřízené, i tak je správné řešení funkci a počet podřízených od sebe oddělit, protože jednak to může být chyba v zadání, jednak je velmi pravděpodobné, že i když to je dnes opravdu tak, že to zítra bude jinak.

Ostatní tedy nepředefinovávají zadání, ale počítají s rozumnou implementací tohoto zadání.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 19. 10. 2019, 10:20:19
Houby si pletu. Vím s jistotou, že pokud můžete modelovat data
Sice to víte s jistotou, ale víte to blbě. Data modelujte pomocí struktury tabulek a omezení. A při vytváření struktury tabulek opravdu JOIN nepoužijete.

Váš INNER JOIN nepřináší nic navíc, pouze omezuje možnosti manipulace s daty.
INNER JOIN navíc přináší přehlednost a srozumitelnost, tím pádem snižuje riziko chyby. Vždyť i vy jste tady ten INNER JOIN pomocí OUTER JOINu psal špatně, než jsem vás na to upozornil – a to se tváříte, jaký jste expert.

Navíc to vaše kritérium, že má být dotaz co nejuniverzálnější, je nesmyslné – a vy sám to víte. Kdybyste tomu svému kritériu opravdu věřil, navrhnete mnohem univerzálnější dotaz, než nějaký OUTER JOIN dvou tabulek. Pořádně univerzální dotaz je CROSS JOIN všech tabulek, teprve ten nijak neomezuje možnost manipulace s daty.

Pleteš si zadání a strukturu databáze. V zadání je např. schopnost IS zachytit to, že je někdo vedoucí. Nikoli to, jak má DB tuto skutečnost zachycovat.
Já si to nepletu. Já jsem napsal, že jedno možné zadání je „vedoucí je definován tím, že má podřízené“. V rozumné definici databázové struktury pak tohle bude kontrolováno, aby nemohl vzniknout vedoucí bez podřízených. Dá se to udělat například tak, že vyjdete přímo z té definice a připravíte si nějaký pohled, který vybere všechny zaměstnance, kteří mají podřízené. Když se v budoucnosti zadání změní, změníte ten pohled. Další možnost je mít na to v databázi příznak a pomocí omezení nebo triggerů zajistit, aby byl vždy nastaven správně.

Dobrá implementace zadání se mj. vyznačuje tím, že je schopna do sebe s co nejmenšími změnami integrovat změny a rozšíření zadání.
Tohle je napsáno hodně obecně, takže to není pravda. Je potřeba umět provést ty změny, které jsou skutečně potřeba. Špatné implementace zadání se totiž mimo jiné vyznačují tím, že jsou přehnaně obecné, přičemž ta obecnost se nikdy nevyužije. A naopak ta obecnost velmi komplikuje skutečné požadované změny, které jsou v takových případech ještě jiného charakteru, než předpokládala ta obecnost. Takže vy si klidně můžete do databáze zavést příznak vedoucího, jenže pak se změní organizační struktura na maticovou, zaměstnanci budou mít organizačního vedoucího a projektového vedoucího, a stejně musíte strukturu měnit.

Ostatní tedy nepředefinovávají zadání, ale počítají s rozumnou implementací tohoto zadání.
Ne, předefinováváte zadání. Pokud zadání zní „vedoucí je ten, kdo má podřízené“, jakmile přijde o posledního podřízeného, podle definice přestává být vedoucím. To zadání vám může připadat divné, můžete ho rozporovat, můžete počítat s jeho změnou. Ale když napíšete „možnosti vyhodit z oddělení posledního člověka, aniž by se Ti ztratila informace o tom, že je někdo vedoucí“, je to v rozporu se zadáním, protože podle zadání dotyčný přestal být vedoucím, ale podle vás dále je vedoucím.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 19. 10. 2019, 13:01:06
Citace
Já jsem napsal, že jedno možné zadání je „vedoucí je definován tím, že má podřízené“.
Což je ovšem zadání s odpuštěním nereálné a tedy nesmyslné. Vedoucí pracovník je termín přímo definován zákonem, tento fakt musí být zachycen v pracovní smlouvě, a jsou zákonem dané možnosti, jak se člověk vedoucím stane a jak jím být přestane. Není možné, aby se z někoho stal "nevedoucí" jen tím, že mu odejde z oddělení poslední zaměstnanec.  I kdyby existovala firma, kde by to dle tvého nelegálního zadání fakt fungovalo, tak možnost, že dřív či později začnou zákon respektovat je natolik reálná, že je blbost na to aplikaci nepřipravit.
Tak se nediv, že si to ostatní Tvé zadání přeložili do reality.
Citace
Špatné implementace zadání se totiž mimo jiné vyznačují tím, že jsou přehnaně obecné, přičemž ta obecnost se nikdy nevyužije
Nu, a proto je třeba, aby ten, kdo navrhuje danou strukturu, o věci něco věděl, jinak není schopen rozlišit obecnost potřebnou od obecnosti "přebujelé".Pokud teda při svém návrhu db ignoruješ legislativu platnou pro daný obor, tak se nediv, že dojdeš k nesmyslným datovým strukturám.

Navíc - viz další odstavec - v normální velké firmě (pro malé se IS zpravidla nedělají) je třeba podchytit v IS daleko více informací (viz další odstavec), takže se do IS firmy hodí daleko flexibilnější datová struktura, než se kterou tady operuješ.
Citace
Když se v budoucnosti zadání změní, změníte ten pohled....... jenže pak se změní organizační struktura na maticovou,
A jsme doma. Vyvrátil sis sám vlastní přístup. Samostatný pohled na vedoucí je evidentně nedostatečný - nebo budeš mít jeden pohled na organizační vedoucí a jiný na projektové vedoucí a třetí na....?
Samozřejmě, že rozumný přístup je mít tabulku organizačních jednotek, a funkcí/rolí v organizačních jednotkách. Nejen vedoucích, ale např. schvalovatelů dovolených, sekretářek, a hromady dalších funkcí/rolí, které je třeba zachytit (např. sekretářkám se posílají pokyny o objednávání kancelářských potřeb atpod.). Tak snadno podchytíš jak stromovou strukturu, tak maticovou, nebo i další pitomosti, co si zrovna ředitel ve firmě vymyslí, aniž bys musel překopávat strukturu databáze. Jen max budeš doplňovat číselníky funkcí.
Tvůj přístup, že do struktury db zakóduješ (navíc ilegální) pravidlo, jak určit vedoucího - a pro další role pak budeš vymýšlet jiné další navzájem nekompatibilní adhoc mechanismy, jak je zachytit a vyhledat, to je cesta do pekel... Samozřejmě, na první pohled je Tebou navržené zachycení fce vedoucího jednoduché. Ale v reálu si o takovej návrh db nabiješ čumec.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 19. 10. 2019, 13:42:13
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á.

Já jsem nepsal o žádném podnikovém IS, psal jsem o jedné jediné tabulce, která sloužila jenom jako příklad. Nepsal jsem nic o tom, že to má být hotové komplexní řešení. Pouze jsem na tom ilustroval to, že ze struktury tabulek neplyne jediný možný pohled na data, tudíž je nesmyslné odvozovat použití INNER nebo OUTER JOINu z toho, jak vypadá struktura tabulek.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 19. 10. 2019, 14:26:53
Citace
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.
Opakuješ vyvrácené. Nikdo si nevymýšlel vlastní zadání. Jen se navrhla struktura DB tak, aby až se zjistí, že nereálné je, tak se to nemuselo předělávat. Dobrý programátor takovéto věci předvídá.

Citace
...použít jiný termín, třeba „nadřízený....
Ale pak se  na ostatní nezlob, že když použiješ termín a myslíš tím něco jiného, než ten termín znamená, že Ti ostatní nerozumí. To není chyba na přijímači, ale na vysílači.

Citace
nebo vytipovali podřízené na školení, nedává smysl informovat o tom někoho, kdo žádné podřízené nemá.
Jo, takže když někdo nemá ten den podřízené, třeba protože zrovna probíhá organizační změna, tak se nedozví, jaké povinnosti má vůči svým podřízeným, které dostane zítra přiřazené. Právě si prakticky demonstroval, jak je Tvůj příklad defunkční a jak je nutné ty dva fakty (být vedoucí a mít podřízené) oddělit.
Btw. uvědomit si a upozornit na takovéto problémy patří do práce programátora, představa, že Ti někdo dá 100% správné zadání, které jen stačí do písmene přesně implementovat, je mimo.

Citace
Já jsem nepsal o žádném podnikovém IS, psal jsem o jedné jediné tabulce, která sloužila jenom jako příklad.
A tak se pozná dobrý programátor od špatného, jestli řeší věci izolovaně a pak je musí předělávat, nebo od začátku přemýšlí nad problémem v kontextu :-) :-)

Citace
že ze struktury tabulek neplyne jediný možný pohled na data...
Ovšem argumentovat tím, že z blbé struktury tabulek něco plyne, je argumentace špatná. Protože právě blbá struktura databáze je tím, co nabádá ke špatným řešením.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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").
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 19. 10. 2019, 19:40:12
Nikdo si nevymýšlel vlastní zadání.

Např. pokud je vedoucí zaměstnanec definován tím, že má podřízené

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

Tak buď Miroslav Šilhavý umí vytvořit zaměstnance, kteří zároveň mají i nemají podřízené, nebo si změnil zadání.

Q.E.D.

Podle toho, čemu říkáte "zadání".
Tady v diskusi říkám zadání tomu, co jsem jako zadání napsal.

To, co jste popsal, je přístup programátorské lopaty (dnes se tomu eufemisticky říká "junior").
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ě?

Junior obvykle aspoň ví, že neví. Horší je, když si někdo o sobě myslí, že je expert, ale ve skutečnosti taky neví.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 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.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 19. 10. 2019, 23:52:37
Citace
Nikdo si nevymýšlel vlastní zadání.
Promiň, už mi mělo dojít, že máš problém porozumět, když člověk se vyjadřuje ve zkratce, a nikoli přísně formálně logicky. Tato věta znamenala:

Nikdo NEMĚNIL tvé zadání, akorát si lidi povšimli chyby toho zadání (která ho činí v praxi nepoužitelným) a tak automaticky přizpůsobili návrh databáze tomu, aby když/až se ta chyba návrhu opraví, nebylo třeba přepisovat půl aplikace.

Už tomu rozumíš, nebo to potřebuješ ještě polopatičtěji? Teda promiň, možná nerozumíš tomu "přepisovat půl aplikace" - tím se myslí, že by s tím bylo zbytečně příliš mnoho práce, samozřejmě se tím nemyslí, že by se musela přepsat každá druhá řádka každého zdrojáku.
Ještě něco potřebuješ vysvětlit?


Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 20. 10. 2019, 18:17:39
V jednom příkladu jsem nedospecifikoval některé stavy, ale účelem bylo upozornit na styl přemýšlení, nikoliv do diskuse napsat definitivní select.
Nikoli. Opakovaně jste se tu pokoušel INNER SELECT přepsat pomocí OUTER SELECTu se spojovací podmínkou přidanou do WHERE, a opakovaně jste tu podmínku do WHERE napsal špatně. Pořád tu píšete o tom, jak je potřeba u začínajících programátorů budovat správné návyky – použít ve WHERE jiný sloupec, než tam má být, s tím, že to v některých specifických případech náhodou bude fungovat, mezi dobré návyky rozhodně nepatří.

V tomto vidíte nějakou chybu?
To, že jste napsal jeden SELECT tak, že by fungoval, neznamená, že jste nemohl udělat chybu v jiném.

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.
Aha, tak použití chybného sloupce v podmínce je překlep a zjednodušení.

Nic mi neuniká. Dávno už jsem vysvětlil, že je ten váš přístup nevýhodný, protože komplikuje a znepřehledňuje kód (o čem svědčí i ten váš „překlep“). Vám uniká, že kód musí být především správný a čitelný, a je nesmysl ho komplikovat s vidinou jakési chimérické univerzálnosti.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 20. 10. 2019, 18:18:59
Nikdo NEMĚNIL tvé zadání
Aha, takže „případ, kdy vedoucí nemá žádné podřízené“ je zcela v souladu se zadáním „vedoucí je definován tím, že má podřízené“. Omlouvám se, této vaší logice opravdu nerozumím – a ani rozumět nechci.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 20. 10. 2019, 19:01:06
Citace
se zadáním „vedoucí je definován tím, že má podřízené
Který z těchto bodů nechápeš?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 20. 10. 2019, 19:23:45
Zadání je funkční. Pokud se vám na něm něco nezdá, můžete zadání rozporovat. Pokud proti zadání nemáte žádné námitky, ale navrhnete řešení, které je v rozporu se zadáním, je to vaše chyba. Co na tom nechápete?

Pořád jenom kličkujete. Zadání bylo „vedoucí zaměstnanec je definován tím, že má podřízené“. Na to Miroslav Šilhavý odpověděl: „můžu chtít zobrazit všechny vedoucí, […] co (už) žádné podřízené nemají“. To tvrzení buď je v souladu se zadáním, nebo je s ním v rozporu. Žádná třetí možnost neexistuje. Vy, místo abyste napsal, zda je v souladu nebo v rozporu, pořád jen vymýšlíte další a další výmluvy. Jak chcete hodnotit funkčnost či nefunkčnost zadání, když nedokážete odpovědět ani na takhle jednoduchou otázku?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 20. 10. 2019, 20:29:24
Aha, takže „případ, kdy vedoucí nemá žádné podřízené“ je zcela v souladu se zadáním „vedoucí je definován tím, že má podřízené“. Omlouvám se, této vaší logice opravdu nerozumím – a ani rozumět nechci.

Tak pak se možná zdržujte radit nováčkům. Ti třeba budou ochotní rozumět.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 20. 10. 2019, 21:02:24
Tak pak se možná zdržujte radit nováčkům. Ti třeba budou ochotní rozumět.
Je možné, že někteří nováčci budou rozumět tomu, že mohou zadání ignorovat a bez varování psát podle jiného zadání, které si sami vytvořili a s nikým ho nekonzultovali. Ovšem pak je potřeba je před takovým počínáním důrazně varovat.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 20. 10. 2019, 21:12:37
Je možné, že někteří nováčci budou rozumět tomu, že mohou zadání ignorovat a bez varování psát podle jiného zadání, které si sami vytvořili a s nikým ho nekonzultovali. Ovšem pak je potřeba je před takovým počínáním důrazně varovat.

Vyvozujete něco, co tu nezaznělo a podsouváte to.

Programátor by měl mít nastartované kritické myšlení a měl by tyto situace domyslet. Zadavateli by je měl samozřejmě předložit, pokud vybočí ze zadání. Neznám však zadavatele, který by dal tak rigidní pokyn, jako že "vedoucí je pouze ten, který má podřízené". Většinou je zadání obecnou větou: "vedoucí se pozná tak, že má podřízené", což si musíte v obecné mluvě přeložit. Zadavatel je neprogramátor, věta pak znamená "vedoucí (se obvykle) pozná podle toho, že má podřízené".

Na programátorovi (analytikovi) je umět tyto nuance rozlišit. V obou případech, které jsme zde probírali, nevybočuje programátor ze zadání, pouze domyslel existenci hraničních stavů. Následně může přidat filtr, který to omezí na úroveň striktního požadavku - a ve chvíli, kdy se ukáže, že to zadavatel nedomyslel, nemusí celou databázi překopávat a revidovat kód, aby každý dotaz od píky přeformulovál.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 20. 10. 2019, 22:14:06
Vyvozujete něco, co tu nezaznělo a podsouváte to.

Programátor by měl mít nastartované kritické myšlení a měl by tyto situace domyslet. Zadavateli by je měl samozřejmě předložit, pokud vybočí ze zadání. Neznám však zadavatele, který by dal tak rigidní pokyn, jako že "vedoucí je pouze ten, který má podřízené". Většinou je zadání obecnou větou: "vedoucí se pozná tak, že má podřízené", což si musíte v obecné mluvě přeložit. Zadavatel je neprogramátor, věta pak znamená "vedoucí (se obvykle) pozná podle toho, že má podřízené".

Na programátorovi (analytikovi) je umět tyto nuance rozlišit. V obou případech, které jsme zde probírali, nevybočuje programátor ze zadání, pouze domyslel existenci hraničních stavů. Následně může přidat filtr, který to omezí na úroveň striktního požadavku - a ve chvíli, kdy se ukáže, že to zadavatel nedomyslel, nemusí celou databázi překopávat a revidovat kód, aby každý dotaz od píky přeformulovál.
Nic vám nepodsouvám. Vy se pořád jen vymlouváte. Že by to takhle normálně zadavatel nezadal? Zaprvé je to jen vaše domněnka, za druhé tady to takhle napsané bylo, tak jste na to měl odpovídajícím způsobem reagovat. Pokud byste zapnul kritické myšlení, musel byste dospět k tomu, že vaše odpověď je v rozporu se zadáním a vy to nijak neřešíte.

Navíc popisujete domýšlivé chování analytika, před kterým je potřeba každého začátečníka varovat. Pokud si analytik není něčím jistý, má se na to zadavatele doptat. Pokud někdo řekne „vedoucí se pozná tak, že má podřízené“, možná také očekává, že to aplikace bude kontrolovat a nedovolí z někoho udělat vedoucího (nebo třeba „šéfa“, ať si to Logik zase neplete s vedoucím zaměstnancem). Ale vy jste mu právě tuhle kontrolu z aplikace odstranil, protože si myslíte, že všechno víte nejlíp a zadání si proto klidně můžete přeformulovat, jak vás napadne.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 20. 10. 2019, 22:32:06
Pokud někdo řekne „vedoucí se pozná tak, že má podřízené“, možná také očekává, že to aplikace bude kontrolovat a nedovolí z někoho udělat vedoucího (nebo třeba „šéfa“, ať si to Logik zase neplete s vedoucím zaměstnancem). Ale vy jste mu právě tuhle kontrolu z aplikace odstranil, protože si myslíte, že všechno víte nejlíp a zadání si proto klidně můžete přeformulovat, jak vás napadne.

Čímž jste se dopustil katastrofální chyby. Vazba bude buďto přímo zaměstnanec => nadřízený, nebo v případě příslušnosti zaměstnance ve více týmech (stává se!) by byla přes dynamickou vazbu zaměstnanec <= vazba => nadřízený. V obou případech vede FK směrem k nadřízenému, tedy na straně entity nadřízeného nemáte jaké pravidlo kontrolovat (maximálně CHECK, který se ovšem nevyvolá při ztrátě vazby - takže je k ničemu), natož aby bylo deferovatelné v době vzniku té vazby. Dál byste musel vyžadovat, aby entita zaměstnance existovala dřív, než entita nadřízeného - což je další úvaha zcela mimo praxi. Sakra, kdo to tu o pár postů výše hlásal, že databáze má zachycovat realitu, nikoliv stav vytvořený rozhodnutím? A jo, Vy. Tím se netrapte, já taky plácám blbosti.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 20. 10. 2019, 23:53:04
Vedoucí vede oddělení, podřízené mít nemusí.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 21. 10. 2019, 07:43:15
Čímž jste se dopustil katastrofální chyby. Vazba bude buďto přímo zaměstnanec => nadřízený, nebo v případě příslušnosti zaměstnance ve více týmech (stává se!) by byla přes dynamickou vazbu zaměstnanec <= vazba => nadřízený. V obou případech vede FK směrem k nadřízenému, tedy na straně entity nadřízeného nemáte jaké pravidlo kontrolovat (maximálně CHECK, který se ovšem nevyvolá při ztrátě vazby - takže je k ničemu), natož aby bylo deferovatelné v době vzniku té vazby. Dál byste musel vyžadovat, aby entita zaměstnance existovala dřív, než entita nadřízeného - což je další úvaha zcela mimo praxi. Sakra, kdo to tu o pár postů výše hlásal, že databáze má zachycovat realitu, nikoliv stav vytvořený rozhodnutím? A jo, Vy. Tím se netrapte, já taky plácám blbosti.
Ano, dopustil jsem se katastrofální chyby, když jsem předpokládal, že vývoji software alespoň trochu rozumíte.

Aplikace musí kontrolovat spoustu dalších věcí, ne jen ty, které lze v databázi vyjádřit jako cizí klíče. A zrovna vazbu „má podřízené“, pokud ji chcete kontrolovat vůči příznaku „je nadřízený“, můžete kontrolovat i v databázi, například pomocí triggeru. V mém příkladu ale nebyla taková kontrola potřeba, protože já jsem nenavrhoval žádný příznak „má nadřízené“ uložený v databázi – já jsem vycházel přímo z definice, že nadřízený je ten, kdo má podřízené, takže ten příznak byl vypočítáván v okamžiku, kdy byl potřeba.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 21. 10. 2019, 09:36:16
Aplikace musí kontrolovat spoustu dalších věcí, ne jen ty, které lze v databázi vyjádřit jako cizí klíče. A zrovna vazbu „má podřízené“, pokud ji chcete kontrolovat vůči příznaku „je nadřízený“, můžete kontrolovat i v databázi, například pomocí triggeru. V mém příkladu ale nebyla taková kontrola potřeba, protože já jsem nenavrhoval žádný příznak „má nadřízené“ uložený v databázi – já jsem vycházel přímo z definice, že nadřízený je ten, kdo má podřízené, takže ten příznak byl vypočítáván v okamžiku, kdy byl potřeba.

Pokud je to kontrola v aplikaci, pak to není možno v pravém smyslu považovat za integritní omezení dat.

Triggerem to hlídat můžete pouze za předpokladu, že budete mít nadřízeného v databázi označeného takovým příznakem. Jinak by trigger nemohl vyhodnotit, který nadřízený musí mít podřízené. V tu chvíli jste na půdě návrhu, o kterém hovořil Logik - tedy musíte mít v datech nadřízeného označeného, nikoliv to vyvozovat z existence vazby.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 21. 10. 2019, 12:34:51
To je jak besídka zvláštní školy…

Pokud je to kontrola v aplikaci, pak to není možno v pravém smyslu považovat za integritní omezení dat.
Za prvé to stejně tak je možné považovat za v pravém smyslu integritní omezení dat – můžete např. data zpřístupnit jen přes nějaké API, jehož implementace teprve bude komunikovat s databází, nikdo jiný přímo do databáze nepoleze. Za druhé, o integritním omezení dat píšete vy, já jsem psal o zadání. To je pořád ten váš velmi zúžený pohled, kdy se díváte jen na databázi a nevidíte nic okolo.

Triggerem to hlídat můžete pouze za předpokladu, že budete mít nadřízeného v databázi označeného takovým příznakem.
Ano, právě na ten případ, kdy máte nějaký příznak v databázi, jsem reagoval.

Jinak by trigger nemohl vyhodnotit, který nadřízený musí mít podřízené. V tu chvíli jste na půdě návrhu, o kterém hovořil Logik - tedy musíte mít v datech nadřízeného označeného, nikoliv to vyvozovat z existence vazby.
Když to odvozujete online z existence vazby, jak byl můj původní návrh, nemáte zase co kontrolovat, protože ta vazba prostě ten stav „vedoucí“ rovnou definuje.

Vaše komentáře už jsou jenom trapné, snažíte se hledat chyby za každou cenu, ale už je nacházíte akorát u sebe. Já napíšu „původně jsem psal o variantě A, ale vaše varianta B by se řešila takhle“, a vy na to odpovíte, že ale to řeší variantu B a varianta A by se musela řešit jinak.

Jestli na to budete reagovat zase nějakým dalším ještě bláznivějším komentářem, s mojí odpovědí už nepočítejte.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 21. 10. 2019, 13:38:33
Jestli na to budete reagovat zase nějakým dalším ještě bláznivějším komentářem, s mojí odpovědí už nepočítejte.

Já myslím, že to v klidu můžeme zakončit. Řekli jsme si o 99 % víc, než bylo potřeba.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 21. 10. 2019, 14:28:36
Pokud je to kontrola v aplikaci, pak to není možno v pravém smyslu považovat za integritní omezení dat.
Za prvé to stejně tak je možné považovat za v pravém smyslu integritní omezení dat – můžete např. data zpřístupnit jen přes nějaké API, jehož implementace teprve bude komunikovat s databází, nikdo jiný přímo do databáze nepoleze.

Nejlepším databázovým API je SQL.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 21. 10. 2019, 14:30:30
Nejlepším databázovým API je SQL.

Amen.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 21. 10. 2019, 14:47:12
Nejlepším databázovým API je SQL.
Ovšem když chcete někoho pustit ke své službě, neznamená to, že nejlepší je zpřístupnit mu databázi.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 21. 10. 2019, 14:52:09
Ovšem když chcete někoho pustit ke své službě, neznamená to, že nejlepší je zpřístupnit mu databázi.

Ano, na to uděláte nějaký middleware, ale funkce by měla obstarávat databáze.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 21. 10. 2019, 16:08:55
Nejlepším databázovým API je SQL.
Ovšem když chcete někoho pustit ke své službě, neznamená to, že nejlepší je zpřístupnit mu databázi.

Když správce databáze umí používat GRANT, vložené procedury a triggery, tak se nemusí bát k ní někoho pustit.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 21. 10. 2019, 16:15:37
Když správce databáze umí používat GRANT, vložené procedury a triggery, tak se nemusí bát k ní někoho pustit.

Na MySQL bude problém s oprávněním k datům uvnitř aplikace, tam asi nebude možné nic vymyslet kromě middlewaru, který provede ověření oprávnění k datům a filtrování řádků, které se nesmějí ven dostat.

Na PostgreSQL by to šlo poměrně bez problémů pomocí row-level-security a pomocí views s WITH secuirty_barrier.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 21. 10. 2019, 16:40:09
Když správce databáze umí používat GRANT, vložené procedury a triggery, tak se nemusí bát k ní někoho pustit.
Na MySQL bude problém s oprávněním k datům uvnitř aplikace, tam asi nebude možné nic vymyslet kromě middlewaru, který provede ověření oprávnění k datům a filtrování řádků, které se nesmějí ven dostat.

Na PostgreSQL by to šlo poměrně bez problémů pomocí row-level-security a pomocí views s WITH secuirty_barrier.

Jde to i v MySQL. Stačí udělit přístupy jen k pohledům a vloženým procedurám. Odpadnou tím potíže se špinavými kešemi a zbytečně dlouhým zamykáním transakcí.

Celý middleware může být přímo v databázi. Spousta běžných potíží tím sama odpadne.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 21. 10. 2019, 16:42:17
Jde to i v MySQL. Stačí udělit přístupy jen k pohledům a vloženým procedurám. Odpadnou tím potíže se špinavými kešemi a zbytečně dlouhým zamykáním transakcí.

Aha, já si nebyl jistý, jestli MySQL umí dostatečně bezpečně vystavit VIEW. Pak je to jasné, přístup DB je určitě dobrý způsob.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 21. 10. 2019, 17:20:06
Když správce databáze umí používat GRANT, vložené procedury a triggery, tak se nemusí bát k ní někoho pustit.
Jistě, ale tady jsme se bavili o případu, kdy jeden diskutující triggery používat neumí. Navíc aplikační logiku je možné psát v databázi, ale má to své meze použitelnosti a složitější logiku je lepší psát jinde, než v databázi. To, že někdo umí jenom SELECT * FROM tabulka a vše ostatní – řazení, filtrování, spojování – řeší (typicky) v PHP, je jeden extrém. Ale komplikovaná logika nacpaná v triggerech a uložených procedurách je druhý extrém.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 21. 10. 2019, 17:28:01
Navíc aplikační logiku je možné psát v databázi, ale má to své meze použitelnosti a složitější logiku je lepší psát jinde, než v databázi. To, že někdo umí jenom SELECT * FROM tabulka a vše ostatní – řazení, filtrování, spojování – řeší (typicky) v PHP, je jeden extrém.

Podle toho, čemu říkáte "aplikační logika". Typicky přístup a pohledy na data jsou databázová záležitost, stejně jako zajištění konzistence dat. Zejména v případech, kdy do databáze přistupuje víc aplikací (přes API - včetně přímého vstupu do databáze). Pak se Vám sakra moc nehodí mít logiku v aplikaci (PHP), protože tu samou logiku pak musíte znovu a znovu zavádět do každého dalšího API, které nad data postavíte. To se dřív nebo později stane neudržitelné.

Typicky se nad určitou oblastí staví velké view, které podchycuje vazby. Nad toto view se pak staví další konkrétní pohledy - které mohou přidávat filtrování, ošetření bezpečnosti atd. atd.

Ale komplikovaná logika nacpaná v triggerech a uložených procedurách je druhý extrém.

Naopak komplikovaná logika patří právě sem. Databázi obvykle řeší mnohem kvalifikovanější pracovník, než ten, který staví aplikaci. Tomu se dávají k dispozici jen data, která potřebuje. Triggery pak zajišťují ověření, nebo např. tvoření historie záznamu atd. Pokud to někdo dělá v aplikaci (PHP), je to nešťastné.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 21. 10. 2019, 20:40:24
Když správce databáze umí používat GRANT, vložené procedury a triggery, tak se nemusí bát k ní někoho pustit.
Jistě, ale tady jsme se bavili o případu, kdy jeden diskutující triggery používat neumí. Navíc aplikační logiku je možné psát v databázi, ale má to své meze použitelnosti a složitější logiku je lepší psát jinde, než v databázi. To, že někdo umí jenom SELECT * FROM tabulka a vše ostatní – řazení, filtrování, spojování – řeší (typicky) v PHP, je jeden extrém. Ale komplikovaná logika nacpaná v triggerech a uložených procedurách je druhý extrém.

Nemusíme jít ani do jednoho extrému. Často úplně stačí, když si databáze udrží konzistenci, referenční integritu. Generování výstupního XML/HTML je sice v databázi možné, ale je to hloupé. Opačně jsem viděl ve výstupní šabloně volat SQL dotazy, což je zpravidla také špatně.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 21. 10. 2019, 20:46:38
Ale komplikovaná logika nacpaná v triggerech a uložených procedurách je druhý extrém.
Naopak komplikovaná logika patří právě sem. Databázi obvykle řeší mnohem kvalifikovanější pracovník, než ten, který staví aplikaci. Tomu se dávají k dispozici jen data, která potřebuje. Triggery pak zajišťují ověření, nebo např. tvoření historie záznamu atd. Pokud to někdo dělá v aplikaci (PHP), je to nešťastné.

Bohužel mnoho firem nemá prostředky na kvalifikovaného DB specialistu a nechávají to na polovzdělaných PHP programátorech, kteří jen umí spoléhat na ORM frameworky, ale o databázovém modelování nemají ani ponětí.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 21. 10. 2019, 22:08:12
Nemusíme jít ani do jednoho extrému. Často úplně stačí, když si databáze udrží konzistenci, referenční integritu. Generování výstupního XML/HTML je sice v databázi možné, ale je to hloupé. Opačně jsem viděl ve výstupní šabloně volat SQL dotazy, což je zpravidla také špatně.
Je tu jeden diskutující, který si nevhodným návrhem databáze zkomplikoval situaci (místo konzistence dané definicí potřeboval nějak udržovat konzistenci), aby následně prohlásil, že pomocí cizích klíčů a check constraints tu konzistenci zaručit neumí. Proto jsem psal, že je možné tu kontrolu dělat i v aplikaci. V tomto případě to sice není vhodné, ale jsou jiné případy, kdy jsou kontroly tak komplexní, že nemá smysl je provádět v databázi.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Vilith 21. 10. 2019, 22:14:06
Už toho nech  - to se nedá číst.

Co může kontrolovat DB, má kontrolovat DB - jedině tak zajistíš konzistentní a správná data.

Každá kontrola dat v aplikaci je jen zdrojem možných problémů (stavíte novou aplikaci, další API, jiný programátor)

Pokud tedy neděláš aplikaci podobnou evidenci knížek v domácí knihovně...


Nemusíme jít ani do jednoho extrému. Často úplně stačí, když si databáze udrží konzistenci, referenční integritu. Generování výstupního XML/HTML je sice v databázi možné, ale je to hloupé. Opačně jsem viděl ve výstupní šabloně volat SQL dotazy, což je zpravidla také špatně.
Je tu jeden diskutující, který si nevhodným návrhem databáze zkomplikoval situaci (místo konzistence dané definicí potřeboval nějak udržovat konzistenci), aby následně prohlásil, že pomocí cizích klíčů a check constraints tu konzistenci zaručit neumí. Proto jsem psal, že je možné tu kontrolu dělat i v aplikaci. V tomto případě to sice není vhodné, ale jsou jiné případy, kdy jsou kontroly tak komplexní, že nemá smysl je provádět v databázi.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 22. 10. 2019, 10:19:56
Citace
Zadání je funkční.
Na konkrétních příkladech - dokonce i Tvých - jsem ukázal, že takové zadání v praxi nebude fungovat dobře. Tyto příklady jsi nijak nevyvrátil. Budeme diskutovat způsobem, že kdo víckrát zařve svoji pravdu, tak vyhrál? Nebo budeme argumentovat?

Citace
Pokud se vám na něm něco nezdá, můžete zadání
rozporovat.
Jestli jsi to nepochopil, tak právě v těch případech bylo to rozporování implicitně obsaženo: upozorňovali jsme Tě na případ, který Tvé zadání neumí pochytit, ač je potřeba. Jen jsme prostě z Tebe nechtěli hned dělat blba a mysleli jsme, že tu chybu svého zadání pochopíš sám a nebudem Ti ji muset otlouct o hlavu - to je jaksi součást normálního vstřícného postoje v diskusi.

A co jsi se vyjádřil, že tu koninu myslíš vážně, že to nebylo jen nepřesné vyjádření, jak jsme předpokládali, ale že chybu toho zadání nevidíš, tak jsme Ti ji rozporovat začali i explicitně. Tak kde máš problém? Že jsme Ti nedali formální změnový požadavek vyhotovený na formuláři XB-457 ve třech kopiích a opatřených kolkem? Jsme v diskusi, ne v korporátu.

Citace
ale navrhnete
řešení, které je v rozporu se zadáním, je to vaše chyba.
Pokolikáté budu muset zopakovat, že ŘEŠENÍ NEBYLO V ROZPORU S TVÝM ZADÁNÍM, do navržené datové struktury šlo uložit i data požadovaná dle tvého chybného zadání. Ovšem naše řešení UMOŽŇOVALO snadnou opravu toho zadání. A zároveň Tě jemně upozorňovalo na chybu zadání.
Uvědom si, k ČEMU MĚL TEN TVŮJ PŘÍKLAD SLOUŽIT: K DEMONSTRACI BEST PRACTICIES při návrhu databáze. Tedy jsou dvě možnosti. Buďto na svém zadání trváš, pak ale je to totální OT, protože demonstrovat best practicies na chybném zadání je nonsens. Anebo chceš diskutovat k tématu - pak by mělo být automatické, že se zadání opraví tak, aby vyhovovalo běžné situaci v praxi.
A i když budeš na tom chybném návrhu trvat - i to se občas u klienta nebo třeba šéfa v práci stane - i tak by v praxi bylo Tvé řešení chybné, protože dřív či pozdějc by se na omezení toho návrhu narazilo tak jako tak. To je jedna z dalších věcí, která dělá dobrého programátora: když už šéf/klient neuhne a chce blbost, tak SW navrhnout aspoň tak, aby ta blbost vadila co nejméně. A ne to naimplementovat pitomně a umejt si ruce, že to bylo v zadání.....




Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 22. 10. 2019, 10:53:47
Na konkrétních příkladech - dokonce i Tvých - jsem ukázal, že takové zadání v praxi nebude fungovat dobře. Tyto příklady jsi nijak nevyvrátil. Budeme diskutovat způsobem, že kdo víckrát zařve svoji pravdu, tak vyhrál? Nebo budeme argumentovat?
Ukázal jste, že jsou možná i jiná řešení. Že nebude fungovat můj příklad jste neukázal. Pokud je např. jediná funkce vedoucího, že schvaluje dovolenou, bude můj příklad fungovat perfektně.

Jestli jsi to nepochopil, tak právě v těch případech bylo to rozporování implicitně obsaženo: upozorňovali jsme Tě na případ, který Tvé zadání neumí pochytit, ač je potřeba.
Já jsem reagoval především na Miroslava Šilhavého, který zadání prostě ignoroval a řešil něco, co bylo v rozporu se zadáním. To, že vy jste si vymyslel svůj vlastní příklad, který není kompatibilní s mým zadáním, je váš problém – o zadání neříká vůbec nic. Když já potřebuji odvézt tři lidi autem a vy potřebujete odvézt metrák uhlí, nedokážete nefunkčnost mého řešení tím, že je nefunkční pro vás.

že chybu toho zadání nevidíš
Zatím nikdo chybu v zadání neukázal. Akorát jste ukázal jiná zadání.

Pokolikáté budu muset zopakovat, že ŘEŠENÍ NEBYLO V ROZPORU S TVÝM ZADÁNÍM, do navržené datové struktury šlo uložit i data požadovaná dle tvého chybného zadání.
Opakovat to můžete kolikrát chcete, ale pravda to není. Řeč není o datové struktuře. Řeč je o zadání „vedoucí je definován tím, že má podřízené“ a reakcí „co když vedoucí nemá podřízené“. Kolikrát ještě budu muset zopakovat, že není možné, aby vedoucí zároveň měl i neměl podřízené?

Uvědom si, k ČEMU MĚL TEN TVŮJ PŘÍKLAD SLOUŽIT: K DEMONSTRACI BEST PRACTICIES při návrhu databáze.
Nikoli. Příklad měl jen ukázat, že struktura databáze neurčuje, jak se budou v dotazech spojovat tabulky. Nad stejnou strukturou tabulek můžete dělat INNER i OUTER JOIN – výstup pak má jiný význam.

tak by v praxi bylo Tvé řešení chybné, protože dřív či pozdějc by se na omezení toho návrhu narazilo tak jako tak. To je jedna z dalších věcí, která dělá dobrého programátora: když už šéf/klient neuhne a chce blbost, tak SW navrhnout aspoň tak, aby ta blbost vadila co nejméně.
Tohle je častá chyba začínajících programátorů – implementují bez znalosti problematiky jakési obecné řešení, jehož výhoda se má ukázat někdy v budoucnosti. Jenže v budoucnosti se ukáže, že potřeby uživatele jsou úplně jiné, program na potřebné změny připravený není, zato je velmi komplikuje to „obecné řešení“.

Vždyť to bylo vidět i na zdejší diskusi. V zadání bylo, že vedoucí je definován tím, že má podřízené. Zadavatel na to může spoléhat – že mu aplikace ohlídá, že nemá vedoucího bez podřízených. Jenže pak jste společnými silami přišli s tím, že to má být v databázi uložené jako příznak, takže je nutná explicitní kontrola. Jenže pomocí cizích klíčů to nejde, pomocí triggerů to neumíte a v aplikaci to kontrolovat nechcete. Takže tam tu kontrolu mít nebudete. Takže jste se přes „vylepšování pro budoucí použití“, několik hloupých pravidel a neznalost dostali k tomu, že vaše aplikace je sice perfektně připravená na budoucí změny, akorát že nesplňuje současné zadání, protože umožní mít vedoucího, který nemá podřízené.

A je úplně jedno, že se vám nelíbí use-case „vedoucí je definován tím, že má podřízené“ – stejné vztahy mohou existovat v jiných případech, třeba „štítek je definován tím, že existují objekty, které mají daný štítek přiřazen“.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 22. 10. 2019, 12:17:27
Já jsem reagoval především na Miroslava Šilhavého, který zadání prostě ignoroval a řešil něco, co bylo v rozporu se zadáním. To, že vy jste si vymyslel svůj vlastní příklad, který není kompatibilní s mým zadáním, je váš problém – o zadání neříká vůbec nic. Když já potřebuji odvézt tři lidi autem a vy potřebujete odvézt metrák uhlí, nedokážete nefunkčnost mého řešení tím, že je nefunkční pro vás.

Ale to je úplně ten samý případ. Racchek jasně definoval, že v návrhu má i neexistence záznamu v tbl2 svůj význam.

Dále pak specifikoval jeden konkrétní dotaz, ve kterém nemají význam řádky bez existence záznamu v tbl2.

Je však zřejmé, pokud pracuje s premisou, že v tbl2 záznam existovat může a nemusí, že v jiných dotazech bude nutně pracovat i s touto situací. V tu chvíli je to na OUTER JOIN situace jak vyšitá - spojení tabulek vyjadřuje strukturou jejich význam (sémantiku), pomocí WHERE pak definujete jen to, co Vás zrovna zajímá.

Racchekovi jste poradil přemýšlení klasické programátorské lopaty, ale bylo zcela na místě ho naučit přemýšlet v kontextu.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 22. 10. 2019, 13:02:18
Citace
Že nebude fungovat můj příklad jste neukázal. Pokud je např. jediná funkce vedoucího, že schvaluje dovolenou, bude můj příklad fungovat perfektně.
Ukázal jsem, že Tvůj příklad v situacích, které v praxi vcelku běžně nastávají, nebude fungovat: např. dojde k tomu, že se vedoucím pracovníků nedostanou potřebné informace, nebo že v případě návratu z mateřské po reorganizaci by člověku nezařazenému do firemní struktury neměl kdo dovolenou schválit.
Tvůj argument je špatný: to, že nějaký model funguje v jedné konkrétní situaci není důkaz toho, že je dobrý. Dobrý model funguje ve všech situacích, které s nějakou nemizivou pravděpodobností mohou nastat.

Citace
Když já potřebuji odvézt tři lidi autem a vy potřebujete odvézt metrák uhlí,
Chybný příměr. Software není věc na jedno použití. Správný příměr by byl: "Když já potřebuju (mám v zadání) odvážet lidi autem a vy TVRDÍTE, ŽE BUDU NĚKDY POTŘEBOVAT ODVÉZT I UHLÍ". A to je naprosto legitimní námitka, která podle toho, o koho jde, může či nemusí být správná. A moji arugmentaci, že česká legislativa i potřeby firemní praxe jsou takové, že si v podstatě odvážení uhlí vynucují, jste nijak nevyvrátil.

Citace
Tohle je častá chyba začínajících programátorů – implementují bez znalosti problematiky jakési obecné řešení, jehož výhoda se má ukázat někdy v budoucnosti.
Ano, to je častá chyba. Stejně jako je chyba začínajících programátorů, že slepě dodržují zadání, i když jsou v něm zjevné chyby. Zkušený programátor posoudí zadání a vyhodnotí dle své znalosti dané problematiky, kde je na místě ho nezobecňovat a kde je třeba ho zobecnit, popř. změnit (což dle procesů ve firmě někdy i může udělat sám, jindy to znamená složitý proces.)

A přesně tak zněla má argumentace: na příkladech z praxe jsem ukázal, proč dané zadání nebude dostačovat a tedy proč v tomto případě ho zobecnit na místě je. Ty jsi se to nejprve snažil vyvrátit - a ukázalo se, že o příslušné legislativě a z ní plynoucích potřebách pro praxi příliš nevíš (viz Tvůj vedoucí schvalující si sám dovolenou, nebo vůbec definice vedoucího odporující zákonu), a pak jsi toho radši nechal a vrátil ses k svému stanovisku: "toto je moje zadání a kdo ho slepě nedodrží anebo kdo ho implementuje obecněji, tak to dělá špatně.
Tak nevím, na koho to "implementuje bez znalosti problematiky" sedí spíš.... :-)


Citace
Nikoli. Příklad měl jen ukázat, že struktura databáze neurčuje, jak se budou v dotazech spojovat tabulky.
Napsal jsi: " Např. pokud je vedoucí zaměstnanec definován tím, že má podřízené, nemá smysl vytvářet si pohled s vedoucími..."Tedy jsi stanovoval "jak se to má dělat". Stejnětak jako Miroslav hájil outer join, tedy jak se to má dělat. Samozřejmě, že tím nemyslel, že se má 100% joinů dělat OUTER. Ale že to má smysl v běžných situacích. Tedy Miroslav stanovoval best practice.
Ty tvrdíš, že jeho best practice je špatná. Tedy říkáš, že best practice je jiná. Tedy ji stanovuješ - a vyvracíš ji příkladem, který je mimo praxi...

Citace
...pomocí triggerů to neumíte...
Ten, kdo se vyhýbá triggerům a bojí se databázovýho programování a radši tu logiku buďto nacpe až do aplikační vrstvy (čímž vznikne problematická situace, kdy různé constrainy jsou vynucované na různé úrovni aplikace), nebo ji v DB vynutí primitivními a neflexibilními mechanismy (přímo strukturou DB) aby se vyhnul triggerům, jsi jaksi Ty. Tak fakt nechápu, proč z toho obviňuješ nás....
Ano, když se člověk vyhýbá nástrojům, které je třeba použít k správnému návrhu databáze, tak tu databázi zkriplí.

Citace
stejné vztahy mohou existovat v jiných případech, třeba „štítek je definován tím, že existují objekty, které mají daný štítek přiřazen“.
Jo, klasika. Tak přesně vznikají ty databáze, kde je hromada šťítků typu: "Novinka", "Novinky", "novinky", "novikny", "novynky", "novikni"..... Kdybych byl vznětlivější typ, tak bych měl chuť zpřerážet hnáty člověku, co tu databázi takhle blbě navrhnul. Todle je i proti základním principům db programování (denormalizovaná struktura).
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 22. 10. 2019, 13:55:44
Ukázal jsem, že Tvůj příklad v situacích, které v praxi vcelku běžně nastávají, nebude fungovat
Co na tom nechápete, že příklad nevhodný pro jednu situaci může být vhodný pro jinou situaci? Opravdu je pro vás tak těžké pochopit, že to, že je osobní auto nevhodné pro převoz metráku uhlí, neznamená, že není vhodné k ničemu?

Tvůj argument je špatný: to, že nějaký model funguje v jedné konkrétní situaci není důkaz toho, že je dobrý.
Ale já jsem nedokazoval, že je dobrý. Pro mé účely úplně stačilo, že je možný.

A to je naprosto legitimní námitka, která podle toho, o koho jde, může či nemusí být správná. A moji arugmentaci, že česká legislativa i potřeby firemní praxe jsou takové, že si v podstatě odvážení uhlí vynucují, jste nijak nevyvrátil.
Ta námitka je úplně mimo. Šlo jen o příklad, kdy je možné použít určitou strukturu tabulek. Vy jste se na tom zasekli, místo abyste řešili podstatu, totiž že struktura tabulek neimplikuje, jaký JOIN se má použít.

Ty jsi se to nejprve snažil vyvrátit - a ukázalo se, že o příslušné legislativě a z ní plynoucích potřebách pro praxi příliš nevíš
Já jsem vaše tvrzení nevyvracel, vyvracel jsem tvrzení Miroslava Šilhavého, který napsal něco, co bylo v rozporu se zadáním, aniž by se tím rozporem jakkoli zabýval. Dokonce jsem přešel i vaši neznalost legislativy, kdy si pletete pojem „vedoucí“ (který legislativa nezná) s pojmem „vedoucí zaměstnanec“.

Ty tvrdíš, že jeho best practice je špatná. Tedy říkáš, že best practice je jiná.
Pokud za best practice označujete i tvrzení „tímto způsobem to vůbec neposuzujte, závisí to na úplně jiných parametrech“, pak je to best practice.

Ten, kdo se vyhýbá triggerům a bojí se databázovýho programování a radši tu logiku buďto nacpe až do aplikační vrstvy (čímž vznikne problematická situace, kdy různé constrainy jsou vynucované na různé úrovni aplikace), nebo ji v DB vynutí primitivními a neflexibilními mechanismy (přímo strukturou DB) aby se vyhnul triggerům, jsi jaksi Ty.
Omyl. To Miroslav Šilhavý napsal, že to nejde kontrolovat pomocí cizích klíčů, tudíž to v databázi nejde zkontrolovat vůbec.

Ano, když se člověk vyhýbá nástrojům, které je třeba použít k správnému návrhu databáze, tak tu databázi zkriplí.
Souhlas. Jenže Miroslav Šilhavý se tu tváří, jako kdovíjaký expert na databáze.

Jo, klasika. Tak přesně vznikají ty databáze, kde je hromada šťítků typu: "Novinka", "Novinky", "novinky", "novikny", "novynky", "novikni"..... Kdybych byl vznětlivější typ, tak bych měl chuť zpřerážet hnáty člověku, co tu databázi takhle blbě navrhnul. Todle je i proti základním principům db programování (denormalizovaná struktura).
To je ale záměr. Štítky jsou prostě libovolný text, který si uživatel k objektu přilepí. Jestli má potřebu vytvořit si štítky „Novinka“ i „Novinky“, ať to klidně udělá. Je to na něm, aplikace mu pouze poskytne nástroj, jak se štítky snadno pracovat. Pokud píše „Novi“, aplikace mu našeptává „Novinka“ a on se stejně rozhodne vytvořit nový štítek „Novinky“, asi k tomu má důvod.

Pokud má uživatel možnost štítky libovolně vytvářet a mazat a štítky nenesou žádnou další informaci, nedává smysl vytvořit si tabulku štítků, která bude mít jediný sloupec, a to název štítku. To není denormalizace.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 22. 10. 2019, 14:06:04
Omyl. To Miroslav Šilhavý napsal, že to nejde kontrolovat pomocí cizích klíčů, tudíž to v databázi nejde zkontrolovat vůbec.

Zkontrolovat to jde pomocí funkce a CHECK CONSTRAINT.

Ale je to zjevná pitomost, protože v době zakládání vedoucího byste musel jít postupem:

Při výměně týmu byste musel postupovat složitěji:

To je zcela nesmyslné zalgoritmizování na tak triviální úkol.
Vedoucího tak či onak musíte označit příznakem - takže vedoucí se pozná tímto způsobem.

Druhá otázka je, který pracovník má pod sebou další pracovníky. To už se kontroluje zcela nezávisle.
Z pohledu byznysové analýzy jsou to dvě odlišné otázky.

si pletete pojem „vedoucí“ (který legislativa nezná) s pojmem „vedoucí zaměstnanec“

Tady už si děláte vysloveně zadek. To je argumentace Aničky a Pepíčka na pískovišti. Anička tvrdí: pískoviště je moje, já tu byla dřív. Pepíček tvrdí: ale já tu byl už včera a krom toho jsem donesl bábovičky.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 22. 10. 2019, 15:19:39
Pokud má uživatel možnost štítky libovolně vytvářet a mazat a štítky nenesou žádnou další informaci, nedává smysl vytvořit si tabulku štítků, která bude mít jediný sloupec, a to název štítku. To není denormalizace.

Heh, i toto mluví samo za sebe.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 22. 10. 2019, 21:13:29
Citace
Co na tom nechápete, že příklad nevhodný pro jednu situaci může být vhodný pro jinou situaci?
S tou nevhodnou situací jsi ovšem přišel Ty sám, že "je třeba informovat vedoucí pracovníky". A na tuto TEBOU stanovenou situaci je TEBOU navržené řešení nevhodné, protože mi neumožní informovat člověka, o kterém vím, že zítra ty podřízené pracovníky mít bude. Takže možná existuje nějaká situace, kde by to vhodné bylo, ale bude velmi speciální, když Ty sám jsi se užitečnost toho modelu snažil ukázat na situaci, kde selhal.
Citace
Ale já jsem nedokazoval, že je dobrý. Pro mé účely úplně stačilo, že je možný.
Nu, a ostatní Ti ten Tvůj "možný" model (který je spíše nemožný :-), ale dejme tomu) opravili na dobrý. A tam najednou Tebou navržený postup selhal.. A teď je otázka. Je lepší se učit postupy, které fungují na modelech, které nejsou dobré, nebo je lepší se učit postupy, které fungují na modelech dobrých?

Citace
Šlo jen o příklad, kdy je možné použít určitou strukturu tabulek.
Ovšem jelikož ten model není dobrý, tak to dokazuje jen známou věc: garbage-in garbage-out.
Citace
Omyl. To Miroslav Šilhavý napsal, že to nejde kontrolovat pomocí cizích klíčů, tudíž to v databázi nejde zkontrolovat vůbec.
Máš evidentně problém pochopit, co druhý tvrdí. Miroslav tvrdil, že to nejde zkontrolovat bez existence explicitního příznaku. Máš pravdum že debata o tom, co by se kontrolovalo v DB bez příznaku je vlastně absurdní. Jenže to je vlastně důsledek absurdní definice vedoucího: jde totiž o klasickou definici kruhem: že ten kdo má podřízené má podřízené.

Ty jsi se touto tautologickou definicí se snažil dát dotazu: "ti kdo mají podřízené" nějaký větší smysl oproti dotazu "ti, kdo nemají podřízené". Ale tam prostě žádný větší smysl není, což ukazuje i praxe, protože v ní je třeba definovat vedoucího jinak.

===

Citace
To je ale záměr. Štítky jsou prostě libovolný text, který si uživatel k objektu přilepí. Jestli má potřebu vytvořit si štítky „Novinka“ i „Novinky“, ať to klidně udělá.
Uffff. Na to se dá říct jen to, že evidentně nemáš zkušenosti s tím, čeho jsou uživatelé schopni, a že bych fakt nechtěl pracovat s DB navrženou podle Tebou ražených principů
Citace
Je to na něm, aplikace mu pouze poskytne nástroj, jak se štítky snadno pracovat.
Ano, vypíchl bych z toho to SNADNO. Ano, např. když mu aplikace neposkytne přehled použitých šťítků, a možnost je např. přejmenovávat a slučovat, tak duplicity budou v podstatě nutně vznikat. Samozřejmě přehled štítků je možné udělat i z Tvojí struktury pomocí select distinct, ale to už je zas klasickej rovnák na vohejbák (např. místo toho, aby člověk na takovej přehled použil "klasickýho admina", kterej každá lopata vygeneruje automaticky, tak to budeš muset extra psát).

Citace
Pokud má uživatel možnost štítky libovolně vytvářet a mazat a štítky nenesou žádnou další informaci, nedává smysl vytvořit si tabulku štítků, která bude mít jediný sloupec, a to název štítku. To není denormalizace.
Je to buďto porušení 3NF, anebo porušení jiného naprosto základního dabázového principu: "Nevýznamových identifikátorů míti budeš". Tebou ražený princip je stejná pitomost, jako např. mít v DB jako klíč rodné číslo.A tento přístup se Ti brzo vymstí, jakmile např. bude chtít zákazník štítky prioritizovat, nebo např. třeba lokalizovat do více jazyků. Todle je fakt s odpuštěním čuňárna.
 

Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 22. 10. 2019, 21:18:08
Ano, vypíchl bych z toho to SNADNO. Ano, např. když mu aplikace neposkytne přehled použitých šťítků, a možnost je např. přejmenovávat a slučovat, tak duplicity budou v podstatě nutně vznikat. Samozřejmě přehled štítků je možné udělat i z Tvojí struktury pomocí select distinct, ale to už je zas klasickej rovnák na vohejbák (např. místo toho, aby člověk na takovej přehled použil "klasickýho admina", kterej každá lopata vygeneruje automaticky, tak to budeš muset extra psát).

Zde je možná ještě na místě dodat, že štítky se často používají nad více tabulkami. Pak by bylo nutné tvořit DISTINCT UNION DISTINC [UNION DISTINCT ...], což myslím jen podtrhuje absurditu takového návrhu.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 22. 10. 2019, 21:57:07
S tou nevhodnou situací jsi ovšem přišel Ty sám, že "je třeba informovat vedoucí pracovníky". A na tuto TEBOU stanovenou situaci je TEBOU navržené řešení nevhodné, protože mi neumožní informovat člověka, o kterém vím, že zítra ty podřízené pracovníky mít bude.
Jenže já jsem nepopisoval takhle obecnou situaci.

Nu, a ostatní Ti ten Tvůj "možný" model (který je spíše nemožný :-), ale dejme tomu) opravili na dobrý.
Model, který odporuje zadání, lze těžko nazývat dobrým.

Miroslav tvrdil, že to nejde zkontrolovat bez existence explicitního příznaku.
Nikoli. Mimochodem, bez explicitního příznaku není co kontrolovat. Což je právě ta výhoda mého řešení, že nemusíte pracně udržovat kopii informace, protože vždy pracujete s primárním zdrojem.

Jenže to je vlastně důsledek absurdní definice vedoucího: jde totiž o klasickou definici kruhem: že ten kdo má podřízené má podřízené.
Takhle já jsem to ovšem nedefinoval. Když si takhle předefinujete vaši definici, totiž že podřízené má ten, kdo může a nemusí mít podřízené, absurdního a tom není nic, že…

Ty jsi se touto tautologickou definicí se snažil dát dotazu: "ti kdo mají podřízené" nějaký větší smysl oproti dotazu "ti, kdo nemají podřízené".
A další vaše dojmologie, která nemá nic společného s tím, co jsem ve skutečnosti psal.

Uffff. Na to se dá říct jen to, že evidentně nemáš zkušenosti s tím, čeho jsou uživatelé schopni, a že bych fakt nechtěl pracovat s DB navrženou podle Tebou ražených principů
Takže vy byste uživatelům neumožnil vytvářet nové štítky? Vytvářel by je nějaký administrátor, nebo by dokonce dostali od vás předem určenou sadu štítků? Obávám se, že jste nepochopil princip štítků…

Ano, např. když mu aplikace neposkytne přehled použitých šťítků a možnost je např. přejmenovávat a slučovat
Proč by mu takový přehled neposkytla? V mém řešení je to jednoduché.

Samozřejmě přehled štítků je možné udělat i z Tvojí struktury pomocí select distinct, ale to už je zas klasickej rovnák na vohejbák
Nikoli, je to přesně to, jak se se štítky pracuje. Je to prostě nějaký text, který se přilepí k dané entitě. Nenese žádnou další informaci, vzniká prostě tím, že se k dané entitě připojí, maže se tak, že se od entity smaže. Neexistuje žádný seznam povolených štítků, nezakládají se nové štítky ani se nemažou. Pokud chci seznam všech štítků, sesypu všechny použité štítky na jednu hromadu.

Je to buďto porušení 3NF, anebo porušení jiného naprosto základního dabázového principu: "Nevýznamových identifikátorů míti budeš". Tebou ražený princip je stejná pitomost, jako např. mít v DB jako klíč rodné číslo. A tento přístup se Ti brzo vymstí, jakmile např. bude chtít zákazník štítky prioritizovat, nebo např. třeba lokalizovat do více jazyků. Todle je fakt s odpuštěním čuňárna.
Jasně, zákazník chtěl jednoduché štítky, tak, jak je má každá aplikace. Ale vy mu z toho uděláte raketoplán, protože co kdyby to náhodou někdy potřeboval. Uživatel si původně chtěl jenom něco označit svými názvy, a teď musí určit prioritu štítku, přeložit ho do dalších jazyků a přes vedoucího požádat administrátora systému o založení štítku.

Když už to prezentujete jako rady začátečníkům, dodejte také kontext. Že jsou to rady pro vývoj na projektu, který se bude vyvíjet několik let a v nejlepším případě se nikdy nenasadí, bude na něm dělat spousta programátorů, takže alespoň někteří budou programovat aspoň přibližně to, co chtěl zákazník – a pak si možná někdo může vymýšlet svou vlastní práci a programovat složitě něco, co vůbec nikdo nechtěl a nikdy to nikdo nebude používat.

Máš evidentně problém pochopit, co druhý tvrdí.
Napsal jste komentář, kde jsou všechny vaše interpretace jiných komentářů (nejen mých) chybné. Problém je evidentně na vaší straně. Nějak nevidím smysl v tom, abych dál opravoval vaše dezinterpretace – ty původní komentáře si přece můžete přečíst sám.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 22. 10. 2019, 21:58:43
Zde je možná ještě na místě dodat, že štítky se často používají nad více tabulkami. Pak by bylo nutné tvořit DISTINCT UNION DISTINC [UNION DISTINCT ...], což myslím jen podtrhuje absurditu takového návrhu.
A jindy zase chci jednu sadu štítků pro jednu entitu a jinou sadu štítků pro jinou entitu. Ale pokud jste chtěl ukázat, že neexistuje jeden univerzální návrh databáze, který by se hodil na všechno, pak se vám to podařilo. Gratuluju, úžasný objev.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 22. 10. 2019, 21:59:34
Když už to prezentujete jako rady začátečníkům, dodejte také kontext. Že jsou to rady pro vývoj na projektu, který se bude vyvíjet několik let a v nejlepším případě se nikdy nenasadí, bude na něm dělat spousta programátorů, takže alespoň někteří budou programovat aspoň přibližně to, co chtěl zákazník – a pak si možná někdo může vymýšlet svou vlastní práci a programovat složitě něco, co vůbec nikdo nechtěl a nikdy to nikdo nebude používat.

Projekty začátečníků != bastl.
Vaše rady == bastl.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 22. 10. 2019, 22:01:17
A jindy zase chci jednu sadu štítků pro jednu entitu a jinou sadu štítků pro jinou entitu. Ale pokud jste chtěl ukázat, že neexistuje jeden univerzální návrh databáze, který by se hodil na všechno, pak se vám to podařilo. Gratuluju, úžasný objev.

Jasně, zákazník chtěl jednoduché štítky, tak, jak je má každá aplikace. Ale vy mu z toho uděláte raketoplán, protože co kdyby to náhodou někdy potřeboval. Uživatel si původně chtěl jenom něco označit svými názvy, a teď musí určit prioritu štítku, přeložit ho do dalších jazyků a přes vedoucího požádat administrátora systému o založení štítku.

Tato dvě tvrzení mi nejdou do sebe. Doublethink?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 22. 10. 2019, 22:40:33
Samozřejmě přehled štítků je možné udělat i z Tvojí struktury pomocí select distinct, ale to už je zas klasickej rovnák na vohejbák
Nikoli, je to přesně to, jak se se štítky pracuje. Je to prostě nějaký text, který se přilepí k dané entitě. Nenese žádnou další informaci, vzniká prostě tím, že se k dané entitě připojí, maže se tak, že se od entity smaže. Neexistuje žádný seznam povolených štítků, nezakládají se nové štítky ani se nemažou. Pokud chci seznam všech štítků, sesypu všechny použité štítky na jednu hromadu.

Tento přístup se v relačních databázích nepoužívá, to dělají jen bastly přes ORM.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 23. 10. 2019, 07:21:14
Tento přístup se v relačních databázích nepoužívá, to dělají jen bastly přes ORM.
Možná proto je teď takový boom NoSQL databází. Protože když si někdo nechá poradit s něčím, co by řešil jeden sloupeček, od „databázového SQL specialisty“, navrhne dotyčný několik tabulek a k údržbě bude potřeba uložené procedury a triggery.

Ostatně svědčí o tom i to, že já jsem popsal už dva příklady, ale Miroslav Šilhavý nebo Logik ještě ani jeden – asi ještě přidávají další tabulky. Tak doufám, že se někdy dočkám příkladu, kde by se podle nich použil INNER JOIN – tak, že nejprve obecně popíšou pravidlo, kdy se podle nich má používat INNER JOIN, a pak to ukáží na konkrétním příkladu.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 23. 10. 2019, 08:49:58
Tento přístup se v relačních databázích nepoužívá, to dělají jen bastly přes ORM.
Možná proto je teď takový boom NoSQL databází. Protože když si někdo nechá poradit s něčím, co by řešil jeden sloupeček, od „databázového SQL specialisty“, navrhne dotyčný několik tabulek a k údržbě bude potřeba uložené procedury a triggery.

Je to krátkozraké. Co když bude potřebný víc než jeden štítek? A co indexování štítků pro lepší vyhledávání? Bude to stíhat, když budu pravidelně potřebovat seznam štítků?

Pro evidenci domácích CD bych však jeden sloupeček pro štítky klidně použil.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 23. 10. 2019, 09:53:43
Ostatně svědčí o tom i to, že já jsem popsal už dva příklady, ale Miroslav Šilhavý nebo Logik ještě ani jeden – asi ještě přidávají další tabulky. Tak doufám, že se někdy dočkám příkladu, kde by se podle nich použil INNER JOIN – tak, že nejprve obecně popíšou pravidlo, kdy se podle nich má používat INNER JOIN, a pak to ukáží na konkrétním příkladu.

INNER JOIN patří zejména tam, kde ze struktury dat musí existovat vazba 1:1-n. Typicky číselníky, nebo pravá strana dynamické vazby (zdroj_tbl LEFT JOIN vazba INNER JOIN cil_tbl). Tedy situace, kdy ani při odlišném pohledu na stejná data nedává smysl uvažovat o neexistující vazbě.

Dva příklady, které zde proběhly jsou přesně opačné. U tabulky oprávnění neexistence záznamu může vyjadřovat buďto to, že oprávnění je v implicitním nastavení, nebo že se má dědit z nadřazeného prvku (u stromové struktury). V případě nadřízených má OUTER JOIN taky smysl - nechcete z výpisu vyloučit nadřízeného, který jen dočasně nemá přiřazené podřízené. V obou těchto případech je důležité, aby si programátor tyto hraniční stavy uvědomoval. Pokud je zakryje INNER JOINEM, zdánlivě se mu bude zdát vše v pořádku - do doby, než problém vyplave na povrch v praxi.

Je to krátkozraké. Co když bude potřebný víc než jeden štítek? A co indexování štítků pro lepší vyhledávání? Bude to stíhat, když budu pravidelně potřebovat seznam štítků?

Ono se to dá řešit např. pomocí materializovaného pohledu ve kterém je DISTINCT, a refreshovat ho vždy jen po updatu. Otázkou je, jestli to není větší opičárna a jen omezeně škálovatelné.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 23. 10. 2019, 10:07:03
Citace
Jenže já jsem nepopisoval takhle obecnou situaci.
Samozřejmě. Protože tu furt prosazuješ řešení, který vyhoví jen pokud jdou věci dobře, a při první "neočekávaný" (ve skutečnosti očekávaný) situaci zhavaruje. Takovejch skvěle "jednoduchejch modelů" jsem se už napřepisoval a byla to někdy pořádná drbačka, když to aplikací proroste.....

Citace
Model, který odporuje zadání, lze těžko nazývat dobrým.
Opakuješ dokolečka už několikrát vyvrácené. Taková debata nemá smysl.

Takhle já jsem to ovšem nedefinoval
Ne, vy jste tak definoval vedoucího, což je ovšem zákonem definovaná věc, takže vaše definice na ní použít nejde. V praxi je Vaše definice: "ten kdo má podřízené" použitelná právě jen pro získání těch, kdo mají podřízené (a i tam viz informování) to chce myslet, kdy se takový dotaz hodí použít, a kdy chce člověk opravdu VEDOUCÍHO a ne jen "MAJITELE PODŘÍZENÝCH".
A když se oprostíme od honosných názvů a nazveme věci tím, co jsou, tak Váš dotaz je odpověď na jednoduchou otázku: "kdo má podřízené?" a nijak se neliší od dotazu: "kdo nemá podřízené?". Takže pro tento dotaz zrovna Miroslavova strategie - udělat si dotaz/pohled, z kterého mohu snadno odečíst obě informace, je přinejmenším dobrou strategií.

===

Citace
Proč by mu takový přehled neposkytla? V mém řešení je to jednoduché.
Ve vašem řešení to znamená psát admin nikoli přes primární entity, ale přes složitější dotaz. Tedy něco, s čím člověk místo toho, aby  použil v podstatě hotový mustr, tak se musí drbat s implementací speciálního případu . Uvědom si, že v rozumně velkém softu/frameworku má člověk takové věci, jako adminy závislých entit, a metody na jejich zakládání, přiřazování atd... hotové. Práce navíc není mít o tabulku víc, práce navíc je dělat řešení, které se nějak svoji strukturou odlišuje od standardního modelu, jak jsou v aplikaci modelovány vztahy, protože to musíš napsat znovu, nebo musíš existující "mustry" modifikovat.
Citace
Pokud chci seznam všech štítků, sesypu všechny použité štítky na jednu hromadu.
Což když půjde např. o štítky z více tabulek, bude fakt príma čistej a srozumitelnej kód. Ale to už lidi psali.
A i v případě jedné tabulky to má nevýhody: při přejmenování štítku to bude zbytečně zamykat všechny záznamy se štítkem, místo toho, co by si to prostě vedle změnilo štítek, SELECT DISTINCT v takovém případě bude full table scan, takže u větší db tomu začne docházet dech atd....
Samozřejmě, jde to řešit (např. materializovaným pohledem, jak píše Miroslav) - ale to už je ten klasický rovnák na vohejbák. Jednoduchost Tvého modelu je v tahu a udržovat takovou aplikaci je radost.....

Citace
Uživatel si původně chtěl jenom něco označit svými názvy, a teď musí určit prioritu štítku, přeložit ho do dalších jazyků a přes vedoucího požádat administrátora systému o založení štítku.
To, že něco daný model je schopen ještě neznamená, že to je vystaveno uživateli. Pořád dokolečka (viz druhý odstavec) máš problém pochopit, že je rozdíl mezi tím, na co je model připraven a co model uživateli vystaví. A že dobrý programátor připraví model na očekávatelné změny, pokud to je levné. Protože zatímco změna na aplikační úrovni je levná, změna DB struktury je hodně problematická (koexistence různých verzí aplikace, revert do staršího stavu, když si něco nesedne, atd. atd....).
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 23. 10. 2019, 10:15:27
Filipovi bylo potvrzeno to, že jeho řešení je funkční, jen bylo poznamenáno, že to lze řešit prozíravěji. Celý ten diskusní šprajc nechápu, připadá mi to jako "proč to dělat dobře a stejně jednoduše, když to jde i blbě a stejně jednoduše".
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 23. 10. 2019, 10:27:07
Je to krátkozraké. Co když bude potřebný víc než jeden štítek? A co indexování štítků pro lepší vyhledávání? Bude to stíhat, když budu pravidelně potřebovat seznam štítků?

Pro evidenci domácích CD bych však jeden sloupeček pro štítky klidně použil.
To myslíte vážně? Pokud bude povoleno víc štítků, potřebuju vazební tabulku – nijak to nesouvisí s tím, zda mám nebo nemám číselník štítků. Indexování štítků se udělá tak, že se na příslušném sloupečku dá normálně index.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 23. 10. 2019, 10:28:45
Filipovi bylo potvrzeno to, že jeho řešení je funkční, jen bylo poznamenáno, že to lze řešit prozíravěji. Celý ten diskusní šprajc nechápu, připadá mi to jako "proč to dělat dobře a stejně jednoduše, když to jde i blbě a stejně jednoduše".
Přesně tak. Vy navrhujete „proč to dělat dobře a jednoduše, když to jde i blbě a složitě“. Celý ten diskusní šprajc je jenom o tom, že když vy to chcete dělat blbě a složitě, klidně to tak dělejte, ale neraďte to začátečníkům jako best practice.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 23. 10. 2019, 10:35:29
Zase jen dokola opakujete vyvrácené. Pokud chcete nějakou reakci, přečtěte si mé předchozí komentáře, nedává smysl, abych je znovu opakoval.

Jediné nové, co jste napsal, je zase nesmysl:
při přejmenování štítku to bude zbytečně zamykat všechny záznamy se štítkem, místo toho, co by si to prostě vedle změnilo štítek
Přejmenování štítku je výjimečná operace. Vy ale budete muset složitě řešit přidávání štítku i mazání štítku, což jsou mnohem častější operace.

SELECT DISTINCT v takovém případě bude full table scan
O existenci indexů jste už slyšel?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 23. 10. 2019, 10:45:31
O existenci indexů jste už slyšel?

Radost indexovat field, ve kterém je pole štítků.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 23. 10. 2019, 13:35:53
Citace
Přejmenování štítku je výjimečná operace. Vy ale budete muset složitě řešit přidávání štítku i mazání štítku, což jsou mnohem častější operace.
Ty jsi nikdy pořádnou aplikaci nevyvíjel, nebo fakt nevím. Na takovéto základní úkony (např. přidávání entit s relací n:m) jsou samozřejmě v každém rozumnějším frameworku nástroje, takže implementace nebude složitější, než bez "štítkové tabulky", je to na pár řádek.

Citace
Citace
SELECT DISTINCT v takovém případě bude full table scan
O existenci indexů jste už slyšel?
Evidentně narozdíl od Tebe nejen slyšel, ale umím je i používat a vím, kdy se použijí a kdy ne :-)

Kód: [Vybrat]
=> create index test on translations(table_name);
CREATE INDEX
=> vacuum analyze translations;
VACUUM
=> EXPLAIN SELECT DISTINCT table_name FROM translations ;                                 
QUERY PLAN                                 
----------------------------------------------------------------------------
 HashAggregate  (cost=11158.59..11158.77 rows=18 width=11)
   Group Key: table_name
   ->  Seq Scan on translations  (cost=0.00..10231.67 rows=370767 width=11)
(3 rows)

Pokud bys chtěl použít index, tak na to musíš v takovémto případě použít speciální "hack" pomocí CTE. Aneb jak jsou tvoje "jednoduchá" řešení "jednoduchá":
https://stackoverflow.com/questions/5973850/can-i-optimize-a-select-distinct-x-from-hugetable-query-by-creating-an-index-on (https://stackoverflow.com/questions/5973850/can-i-optimize-a-select-distinct-x-from-hugetable-query-by-creating-an-index-on)
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 23. 10. 2019, 14:03:48
Důvod je prostý: Pokud má engine volbu, zda projít všechny záznamy nebo všechny klíče v indexu, zvolí průchod všemi záznamy. Distinct na to nemá vliv.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 23. 10. 2019, 17:53:00
Evidentně narozdíl od Tebe nejen slyšel, ale umím je i používat a vím, kdy se použijí a kdy ne :-)
Umíte je používat? Vážně?

Kód: [Vybrat]
CREATE TABLE stitky (stitek VARCHAR NOT NULL);
CREATE INDEX idx_stitky ON stitky USING BTREE (stitek);
INSERT INTO stitky (stitek) VALUES ('Praha1'), ('Praha1'), ('Brno1'), ('Ostrava1'), ('Brno1'), ('Praha1'), ('Praha1'), ('Ostrava1'), ('Zlín1');

INSERT INTO stitky (stitek) VALUES ('Praha10'), ('Praha10'), ('Brno10'), ('Ostrava10'), ('Brno10'), ('Praha10'), ('Praha10'), ('Ostrava10'), ('Zlín10');
VACUUM;
EXPLAIN SELECT DISTINCT stitek FROM stitky ORDER BY stitek LIMIT 10;
QUERY PLAN                             
-------------------------------------------------------------------------------------------
 Limit  (cost=0.14..2.35 rows=10 width=7)
   ->  Unique  (cost=0.14..9.88 rows=44 width=7)
         ->  Index Only Scan using idx_stitky on stitky  (cost=0.14..9.63 rows=99 width=7)

Samozřejmě, pokud na uživatele vylejete stovky štítků, ať si v tom hledá sám, protože to aplikace neumí, bude to pro databázi jiný úkol. Nicméně i tam se jí index bude hodit alespoň pro řazení. Teda pokud ty štítky aspoň seřadíte.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 23. 10. 2019, 18:52:26
Koukám, že jsi furt nepochopil, kde je v Tvé DB struktuře problém. Příklad byl ZÁMĚRNĚ bez řazení, aby Ti demonstroval, že INDEX NEUMÍ AKCELEROVAT OPERACI DISTINCT. V Tvém dotazu se index použije pouze na řazení, ale práci oproti full table scanu (nebo přesněji sekvenčnímu scanu, protože po nalezení dostatečného počtu hodnot se zastaví) Ti neušetří ani náhodou.

Problém je v tom, že v indexu jsou odkazy na VŠECHNY záznamy. NENÍ to seznam unikátních hodnot. Tedy když máš v tabulce milion záznamů, tak tam máš milion odkazů do primárního souboru. A pokud ten milion záznamů bude mít sto štítků s +- rovnoměrným rozdělením, tak Tvůj dotaz sice použije index, aby si ušetřil řazení, ale pořád ten Tvůj dotaz bude pro DB znamenat projít prvních sto tisíc záznamů indexu, aby těch deset unikátních hodnot našel. Skvělé, že?

Zkus si navýšit počet záznamů, aniž bys navýšil počet různých štítků - čas na dotaz Ti naroste. Btw. to je vidět i na Tvém vygenerovaném plánu, proč je tam asi ten operátor unique, že?
PS: A ano, mimochodem, přesně jsi to vystihl s tím NoSQL: ano přesně toto je důvodem boomu NoSQL databází. Protože když SQL databázi používají lidé, co jí nerozumí a dělají takovéto zprasené DB struktury, tak přechodem na NoSQL databázi jen získají. A typické je, že si myslí, že je to vina těch SQL databází....
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 23. 10. 2019, 20:46:51
Koukám, že jsi furt nepochopil, kde je v Tvé DB struktuře problém. Příklad byl ZÁMĚRNĚ bez řazení, aby Ti demonstroval, že INDEX NEUMÍ AKCELEROVAT OPERACI DISTINCT. V Tvém dotazu se index použije pouze na řazení, ale práci oproti full table scanu (nebo přesněji sekvenčnímu scanu, protože po nalezení dostatečného počtu hodnot se zastaví) Ti neušetří ani náhodou.
Příště se zase ohánějte tím, že mé příklady neodpovídají realitě. V mé DB struktuře je problém, že je připravená na reálné použití a není optimalizovaná na nesmyslné dotazy typu „potřebuji všechny štítky z databáze v náhodném pořadí“. Prozradím vám, kdy je ten váš dotaz obvykle potřeba – pokud je vaše aplikace tak neschopná, že si z ní uživatel raději data vyexportuje a pracuje s nimi dál v Excelu.

Problém je v tom, že v indexu jsou odkazy na VŠECHNY záznamy. NENÍ to seznam unikátních hodnot.
B-Tree vskutku není seznam, B-Tree je strom. Listy toho stromu jsou zaindexované hodnoty. Teprve od té hodnoty vede odkaz na seznam záznamů, kde se ta hodnota vyskytuje. Jenže v mnou uvedeném příkladu databáze ty záznamy vůbec nepotřebuje, protože hodnoty zná už z indexu.

bude pro DB znamenat projít prvních sto tisíc záznamů indexu
Mohl byste nám nastínit, jak podle vás vypadá takový databázový index? A jak ho databáze používá pro hledání, když podle vás prochází jakési „záznamy indexu“ jeden po druhém?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 23. 10. 2019, 21:22:29
Listy toho stromu jsou zaindexované hodnoty. Teprve od té hodnoty vede odkaz na seznam záznamů, kde se ta hodnota vyskytuje.
Díval jsem se ještě na B-Tree indexy Oraclu a PostgreSQL, a tam tohle neplatí. PostgreSQL má u neunikátního B-Tree indexu zapsané v indexu hodnoty opakovaně, protože každý list obsahuje odkaz na jeden řádek. Oracle má u neunikátního B-Tree indexu ROWID jako součást klíče, což je prakticky to samé. Teoreticky by nad těmi indexy mohly mít implementovanou funkci „najdi další klíč“, ale asi by nebyla moc využívaná. Pokud byste tedy opravdu použil pro štítky B-Tree index, máte pravdu.

Nicméně pro rozumnou implementaci štítků je potřeba použít fulltextový index. Tam už je to s jejich strukturou rozmanitější, nicméně s tím, že pod jedním klíčem bude větší množství záznamů, obvykle počítají.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: linuxak 23. 10. 2019, 21:24:18
B-Tree vskutku není seznam, B-Tree je strom. Listy toho stromu jsou zaindexované hodnoty. Teprve od té hodnoty vede odkaz na seznam záznamů, kde se ta hodnota vyskytuje.

Ne takhle to nefunguje. B-Tree jako takové nepodporuje duplicitní záznamy. Prakticky se to omezení obchází tak, že se k indexu, který povoluje duplicitní hodnoty, interně dolepí "virtuální" sloupec, ve kterém je autoinkrementovaná hodnota. Tím se ze všech duplicitních klíčů stanou neduplicitní.

A to je ten problém, který Ti nedochází a kvůli kterému je Tebou navržená struktura zoufale neefektivní. Nelze totiž levně přejít na další záznam, který se liší nevirtuálním sloupcem. Musíš totiž buď udělat sekvenční scan, nebo pro nalezení dalšího unikátního štítku udělat nové hledání se složitostí O(log N), kde N je počet všech neunikátních štítků. S extra tabulkou pro štítky je to O(1).

Dostuduj si základy databází a normalizace dat, máš v tom dost velké mezery.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 23. 10. 2019, 21:54:54
A to je ten problém, který Ti nedochází a kvůli kterému je Tebou navržená struktura zoufale neefektivní. Nelze totiž levně přejít na další záznam, který se liší nevirtuálním sloupcem.
Přečtěte si předchozí komentář, tam je to vysvětlené. Problém není ve struktuře dat, ale v použitém typu indexu. Přičemž pro štítky je B-Tree index nevhodný tak jako tak, pro štítky je potřeba používat fulltextový index.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 23. 10. 2019, 22:26:08
Citace
Pokud byste tedy opravdu použil pro štítky B-Tree index, máte pravdu.
Já narozdíl od Tebe netvrdím, že existuje nějaký index, který by Ti v tomto případě pomohl. Tedy jsem Ti na tom nejpřirozenějším indexu ukázal, že je to nesmysl. Ty jsi tvrdil, že Ti index pomůže a použil jsi B-Tree také. Ale furt je myšlenka, že B-Tree bude v běžných DB akcelerovat DISTINCT menší omyl (jen evidentní nedostatek praxe), než snaha použít na tento účel fulltext (což je úplné nepochopení, k čemu tento typ indexů slouží).

Citace
Nicméně pro rozumnou implementaci štítků je potřeba použít fulltextový index.
A jakej index např. v Postgres tedy použiješ? GIN nebo GIST? Nebo jiný? A to budeš hodnoty ukládat jako typ TSQuery, nebo jako jaký typ? No potěš koště....A jak Ti prosímtě takovej index pomůže????? Dáš nám sem nějaký usecase?

Jen si ve snaze nemuset uznat omyl jsi jen vymyslel ještě větší koninu. Fulltext slouží k indexaci slov v textu, nikoli k indexaci "celých hodnot" ve sloupci.Ještě tak by byl usecase pro fulltext narvat všechny štítky do jednoho pole a nad ním udělat fulltext - tam by dával tento typ indexu smysl. Ale to by jednak byla jiná struktura, než kterou si doteď razil, jednak by to byl jednak naprosto ukázkový příklad nesmyslné denormalizace, jednak ani tak by db neuměla Ti vrátit seznam použitých štítků.

Citace
...a není optimalizovaná na nesmyslné dotazy typu „potřebuji všechny štítky z databáze v náhodném pořadí“.
To byla demonstrace, že v Tvojí  struktuře to ta databáze prostě efektivně dělat nebude. Jestli Ti to nedošlo, tak kdyby to db uměla efektivně vrátit seřazené, tak by to uměla vrátit efektivně i bez požadavku na řazení - nikde není zakázáno, aby to vrátila seřazené, i když ji o to nikdo neprosí.

Citace
....že je připravená na reálné použití....
Tak už se shodneme, že Tebou navržená struktura neumí ani tak základní věc, jako vylistovat použité štítky v čase O(N), kde N je počet unikátních štítků, nebo tedy máš ještě nějaký pokus, jak znásilnit relační databázi?

Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 23. 10. 2019, 22:43:37
Budem se tu ještě dlouho plácat kolem štítků, když víme, že je to M:N? Máme na to jasný a osvědčený vzor s bázovou tabulkou, jedním číselníkem a jednou vazební tabulkou.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 23. 10. 2019, 22:53:45
Když to je těžký, když někdo chce znova vymejšlet kolo a ještě ho vymyslí hranatý.... :-)
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 23. 10. 2019, 22:54:33
Já narozdíl od Tebe netvrdím, že existuje nějaký index, který by Ti v tomto případě pomohl.
Aha. Takže uchovávat množinu krátkých textů je podle vás pro počítače neřešitelný úkol. Viděl jste někdy spellchecker, úplně tu nejprimitivnější implementaci? To je prostě množina slov, ve které se dá rychle vyhledat, jestli v ní dané slovo je nebo není. Seznam těch slov je možné i vypsat. Té struktuře, která umožňuje rychlé vyhledávání, se říká – index.

To, co potřebujete pro práci se štítky, je našeptávač. Přičemž našeptávače se běžně používají, fungují, a jsou implementované právě pomocí fulltextových indexů. Vypsat všechny hodnoty našeptávač (resp. použitý index) samozřejmě také umí, akorát se taková funkce v našeptávači neposkytuje uživatelům, protože je k ničemu.

To je právě ten rozdíl v našem přístupu. Já považuju za samozřejmost pro práci se štítky fulltextové a podobnostní vyhledávání (našeptávač). Pro vás je to zbytečnost, pak se ale divíte, že máte v databázi velmi podobné štítky. Jediné, co dokážete uživateli nabídnout, je vypsat mu všechny štítky, ať s nimi může pracovat v nějakém normálním programu a místo vaší aplikace.

Ale aspoň z toho máme další hezkou poučku pro začátečníky: pokud vaši uživatelé chtějí vypisovat stovky záznamů (ať už najednou, nebo stránkovaně), znamená to, že jim poskytujete špatné funkce pro filtrování a vyhledávání. Nikdo nechce hledat něco očima ve stovkách záznamů (nebo si to exportovat do Excelu a tam s tím čarovat).
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 23. 10. 2019, 23:03:42
Budem se tu ještě dlouho plácat kolem štítků, když víme, že je to M:N? Máme na to jasný a osvědčený vzor s bázovou tabulkou, jedním číselníkem a jednou vazební tabulkou.
Snad byste nechtěl porovnávat databázový výkon pro běžné operace – tj. získání seznamu štítků daného objektu, získání objektů s daným štítkem a přidání a smazání štítku u daného objektu. To ne, tady se přece porovnává výkon tak zásadních operací, jako je výpis všech štítků.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 23. 10. 2019, 23:18:47
Já narozdíl od Tebe netvrdím, že existuje nějaký index, který by Ti v tomto případě pomohl.
Aha. Takže uchovávat množinu krátkých textů je podle vás pro počítače neřešitelný úkol. Viděl jste někdy spellchecker, úplně tu nejprimitivnější implementaci? To je prostě množina slov, ve které se dá rychle vyhledat, jestli v ní dané slovo je nebo není. Seznam těch slov je možné i vypsat. Té struktuře, která umožňuje rychlé vyhledávání, se říká – index.

Je to řešitelné i bez M:N, ale používá se na to jiná metodika než prostý index. Udělá se další indexovaná tabulka, třeba i bez vazby na základní tabulku, ale zato s unikátním indexem, který nedovolí duplicitní vložení štítku. Taková tabulka už nemá milióny záznamů ale jen stovky a je tak pro našeptávač bezproblémově použitelná.

Je to denormalizované řešení, které tedy vyžaduje použití triggerů. Jeho možnou výhodou je, že se štítky po výmazu hlavního záznamu neztratí.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 23. 10. 2019, 23:26:13
Budem se tu ještě dlouho plácat kolem štítků, když víme, že je to M:N? Máme na to jasný a osvědčený vzor s bázovou tabulkou, jedním číselníkem a jednou vazební tabulkou.
Snad byste nechtěl porovnávat databázový výkon pro běžné operace – tj. získání seznamu štítků daného objektu, získání objektů s daným štítkem a přidání a smazání štítku u daného objektu. To ne, tady se přece porovnává výkon tak zásadních operací, jako je výpis všech štítků.

Pokud se to udělá M:N, tak číselník štítků bude mít jen stovky záznamů a práce s nimi bude velmi rychlá, včetně našeptávání. Rozhodně rychlejší, než index štítků v dlouhé tabulce.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 23. 10. 2019, 23:42:15
Citace
Viděl jste někdy spellchecker, úplně tu nejprimitivnější implementaci?
Viděl. Dokonce evidentně narozdíl od Tebe jsem custom-made fulltext i implementoval, takže vím, že
a) fulltext index se spelcheckerem vlastně nijak nesouvisí, jsou to dvě úplně jiné technologie. To, že některé DB mají ve fultextových indexech zabudovaný jako preprocessing možnost stemmingu, aby ho aplikovali na data před tím, než data uloží do fulltext indexu, to nic nemění - do fulltextových indexů jdou ukládat (a i se ukládají) i nenastemmovaná data a naopak jde stemovat i něco, co neuložím do indexu.

b) spellchecker/stemmer samotný používá zpravidla hunspell algoritmus, kde sice má databázi slov, ale ve velmi speciálním tvaru (pomocí seznamu kořenů, prefixů a infixů) a jde o zcela jiné uložení dat, než je jak v B-Tree, tak ve fulltextových indexech - a s otázkou, jak něco ukládat a vyhledávat v relační databázi vůbec nesouvisí.

c) pro našeptávač je v tomto případě asi nejlepší varianta použít tzn. trigram indexy, které narozdíl od stemmingu ve fulltext indexech umí vyhledat i překlepy, to ovšem je úplně jiný typ indexu, než fulltextový index - a stejně jako fulltextový index nejde použít k akceleraci operace distinct.
d) stemming může pro jedno slovo vrátit více kořenů, takže zmiňovat ho v souvislosti s akcelerací DISTINCT operace je nesmysl.

V každém případě vyhledávání štítků pro účely našeptávání je zcela jiná úloha, než o které jsme se bavili. Kdo se tady furt vztekal, že nedodržujeme zadání? :-). My jsme se bavili o tom, jak udělat admin štítků, kde kupodivu seznam štítků potřebuji vidět i celý, např. pro to, aby ho mohl člověk jednou za čas zrevidovat a např. sloučit duplicity. Ono v reálu - pokud na to ten nástroj je - tak jde udržovat seznam štítků rozumně dlouhý a tedy revidovatelný. U této úlohy začala debata o indexu a na začátku to byl pro Vás snadný úkol, kde jste se mne snažil poučovat o indexech. Teď jsme se najednou dobrali do situace, kdy se zjistilo, že to opravdu neumíte rozumným způsobem udělat a tak to najednou není potřeba....
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 24. 10. 2019, 07:08:43
V každém případě vyhledávání štítků pro účely našeptávání je zcela jiná úloha

Našeptávání je úplně jiná úloha. Když odmyslíme překlepy, tak našeptávání urychluje dohledání slova pomocí substringu (v nejjednodušším případě zleva). Na našeptání slova "hovado" je provedeno až šest dotazů a cílem je urychlit je jako celek. Naprosto nelze srovnat s dohledáním slova jedním dotazem, natož provedení distinkce.

Filipe, na DISTINCT opravdu indexy nezabírají. V mateřské škole pro databázové pracovníky se polopaticky učí, že je nutné data co nejvíc omezit a vyfiltrovat před tím, než se provádí distinct. Typickým zabijákem výkonu jsou distinct subselecty, distinct joiny apod., právě z tohoto důvodu.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 24. 10. 2019, 21:12:11
Našeptávání je úplně jiná úloha.
Našeptávání je jediná reálná úloha, kdy uživatel pracuje se seznamem štítků. Jak už jsem psal, pokud píšete databázovou aplikaci, kde uživatel často potřebuje získat seznam stovek nebo více záznamů, aby v nich pak sám něco ručně hledal, je na vaší aplikaci něco hodně špatně. Takže úloha „dej mi seznam všech štítků“ je sice hezké teoretické cvičení, ale pro praxi je to k ničemu.

Filipe, na DISTINCT opravdu indexy nezabírají.
Když píšete o implementaci nějakého konkrétního databázového enginu, konkrétně ho pojmenujte. Když to napíšete takhle obecně, někdo by si mohl myslet, že je to nějaký principiální problém.

spellchecker/stemmer
Až na to, že spellchecker je něco úplně jiného, než stemmer. Spellchecker je prostý dotaz „existuje toto slovo?“, případně vylepšený o „pokud neexistuje, jaká podobná slova existují?“. Stemmer je nalezení kořene slova.

Rozhodně rychlejší, než index štítků v dlouhé tabulce.
Jenom jestli to ví třeba Google, že vyhledávání slova ve fulltextovém indexu závisí na celkovém počtu dokumentů a ne na počtu různých slov v indexu.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 24. 10. 2019, 21:47:23
Filipe, na DISTINCT opravdu indexy nezabírají.
Když píšete o implementaci nějakého konkrétního databázového enginu, konkrétně ho pojmenujte. Když to napíšete takhle obecně, někdo by si mohl myslet, že je to nějaký principiální problém.

Jenže on to je principiální problém, se kterým si B-stromy ani heše neporadí. To by musel být ke každému klíči přidělen seznam ID záznamů, které tomu klíči vyhovují, abys mohl vždy vybrat jen ten první a jít dál.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 24. 10. 2019, 22:04:03
Jenže on to je principiální problém, se kterým si B-stromy ani heše neporadí. To by musel být ke každému klíči přidělen seznam ID záznamů, které tomu klíči vyhovují, abys mohl vždy vybrat jen ten první a jít dál.
Existují ale i jiné druhy indexů. Hash si s tím neporadí, protože v indexu není uložena hodnota. B-Tree si s tím může poradit například právě tím způsobem, jaký jste popsal – v každém listu bude uložen seznam záznamů, které ten klíč obsahují. Vybírat první záznam není potřeba, protože hodnotu zná databáze už z indexu. Problém s B-Tree je jenom tehdy, pokud se používá upravená varianta, která umožňuje ukládat duplicitní klíče přímo jako samostatné uzly stromu – jako to má právě PostgreSQL nebo Oracle. To ale není obecná vlastnost B-Tree, naopak je to spíš odchylka těchto databází od standardní implementace B-Tree (i když je to odchylka logická, protože umožňuje řešit neunikátní hodnoty pořád v rámci jedné datové struktury B-Tree).
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 24. 10. 2019, 22:20:51
Jenže on to je principiální problém, se kterým si B-stromy ani heše neporadí. To by musel být ke každému klíči přidělen seznam ID záznamů, které tomu klíči vyhovují, abys mohl vždy vybrat jen ten první a jít dál.
Existují ale i jiné druhy indexů. Hash si s tím neporadí, protože v indexu není uložena hodnota. B-Tree si s tím může poradit například právě tím způsobem, jaký jste popsal – v každém listu bude uložen seznam záznamů, které ten klíč obsahují. Vybírat první záznam není potřeba, protože hodnotu zná databáze už z indexu. Problém s B-Tree je jenom tehdy, pokud se používá upravená varianta, která umožňuje ukládat duplicitní klíče přímo jako samostatné uzly stromu – jako to má právě PostgreSQL nebo Oracle. To ale není obecná vlastnost B-Tree, naopak je to spíš odchylka těchto databází od standardní implementace B-Tree (i když je to odchylka logická, protože umožňuje řešit neunikátní hodnoty pořád v rámci jedné datové struktury B-Tree).

To by nebyl B-Tree.

V hešovaném indexu se neukládá heš, ale přímo klíče.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 24. 10. 2019, 22:33:48
Problém s B-Tree je jenom tehdy, pokud se používá upravená varianta, která umožňuje ukládat duplicitní klíče přímo jako samostatné uzly stromu – jako to má právě PostgreSQL nebo Oracle. To ale není obecná vlastnost B-Tree, naopak je to spíš odchylka těchto databází od standardní implementace B-Tree (i když je to odchylka logická, protože umožňuje řešit neunikátní hodnoty pořád v rámci jedné datové struktury B-Tree).

Aha, tak teď už rozumím, proč jste posílal explain z Postgresu. Chtěl jste demonstrovat, jak to Postgres ani nemůže umět!
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 24. 10. 2019, 22:51:09
To by nebyl B-Tree.
Pokud něco z uváděného není B-Tree (https://cs.wikipedia.org/wiki/B-strom), pak ta varianta používaná PostgreSQL,která umožňuje ukládat duplicitní klíče – protože striktní definice B-Tree vyžaduje lineárně uspořádané klíče.

V hešovaném indexu se neukládá heš, ale přímo klíče.
Hlavně tam musí být uložené odkazy na příslušné záznamy, které hashi odpovídají. Jestli tam budou uložené i klíče je věc implementace. Zrovna PostgreSQL nemá v hash indexu uložené klíče, ale jen jejich hashe. Zda záznam opravdu obsahuje požadovanou hodnotu (nebo jde jen o kolizi hashů) se zjistí teprve porovnáním skutečného záznamu z tabulky. Hash indexy v PostgreSQL tedy není možné použít pro optimalizované načítání dat přímo z indexu (bez čtení samotné tabulky).
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 24. 10. 2019, 23:00:16
To by nebyl B-Tree.
Pokud něco z uváděného není B-Tree (https://cs.wikipedia.org/wiki/B-strom), pak ta varianta používaná PostgreSQL,která umožňuje ukládat duplicitní klíče – protože striktní definice B-Tree vyžaduje lineárně uspořádané klíče.

Už výše bylo řečeno, že součástí toho klíče je i interní ID záznamu, které nemůže být duplicitní.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 25. 10. 2019, 07:41:37
Už výše bylo řečeno, že součástí toho klíče je i interní ID záznamu, které nemůže být duplicitní.
Podle tohoto popisu (https://habr.com/en/company/postgrespro/blog/443284/) není v PostgreSQL ID záznamu součástí klíče, ale je ve stromu uložené jako hodnota, na kterou se ten klíč odkazuje. Z čeho usuzujete na opak?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 25. 10. 2019, 09:13:40
Už výše bylo řečeno, že součástí toho klíče je i interní ID záznamu, které nemůže být duplicitní.
Podle tohoto popisu (https://habr.com/en/company/postgrespro/blog/443284/) není v PostgreSQL ID záznamu součástí klíče, ale je ve stromu uložené jako hodnota, na kterou se ten klíč odkazuje. Z čeho usuzujete na opak?

Takže to má jinak a připouští duplicitu klíče, viz klíč '49'. Jak by z tohoto měl jít udělat distinct jinak, než poctivým traverzováním?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 25. 10. 2019, 09:28:49
Už výše bylo řečeno, že součástí toho klíče je i interní ID záznamu, které nemůže být duplicitní.
Podle tohoto popisu (https://habr.com/en/company/postgrespro/blog/443284/) není v PostgreSQL ID záznamu součástí klíče, ale je ve stromu uložené jako hodnota, na kterou se ten klíč odkazuje. Z čeho usuzujete na opak?

Takže to má jinak a připouští duplicitu klíče, viz klíč '49'. Jak by z tohoto měl jít udělat distinct jinak, než poctivým traverzováním?

Já si myslím, že Filip hovoří o databázích, u kterých je (možná?) full table scan jednoho sloupce pomalejší, než totožné projití stejného počtu záznamů v indexu. Je to možné?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 25. 10. 2019, 09:56:47
Už výše bylo řečeno, že součástí toho klíče je i interní ID záznamu, které nemůže být duplicitní.
Podle tohoto popisu (https://habr.com/en/company/postgrespro/blog/443284/) není v PostgreSQL ID záznamu součástí klíče, ale je ve stromu uložené jako hodnota, na kterou se ten klíč odkazuje. Z čeho usuzujete na opak?

Takže to má jinak a připouští duplicitu klíče, viz klíč '49'. Jak by z tohoto měl jít udělat distinct jinak, než poctivým traverzováním?

Já si myslím, že Filip hovoří o databázích, u kterých je (možná?) full table scan jednoho sloupce pomalejší, než totožné projití stejného počtu záznamů v indexu. Je to možné?

Možné to je, dokonce se to může dynamicky měnit i v průběhu života jedné tabulky.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 25. 10. 2019, 10:43:04
Citace
Našeptávání je jediná reálná úloha, kdy uživatel pracuje se seznamem štítků.
1) Ano - jak jinak vybruslit z toho, že něco neumíš, než prohlásit, že to není potřeba, že?
2) V minulém mailu jsem asi potřetí zopakoval usecase, na který je potřeba mít seznam všech štítků - ten usecase se reálně používá (mohu doložit). Jaká je Tvá reakce? Aniž bys ten usecase jakkoli rozporoval, tak napíšeš, todle.
Tak nevím - Tvůj mozek automaticky ignoruje to, co se Ti nehodí do krámu a ani jsi to doteď nezaznamenal? Anebo o tom usecase víš, a jen se snažíš prosadit svoje stylem: když to mnohokrát zopakuji, stane se z toho pravda?
Seznam štítků je třeba pravidelně revidovat, protože jinak i v nejgeniálněji napsaném systému dřív nebo pozdějc někdo založí štítky
 "novikny", "novinka" "novynka".... A pokud navrhuješ procesy tak, že se na takovéto chyby, které nutně vznikají v každém systému, dá přijít jen náhodou, a není způsob, jak na ně přijít pravidelnou systémovou revizí dat, tak opět potěš koště. Anebo budeš revidovat štítky tak, že budeš revidovat ty tísíce záznamů štítky používající? To taky potěš koště...

3) Řešili jsme konkrétní zadání. V minulých postech jsi se šíleně čertil, když jsme zadání jen implementovali tak, že to připouštělo jeho změnu. A najednou tady prohlásíš to, že sice v zadání je A, ale to přeci uživatel nepotřebuje, takže já mu napíšu B. Zlobil ses, když jsme přemešleli nad tím, zda není třeba vozit kromě lidí i uhlí. A teď vůbec lidi vozit nebudeš, protože umíš vozit jen uhlí. Fakt Ti to není trapný?

4) I to našeptávání v tvém případě bude pomalé, ať už použiješ např. v Postrgresu BTREE index, nebo na to znásilníš GIN/GIST indexy. Prostě se smiř s tím, že indexy na tento typ úlohy nejsou dělané - PRÁVĚ PROTO, ŽE V DOBŘE NAVRŽENÉ DATABÁZI JSOU NORMALIZOVANÁ DATA A BĚŽNĚ TO NENÍ POTŘEBA.
Citace
Až na to, že spellchecker je něco úplně jiného, než stemmer. Spellchecker je prostý dotaz „existuje toto slovo?“, případně vylepšený o „pokud neexistuje, jaká podobná slova existují?“. Stemmer je nalezení kořene slova.
Opět rádobyzasvěceně hovořít o něčem, co jsi evidentně viděl jen z rychlíku. V realitě jsou spellcheck algoritmy implementovány nikoli pomocí seznamu slov, ale pomocí generativních gramatik. A kupodivu ty gramatiky jsou přesně ty samé, co se používají na stemming, a jde o stejnou úlohu - slovo projde spellcheckerem, pokud lze najít v "gramatice daného jazyka" (hunspell slovníku) kořen.

Samozřejmě, u spellcheckeru je kromě toho ještě user define seznam výjimek, ale to není nic technologicky zajímavého, ten už bude implementován pomocí klasického indexu - a s fulltextem (jak jsi předtím psal) to nesouvisí ani náhodou.

Citace
Když píšete o implementaci nějakého konkrétního databázového enginu, konkrétně ho pojmenujte.
Víš, my nejsme teoretici, co evidentně v DB toho moc nenaprogramovali, a jen mají nějaké povědomí o tom, že by "něco mělo jít". Samozřejmě, počítač je turingovsky úplnej, takže pokud takovej algoritmus umí člověk navrhnout - a to evidentně umí, když jsme Ti už dávno předestřeli řešení, které to umí - jde to zalgoritmizovat. Takže otázka kupodivu není: "je teoreticky možné, aby to databáze uměla", ale "umí to reálné databáze"?

Debata tu není o teoretických možnostech obskurní databáze z alternativní reality, ale o tom, jak se mají navrhovat DB struktury, aby to pokud možno fungovalo v každé DB, anebo alespoň v těch rozumných. A zrovna neakceleraci distinct indexem má jak postgres, tak oracle, tak MSSQL....

Tvoje argumentace, že by to nějaká DB umět mohla. Ano, mohla. A nějaká DB by mohla automaticky dělat vývojářum zmrzlinu. To nic nemění na tom, že to přinejemenším zpravidla neumí a tedy Tvé řešení je antipattern, který by se neměl doporučovat.

Citace
Jenom jestli to ví třeba Google, že vyhledávání slova ve fulltextovém indexu závisí na celkovém počtu dokumentů a ne na počtu různých slov v indexu.
Bavíme se o implementaci v relační databázi. Demonstrovali jsme Ti, že běžnou technikou v postgresu to, co tvrdíš, prostě nejde. Tak jsou dvě možnosti: BUĎTO UKAŽ NA KONKRÉTNÍM ŘEŠENÍ V ROZUMNÉ DATABÁZI, ŽE TO JDE a ukaž nám, jak použít fulltext index na akceleraci výpisu šítků, anebo i jen na to tvoje našeptávání ANEBO PŘESTAŇ ŠÍŘIT BLUDY.
To, že možná někde existuje algoritmus, který by Tvoji strukturu zvládal, je samozřejmě možné. Může Ti databáze dělat zmrzlinu. Až nějakou takovou najdeš, tak nám o ní řekni (i když teď když bude zima bych radši horkou čokoládu).
===

A Btw - ony good practices mají smysl. Uvědom si, kolik by si již při vývoji ztratil času - když sis vymyslel svoje "úžasné řešení", a teď zjišťoval, že ale vlastně B-Tree indexem to nejde indexovat. Takže fulltextem.... hmmmm, takže založíme TSVector sloupec a zkusíme. Nejde, tak ale ono to musí jít, tak jdeme googlovat.... googlím.... googlím, ale ono to přeci MUSÍ jít....

Dobrej junior používá osvědčená řešení. Dobrej senior je schopen použít originální správná řešení, když ty osvědčená se z nějakého důvodu nehodí. Ale junior, který bez znalosti problematiky se vrhá do neprozkoumaných vod (mýdlo, z odpadků, ale skvost) je k nezaplacení (rozumněj, vyjde firmu pěkně draho).
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 25. 10. 2019, 11:15:59
...

Pane kolego, tohle je zbytečná ztráta energie a snad i emocí. Správné postupy i argumenty jsme předložili, několikrát vysvětlili, že nováčkům se mají dávat prozíravé rady. Není účelem přesvědčit Filipa - ostatně se zdá, že je mimo jeho moc diskutovat jinak, než zastávat svoji pravdu. Točit se dokola opakováním opravdu nemá smysl, stejně to beztak kromě nás čtyř nikdo nečte.

Ve Filipových argumentech jsou opravdu veletoče - jinou metrikou hodnotí své argumenty a jinou cizí. Když už je v úzkých napíše něco ve smyslu "měl byste uvést konkrétní databáze" - aniž by sám takto postupoval. Jako příklad dává databázi, na které to jednoznačně nejde, navíc se sloupcem štítků "NOT NULL", ačkoliv později označuje patřičné indexy za "nestandardní implementaci" atd.

Mrzí mě, že z této diskuse si Racchek nemůže nic smysluplného odnést.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 25. 10. 2019, 14:55:27
Takže to má jinak a připouští duplicitu klíče, viz klíč '49'. Jak by z tohoto měl jít udělat distinct jinak, než poctivým traverzováním?
Myslím, že není potřeba diskusi zacyklovat. Už se to tu řešilo.

2) V minulém mailu jsem asi potřetí zopakoval usecase, na který je potřeba mít seznam všech štítků - ten usecase se reálně používá (mohu doložit). Jaká je Tvá reakce? Aniž bys ten usecase jakkoli rozporoval, tak napíšeš, todle.
To je usecase „aplikace něco neumí, je potřeba dát všechna data k dispozici uživateli, aby si to vyřešil v jiné aplikaci nebo ručně“. O tom už jsem psal, jako řešení jsem navrhoval napsat aplikaci, která bude řešit skutečné požadavky uživatele.

Seznam štítků je třeba pravidelně revidovat, protože jinak i v nejgeniálněji napsaném systému dřív nebo pozdějc někdo založí štítky
 "novikny", "novinka" "novynka"....
Výborně, zadání máte, Tak si teď zkuste odpovědět na otázku: Kdo bude lepší v hledání duplicit ve stovkách štítků? Člověk, který bude číst jeden štítek za druhým, nebo počítač, který udělá podobnostní vyhledávání a nabídne uživateli: „Štítky novinky, novikny, novinka a novynka jsou podobné, chcete některé sloučit?“ Mimochodem, když pro přiřazování štítků použijete našeptávač, těchto případů bude existovat minimum, a nejspíš je někdo opraví daleko dřív, než by se k tomu dostal nějaký správce.

Prostě se smiř s tím, že indexy na tento typ úlohy nejsou dělané
Indexy na tento typ úlohy jsou dělané. Např. Lucene (NoSQL databáze pro fulltext) má speciální operátor „vrať mi všechny unikátní hodnoty daného atributu“. Ten operátor opravdu neposkytují proto, že by to byl snadný způsob, jak zatížit databázi. Poskytují ho proto, že je to často požadovaná funkce a je velmi snadné nad používaným indexem to implementovat.

V realitě jsou spellcheck algoritmy implementovány nikoli pomocí seznamu slov, ale pomocí generativních gramatik.
Ano, to je jedna z možných implementací. Ovšem co má společného s indexy? Vůbec nic. Takže jsem logicky psal o té další možné implementaci, kterou ve skutečnosti používá každý spellchecker, minimálně pro uživatelský slovník – o podobnostním vyhledávání v seznamu slov.

Víš, my nejsme teoretici, co evidentně v DB toho moc nenaprogramovali
No, pokud to programujete tak, že uživateli neposkytnete našeptávač štítků, protože ho neumíte udělat, a místo toho nutíte admina, aby se jednou za měsíc vypsal nestránkovaný seznam všech štítků a ručně tam hledal duplicity, pak upřímně lituju uživatele vašich aplikací.

Tvoje argumentace, že by to nějaká DB umět mohla.
Na argument Miroslava Šilhavého „nejde to“ je to validní protiargument. Pokud mi někdo bude argumentovat tím, že našeptávání štítků v aplikaci neudělá, protože to jeho databáze neumí, budu hledat jiný nástroj, který to umí. V tomto případě to dokonce bude ještě jednodušší, stačí dotyčnému vysvětlit, že ty databáze to umí, akorát musí použít správný typ indexu.

A Btw - ony good practices mají smysl. Uvědom si, kolik by si již při vývoji ztratil času - když sis vymyslel svoje "úžasné řešení", a teď zjišťoval, že ale vlastně B-Tree indexem to nejde indexovat.
Já jsem to nenavrhoval jako úžasné řešení, napsal jsem to jako příklad, který někdy může dávat smysl. Nepsal jsem nic takového, že to většinou bude nejlepší řešení, že to je best practice pro implementaci štítků, nic takového. Dostali jsem se k tomu v debatě o tom, jestli má JOIN popisovat strukturu získávaných dat, nebo jestli má kopírovat strukturu tabulek. Jenže místo abyste se drželi tématu debaty, tohle byla vítaná záminka jak odvést debatu jinam.

Mimochodem, s použitím B-Tree indexu pro indexování štítků jsem nepřišel já, ale vy. Já jsem jenom ukázal, že i ten B-Tree index pomůže i v té hloupé implementaci, kdy chcete seznam všech štítků, pokud ten seznam budete alespoň stránkovat. Ale vy trváte na tom, že když už uživatel musí používat vaši hloupou aplikaci, ať si to vyžere až do dna.

BUĎTO UKAŽ NA KONKRÉTNÍM ŘEŠENÍ V ROZUMNÉ DATABÁZI, ŽE TO JDE a ukaž nám, jak použít fulltext index na akceleraci výpisu šítků, anebo i jen na to tvoje našeptávání ANEBO PŘESTAŇ ŠÍŘIT BLUDY.
Nevím, jestli pořád ještě trváte na relační databázi. Tip pro to, jak vytvořit našeptávač se Solr (nadstavba nad Lucene) najdete třeba zde (https://lucene.apache.org/solr/guide/8_2/suggester.html#suggester). Relační databáze jsou ve vyhledávání textu tradičně slabší, ale dnes už většinou mají použitelné fulltextové indexy, které se na to dají použít. Zvlášť když štítků nejspíš budou stovky a ne desítky milionů.

Dobrej junior používá osvědčená řešení. Dobrej senior je schopen použít originální správná řešení, když ty osvědčená se z nějakého důvodu nehodí. Ale junior, který bez znalosti problematiky se vrhá do neprozkoumaných vod (mýdlo, z odpadků, ale skvost) je k nezaplacení (rozumněj, vyjde firmu pěkně draho).
Jenže v této diskusi je jiný problém. Že se někdo tváří jako expert, ale juniorovi doporučuje velmi nestandardní řešení – např. INNER JOIN psát pomocí OUTER JOINu + spojovací podmínky do WHERE (kterou navíc napíše špatně). Nebo se jako úplně normální prezentuje vypsat uživateli nestránkovaný seznam všech štítků, ať si v nich hledá duplicity očima.

Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 25. 10. 2019, 15:09:21
Víš, my nejsme teoretici, co evidentně v DB toho moc nenaprogramovali
No, pokud to programujete tak, že uživateli neposkytnete našeptávač štítků, protože ho neumíte udělat, a místo toho nutíte admina, aby se jednou za měsíc vypsal nestránkovaný seznam všech štítků a ručně tam hledal duplicity, pak upřímně lituju uživatele vašich aplikací.

My ale umíme udělat našeptávač štítků. Jen k tomu nepoužíváme indexy do obřích tabulek, protože víme, že by to bylo zoufale neefektivní a uživatel by mezitím mohl usnout.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 25. 10. 2019, 16:53:44
Jenže v této diskusi je jiný problém. Že se někdo tváří jako expert, ale juniorovi doporučuje velmi nestandardní řešení – např. INNER JOIN psát pomocí OUTER JOINu + spojovací podmínky do WHERE (kterou navíc napíše špatně). Nebo se jako úplně normální prezentuje vypsat uživateli nestránkovaný seznam všech štítků, ať si v nich hledá duplicity očima.

INNER JOIN už Vám byl vyvrácen vícekrát, nemá smysl se k němu vracet.

Štítky pomocí DISTINCT nad velkou tabulí jsou blbina. Tímto vzorem zrychlíte zápis a update štítku na záznamu (což jsou operace méně používané), ale zpomalíte jakékoliv dohledání (což je častější operace).
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 25. 10. 2019, 19:12:09
My ale umíme udělat našeptávač štítků. Jen k tomu nepoužíváme indexy do obřích tabulek, protože víme, že by to bylo zoufale neefektivní a uživatel by mezitím mohl usnout.
Google má vyhledávač a má v něm i našeptávač. Buď je to zoufale neefektivní a uživatelé u toho usínají, nebo nemá zaindexováno moc dokumentů, nebo používá nějakou jinou zázračnou metodu, než indexy. A nebo neplatí váš předpoklad efektivita správného indexu pro fulltextové vyhledávání není tolik citlivá na počet zaindexovaných dokumentů/záznamů.

INNER JOIN už Vám byl vyvrácen vícekrát, nemá smysl se k němu vracet.
OUTER JOIN už vám byl vyvrácen vícekrát, nemá smysl se k němu vracet.

Jinak celá ta debata kolem nadřízených a štítků vznikla tím, že jste měl uvést příklad, kdy je podle vás správné použít INNER JOIN – a jaké je to pravidlo pro použití. Zatím jste neuvedl nic, takže to zatím vypadá, že se autoři SQL standardu zbláznili a jako default vybrali něco, co nemá žádné rozumné použití.

Štítky pomocí DISTINCT nad velkou tabulí jsou blbina. Tímto vzorem zrychlíte zápis a update štítku na záznamu (což jsou operace méně používané), ale zpomalíte jakékoliv dohledání (což je častější operace).
O velké tabulce píšete vy. Jakékoli dohledání tím nezpomalím, právě naopak – dohledání „které záznamy mají tento štítek“ se tím mírně zrychlí, protože se půjde přes jeden index a ne přes dva. Dokonce pokud budu chtít vypsat třeba jen názvy těch záznamů, a bude to fakt častá operace, můžu je přidat do toho indexu a nemusí se pak číst ani ta tabulka.

Řazený stránkovaný výpis všech štítků by byl lehce neefektivní, ale žádná tragédie (pokud by k jednomu štítku nepříslušely tisíce záznamů).

Jinak pokud by mi někdo dal obecné zadání „štítky k entitám“, nic víc bych o tom nevěděl, tak bych samozřejmě také volil tabulku se seznamem štítků a M:N tabulky mezi entitami a štítky. Ale nemám tak málo zkušeností, abych tvrdil, že je to nejlepší řešení absolutně vždy ve všech případech. A hlavně to neobhajuju nesmysly typu „často bude potřeba uživateli vypsat nestránkovaně seznam všech štítků“. Použil bych to řešení proto, že je implementačně nejjednodušší a je tradiční. Nějaké optimalizace toho jednoduchého řešení má smysl řešit teprve tehdy, až se ukáže, že současné řešení nedostačuje. Přičemž příkladem takové optimalizace (u štítků opravdu jen teoreticky) může být právě denormalizace a uvedení štítků přímo u záznamů (což by byl problém u vícenásobných štítků, pak by bylo nutné to řešit buď polem nebo další tabulkou), která umožní snížení počtu použitých indexů. Při hledání pouze přes štítky by úspora byla minimální, ale kdybyste chtěl kombinovat hledání „dej mi všechny záznamy, které mají štítek X, patří do kategorie Y a vytvořil je uživatel Z“, může už být podstatný rozdíl, jestli databázi donutíte slévat desítky tisíc záznamů ze tří indexů, aby tam našla průnik pěti záznamů, nebo zda těch pět záznamů najde přímo v indexu. Samozřejmě to zase závisí na tom, jaké typy dotazů uživatelé používají – pokud bude kombinací podmínek 60, asi nebudete chtít mít 40 indexů, abyste pokryl všechny varianty dotazů.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 25. 10. 2019, 20:19:53
My ale umíme udělat našeptávač štítků. Jen k tomu nepoužíváme indexy do obřích tabulek, protože víme, že by to bylo zoufale neefektivní a uživatel by mezitím mohl usnout.
Google má vyhledávač a má v něm i našeptávač. Buď je to zoufale neefektivní a uživatelé u toho usínají, nebo nemá zaindexováno moc dokumentů, nebo používá nějakou jinou zázračnou metodu, než indexy. A nebo neplatí váš předpoklad efektivita správného indexu pro fulltextové vyhledávání není tolik citlivá na počet zaindexovaných dokumentů/záznamů.

Pomiňme, že Google pro tento účel nepoužívá SQL, ale vlastní databázi Big Table.

Jenže i v SQL tohle umíme. Stačí jen tu databázi normalizovat. Tabulka se nám rozpadne na tři tabulky a ejhle, najednou našeptávač neprochází milióny záznamů se štítky, ale jen stovky. Navíc je tabulka se štítky velmi úzká a tedy i rychlá. Samozřejmě má i svůj index.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 26. 10. 2019, 13:06:28
Výborně, zadání máte, Tak si teď zkuste odpovědět na otázku: Kdo bude lepší v hledání duplicit ve stovkách štítků?
Člověk, protože počítač neodhalí např. duplicitu novinka versus news. Nebo nedovede vyřešit to, že když je štítků moc různých a je třeba sjednotit (např. zahrnout auto a autobus pod jeden štítek dopravní prostředek), nebo nějak lépe strukturovat.  Samozřejmě, taková revize jde dělat jen do určitého počtu štítků. Ale to, že těch štítků bude více, to je jen Tvoje utkvělá představa, ke které ses upnul, aby si nemusel přiznat, že je toto v některých případech validní usecase. Je mnoho oblastí, kde je reálně používý počet štítků řádově desítky (ač štítkovaných třeba stovky tisíc), a tam je takové review otázkou pár minut.

V každém případě, zadání nebylo odstranit duplicitu štítků. Od začátku jsme se tady bavili o seznamu štítků a jak ho udělat. Teprv, když jste zjistil, že to neumíte, tak hledáte, jak se z toho vykecat a vymyslel jste si, že vlastně místo seznamu štítků budete dělat našeptávač.Vozit uhlí a ne lidi.

Citace
Mimochodem, když pro přiřazování štítků použijete našeptávač, těchto případů bude existovat minimum, a nejspíš je někdo opraví daleko dřív, než by se k tomu dostal nějaký správce.
Na to se dá říci jen to, že jste evidentně nikdy žádnou reálnou databázi vyplňovanou uživateli nespravoval.
Citace
Indexy na tento typ úlohy jsou dělané. Např. Lucene (NoSQL databáze pro fulltext)
Ano, v NOSQL databázích, kde člověk nemá možnost vytvářet normalizované datové struktury, to je třeba řešit a ty databáze to zpravidla umějí. V SQL databázích se to řeší normalizací a tedy tam zpravidla tato funkcionalita implementovaná není. My jsme se ovšem jaksi bavili o implementaci v SQL databázi. Vždyť jsem psal, pokud neumíte SQL, tak radši používejte NoSQL databáze. Pak ale neraďte lidem, jak implementovat strukturu v SQL databázi.
Citace
Ano, to je jedna z možných implementací. Ovšem co má společného s indexy? Vůbec nic.
No právě, pleteš sem úplně nesouvisející věci.
Citace
Takže jsem logicky psal o té další možné implementaci
Ano, pořád dokolečka si vymýšlíte, jak by něco implementováno být MOHLO, protože nevíte, jak věci implementované JSOU. Pro spellchecking je hunspell algoritmus nepsaný standard (obzvlášť v jednodušších implementacích fulltextu, o kterých jste mluvil) a tedy pokud bez dalšího mluvíte o spellchekingu, tak každý, kdo o věci něco ví, bude předpokládat, že mluvíte o tomto algoritmu.
Zadruhé si pletete spellchecking a "suggestions", česky našeptávání. Spellcheck je kontrola vůči slovníku, našeptávání je napovídání nejlepšího známého inputu k zadané frázi. Takže vlastně tady tvrdíte, že se našeptávání implementuje pomocí našeptávání. Hezká tautologie.
Citace
kterou ve skutečnosti používá každý spellchecker, minimálně pro uživatelský slovník
Zaprve, vzhledem k tomu, že je třeba nají možné korekce nejen vůči uživatelskému slovníku, ale také vůči sytémovému. Pokud je systémový implementován pomocí hunspellu, tak podobnostní hledání není možné úplně možné. Někdy se používá, pak ale je výsledek zkreslen, protože se hledá nestemované slovo vůči stemovanému indexu. Přesnější algoritmus je ovšem vygenerovaný seznam kandidátů a kontrola vůči spellchecku. Viz např. https://norvig.com/spell-correct.html
Tedy Vaše tvrzení, že spellchecker je podobnostní hledání, je prostě nesmysl - představujete si tudle problematiku jak Hurvínek válku a myslíte si, že když řeknete spellchecker, že si každý vybaví zrovna ten stejný algoritmus, který máte na mysli Vy. Ve skutečnosti myslíte jeden z X algoritmů na řešení něčeho jiného.

A za druhé, když už se používá podobnostní vyhledávání, tak ve smyslu metriky blízkosti slov, např. Levenshteinova distance (v lepších případech s přihlédnutím k možnosti fonetické záměny), a na akceleraci čehož se trigram indexy (jak v SQL databázích (pg_trgm), tak nosql fulltextech https://community.oracle.com/docs/DOC-983151 (https://community.oracle.com/docs/DOC-983151)), které ani náhodou nemají schopnost akcelerovat operaci distinct - takže ani tato technologie, o které tu celou dobu mylně prohlašujete, že je to základní algoritmus spellcheckeru, Vám k implementaci Vašeho vysněného indexu pro DISTINCT prostě nepomůže. Mícháte páté přes deváté.

Citace
No, pokud to programujete tak, že uživateli neposkytnete našeptávač štítků:
Todle už je hodně laciná snaha se z toho vykecat, že jo? Já na tvým místě bych se za takto chabej pokus styděl....
Nikde jsem neřekl, že štítky nebudu našeptávat, to jen takovej nesmysl se nám snažíš vložit do úst, abys nemusel uznat omyl. To, co tvrdíme, je:
a) jsou usecase i pro seznam štítků, a tvůj db model se pro tento usecase prostě nehodí, protože je pomalý a indexy neodstraní principiální problém této struktury
b) Tvůj DB model se nehodí ani pro implementaci našeptávání v SQL databázi, protože i tam narazíš na stejný problém.

Citace
Pokud mi někdo bude argumentovat tím, že našeptávání štítků v aplikaci neudělá, protože to jeho databáze neumí,
Zase lžete. Víš, proč s Tebou ještě diskutuji? Zajímá mě, jaké lži ještě dokážete vyplodit, abyste nemusel uznat omyl a Tvoje vykrucování mě baví. Sorry, že Ti to říkám tak narovinu, ale třeba Tě to přinutí se nad sebou zamyslet.

Nikdo tady netvrdil, že to db neumí, nebo že nebude dělat našeptávání. Tvrdíme, že TEBOU NAVRŽENÁ DB STRUKTURA je jak na výpis štítků, tak na našeptávání NEVHODNÁ, a že se to v databázích dělá jinak.

Citace
budu hledat jiný nástroj, který to umí..... nevím, jestli pořád ještě trváte na relační databázi....Tip pro to, jak vytvořit našeptávač se Solr 
Jééééééé. Takže místo toho, abys s minimem práce udělal rozumnou db strukturu použitelnou jak k adminu štítků, tak pro implementaci našeptávání, radši nainstaluješ další software, budeš řešit synchronizaci dat a atomicitu transakcí atd... atd... Z práce na pár hodin uděláš práci na měsíc....Je fakt zábavné pozorovat, čeho všeho jsou lidi schopní, aby nemuseli uznat omyl.

Citace
Já jsem jenom ukázal, že i ten B-Tree index pomůže i v té hloupé implementaci, kdy chcete seznam všech štítků, pokud ten seznam budete alespoň stránkovat.
Jééééé, ty jsi snad fakt doteď nepochopil, v čem je problém. Teda, čekal jsem hodně věcí, ale todle ne. Znovu: B-Tree index - přinejmenším jeho standardní implementace v běžných databázích - Ti nepomůže proti sekvenčnímu scanu všech štítkovaných (ať už v primárním datovém souboru, nebo indexu, problém je to stejný), ať už budeš stránkovat nebo ne. Zkus si několikrát znovu přečíst předchozí odpovědi týkající se tohoto, třeba Ti to konečně docvakne.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 26. 10. 2019, 15:02:02
Člověk, protože počítač neodhalí např. duplicitu novinka versus news. Nebo nedovede vyřešit to, že když je štítků moc různých a je třeba sjednotit (např. zahrnout auto a autobus pod jeden štítek dopravní prostředek), nebo nějak lépe strukturovat.  Samozřejmě, taková revize jde dělat jen do určitého počtu štítků.
Přesněji řečeno do počtu štítků, které je člověk schopen si najednou zapamatovat. A s takovým počtem štítků zase databáze nebude mít problém, i když bude muset tabulku načíst fullscanem (protože s tak malým množstvím štítků nebude moc ani oštítkovaných entit).

Ale to, že těch štítků bude více, to je jen Tvoje utkvělá představa, ke které ses upnul, aby si nemusel přiznat, že je toto v některých případech validní usecase.
Bavili jsme se totiž o optimalizaci výpisu. Pokud je záznamů pár, není nutné pro takovéhle specifické použití dělat nějakou optimalizaci. Holt si ten administrátor jednou za měsíc deset sekund počká – to ruční třídění štítků mu pak zabere řádově víc času.

V každém případě, zadání nebylo odstranit duplicitu štítků. Od začátku jsme se tady bavili o seznamu štítků a jak ho udělat. Teprv, když jste zjistil, že to neumíte, tak hledáte, jak se z toho vykecat a vymyslel jste si, že vlastně místo seznamu štítků budete dělat našeptávač.Vozit uhlí a ne lidi.
Ale já to umím. Já jsem jenom reagoval na váš use case, kdy už je záznamů tolik, že to bez indexu nezvládne ani databáze, natož člověk.

Ano, v NOSQL databázích, kde člověk nemá možnost vytvářet normalizované datové struktury, to je třeba řešit a ty databáze to zpravidla umějí. V SQL databázích se to řeší normalizací a tedy tam zpravidla tato funkcionalita implementovaná není.
Našeptávač štítků a normalizace databáze spolu vůbec nijak nesouvisejí.

No právě, pleteš sem úplně nesouvisející věci.
S hunspellem jste přišel vy, ne já.

Pro spellchecking je hunspell algoritmus nepsaný standard (obzvlášť v jednodušších implementacích fulltextu, o kterých jste mluvil) a tedy pokud bez dalšího mluvíte o spellchekingu, tak každý, kdo o věci něco ví, bude předpokládat, že mluvíte o tomto algoritmu.
Chvíli píšete o spellcheckeru hunspell, chvíli zaměňujete fulltext a spellchek (takže to nemůže být hunspell). Gratuluju, teď jste konečně ty dvě různé implementace nacpal do jedné věty, takže nesmyslnost vašich tvrzení o to více vynikla.

Zadruhé si pletete spellchecking a "suggestions", česky našeptávání.
Spellchecker má za úkol na základě vstupu najít možná podobná slova ze slovníku existujících slov. Našeptávač má za úkol na základě vstupu najít možné podobná slova nebo jejich části ze slovníku, nad kterým se našeptává. Spellchecker tedy může být implementován jako speciální varianta našeptávače.

A za druhé, když už se používá podobnostní vyhledávání, tak ve smyslu metriky blízkosti slov, např. Levenshteinova distance (v lepších případech s přihlédnutím k možnosti fonetické záměny), a na akceleraci čehož se trigram indexy (jak v SQL databázích (pg_trgm), tak nosql fulltextech https://community.oracle.com/docs/DOC-983151 (https://community.oracle.com/docs/DOC-983151)), které ani náhodou nemají schopnost akcelerovat operaci distinct - takže ani tato technologie, o které tu celou dobu mylně prohlašujete, že je to základní algoritmus spellcheckeru, Vám k implementaci Vašeho vysněného indexu pro DISTINCT prostě nepomůže. Mícháte páté přes deváté.
Výborně, takže už jste si dostudoval základy toho, o čem se chcete bavit. Teď už si to jenom správně spárujte – o fulltextech a trigram indexech byla řeč v souvislosti s našeptávačem.


a) jsou usecase i pro seznam štítků, a tvůj db model se pro tento usecase prostě nehodí, protože je pomalý a indexy neodstraní principiální problém této struktury
Zapomněl jste dodat, že jde o use case, kde je štítků i záznamů málo a příslušný use case se používá jen občas. Takže to, že je „pomalý“, nemusí vadit.

b) Tvůj DB model se nehodí ani pro implementaci našeptávání v SQL databázi, protože i tam narazíš na stejný problém.
Vždyť už jste konečně zjistil, že i v relačních databázích existují fulltextové indexy. To už jste to zase zapomněl?

Zase lžete. Víš, proč s Tebou ještě diskutuji? Zajímá mě, jaké lži ještě dokážete vyplodit, abyste nemusel uznat omyl a Tvoje vykrucování mě baví. Sorry, že Ti to říkám tak narovinu, ale třeba Tě to přinutí se nad sebou zamyslet.
Pouze jsem se přizpůsobil vašemu stylu.

Nikdo tady netvrdil, že to db neumí, nebo že nebude dělat našeptávání. Tvrdíme, že TEBOU NAVRŽENÁ DB STRUKTURA je jak na výpis štítků, tak na našeptávání NEVHODNÁ, a že se to v databázích dělá jinak.
O dvě citace výš jste psal, že při implementaci našeptávání v SQL databázi narazíte na problém. Teď zase tvrdíte, že to žádný problém není. Tak která varianta platí?

Ano, navržená struktura není vhodná pro výpis všech štítků, pokud bude entit větší množství. Jenže já jsem nikde nepsal, že je ta struktura vhodná na všechny případy použití. Ten váš příklad, kdy je potřeba vypisovat větší množství štítků najednou, přece také není vhodný pro všechny případy použití. Tak já nemohu psát o speciálních případech a vy ano?

Jééééééé. Takže místo toho, abys s minimem práce udělal rozumnou db strukturu použitelnou jak k adminu štítků, tak pro implementaci našeptávání, radši nainstaluješ další software, budeš řešit synchronizaci dat a atomicitu transakcí atd... atd... Z práce na pár hodin uděláš práci na měsíc....Je fakt zábavné pozorovat, čeho všeho jsou lidi schopní, aby nemuseli uznat omyl.
Zase lžete. Víš, proč s Tebou ještě diskutuji? Zajímá mě, jaké lži ještě dokážete vyplodit, abyste nemusel uznat omyl a Tvoje vykrucování mě baví. Sorry, že Ti to říkám tak narovinu, ale třeba Tě to přinutí se nad sebou zamyslet.

Jééééé, ty jsi snad fakt doteď nepochopil, v čem je problém. Teda, čekal jsem hodně věcí, ale todle ne. Znovu: B-Tree index - přinejmenším jeho standardní implementace v běžných databázích - Ti nepomůže proti sekvenčnímu scanu všech štítkovaných (ať už v primárním datovém souboru, nebo indexu, problém je to stejný), ať už budeš stránkovat nebo ne. Zkus si několikrát znovu přečíst předchozí odpovědi týkající se tohoto, třeba Ti to konečně docvakne.
Při řazeném stránkovaném výpisu B-Tree index pomůže, protože databáze pojede po tom indexu a bude počítat, kolik má unikátních záznamů, a až jich napočítá dost, tak skončí. Když nebude mít ten index, musí načíst všechny záznamy z tabulky, jejich hodnoty seřadit – a pak může konečně začít dělat to, co před tím dělala nad indexem. Když těch štítků bude málo, takže nepotřebujete stránkovat, bude to podobné, akorát je podle indexu vypíše všechny. To, k čemu tam ten index je, je to řazení záznamů – odpadne ta potřeba vše načíst a seřadit až v okamžiku dotazu, protože už je to uložené v tom indexu.

Už jste pochopil, v čem je problém?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 26. 10. 2019, 15:04:30
Pomiňme, že Google pro tento účel nepoužívá SQL, ale vlastní databázi Big Table.

Jenže i v SQL tohle umíme. Stačí jen tu databázi normalizovat. Tabulka se nám rozpadne na tři tabulky a ejhle, najednou našeptávač neprochází milióny záznamů se štítky, ale jen stovky. Navíc je tabulka se štítky velmi úzká a tedy i rychlá. Samozřejmě má i svůj index.
Jenže tady vůbec nejde o databázi, ale o index. Našeptávač opravdu nemůže dělat fullscan tabulky, ani malé. Našeptávač musí vždy pracovat nad indexem. Teda pokud budete našeptávat z deseti hodnot, nemusíte to vůbec řešit v databázi a vyřešíte to na klientovi, ale o takovém případu se snad nebavíme.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 26. 10. 2019, 15:10:09
Citace
O velké tabulce píšete vy. Jakékoli dohledání tím nezpomalím, právě naopak – dohledání „které záznamy mají tento štítek“ se tím mírně zrychlí, protože se půjde přes jeden index a ne přes dva.
Tady se opět mýlíš. Protože dohledání bude sice přes dva indexy, ale jejichž souhrnná velikost a tedy i hloubka bude plus mínus podobná tomu jednomu indexu, velikost a rychlost dohledání samotného štítku bude oproti dohledání těch záznamů zanedbatelná úloha. Ovšem paměťová náročnost bude podstatně větší, protože ten ohromnej "denormalizaovanej index" bude jinak k ničemu, zatímco v druhém případě se použije malinký index přes štítky plus primární klíč.
Ve výsledku tedy vzhledem k hierarchickému paměťovému systému bude na rozumně zatížené databázi řešení s dvěma indexy zpravidla rychlejší, protože se nebude muset sahat pro řídčeji používaný index do pomalejších pamětí (anebo ten index naopak z těch pamětí nevytěsní jiná data, což zpomalí ostatní dotazy).

Citace
Při hledání pouze přes štítky by úspora byla minimální, ale kdybyste chtěl kombinovat hledání „dej mi všechny záznamy, které mají štítek X, patří do kategorie Y a vytvořil je uživatel Z“
Pokud je potřeba akcelerovat takovéto dotazy, pak opravdu může být denormalizace rozumná. Ovšem to už je jednak velmi speciální obor, něco, co by se rozhodně nemělo radit na webových fórech. Kdybys na začátku řekl - ano, todle je denormalizovaná struktura, která ale ve speciálních případech může mít smysl, tak by vypadala diskuse jinak. Tys to ale od začátku razil jako normální běžný přístup, a teprv teď, když vidíš, že je to neudržitelné, si najednou vytáhl denormalizaci (btw. na začátku diskuse si vůbec popíral, že Tvé řešení je denormalizace) jako úhybný manévr.

Zadruhé, běžná praxe je takováto denormalizovaná data pro účely rychlejšího přístupu držet nikoli jako primární data, ale jako "precomputed data" udržovaná triggery z původní normalizované datové struktury. Viz např.https://rubygarage.org/blog/database-denormalization-with-exampleshttp://www.ovaistariq.net/199/databases-normalization-or-denormalization-which-is-the-better-technique/takže i tak ten úhybný manévr se příliš nepovedl....

Citace
Jenže tady vůbec nejde o databázi, ale o index. Našeptávač opravdu nemůže dělat fullscan tabulky, ani malé. Našeptávač musí vždy pracovat nad indexem. Teda pokud budete našeptávat z deseti hodnot,
A kolikrát Ti budeme muset zopakovat, že INDEXY V SQL DATABÁZI PROSTĚ NEJSOU (zpravidla) NAPSANÉ TAK, ABY "ELIMINOVALI DUPLICITY", TAKŽE VE VÝSLEDKU PŮJDE I PŘI POUŽITÍ INDEXU O "SEQUENTIAL SCAN" PŘES TY DUPLICITY, než Ti to dojde? 
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 26. 10. 2019, 15:30:55
Když nebude mít ten index, musí načíst všechny záznamy z tabulky, jejich hodnoty seřadit – a pak může konečně začít dělat to, co před tím dělala nad indexem. Když těch štítků bude málo, takže nepotřebujete stránkovat, bude to podobné, akorát je podle indexu vypíše všechny. To, k čemu tam ten index je, je to řazení záznamů – odpadne ta potřeba vše načíst a seřadit až v okamžiku dotazu, protože už je to uložené v tom indexu.

Takhle se to skutečně nedělá. Záznamy se sekvenčně sypou do datové struktury, ve které je text štítku klíčem. Duplicita je rozpoznána ihned při vložení klíče. Žádné následné řazení ani selekce se nekoná, jen se ta struktura vyleje na výstup.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 26. 10. 2019, 15:41:12
Citace
(protože s tak malým množstvím štítků nebude moc ani oštítkovaných entit).
To byste se divil, kolikrát je malé množství štítků a velké množství oštítkovaných entit. V případě, že se nejdená o štíky soukromé pro každého uživatele, tak je to spíše pravidlem: oni jaksi zpravidla štítky ztrácejí smysl, když jich je moc.... Tvůj předpoklad, že když je málo štítků, tak je vždy málo entit, je nesmysl, a tím padá i Tvoje argumentace.

Citace
Našeptávač štítků a normalizace databáze spolu vůbec nijak nesouvisejí.
Souvisejí, akorát to nevíš, a to tak, že fulltext nad denormalizovanými štítky bude v SQL databázi zpravidla pomalý.


Citace
S hunspellem jste přišel vy, ne já.
Slovo spellchecker jsi poprve použil v diskusi ty. A standardní implementace spellcheckru je hunspell algoritmus. Tedy toto téma jsi do diskuse zatáhl Ty - akorát, jak se ukazuje, ani nevíš, co to vlastně je.

Citace
Spellchecker má za úkol na základě vstupu najít možná podobná slova ze slovníku existujících slov.
Omyl. Spellchecker má za úkol zjistit, zdali je dané slovo součástí dané gramatiky. Ať už dané výčtem, nebo, což je daleko častější, generativní gramatikou. Umíš vůbec anglicky. Víš, co znamená to "check" v tom "spellchecker"?
Nabídka korekce není nic jiného než našeptávání, a je to jiná úloha, než spellchecker, byť s ním souvisí.

Citace
chvíli zaměňujete fulltext a spellchek
Ufff. Spellchecker a fulltext jsi právě zaměnil Ty, když jsi psal, že na to použiješ fulltext index, a když jsem se začal ptát, jak je použiješ, tak jsi začal že přeci tak, jak je to použito v každém spellcheckru.....

Citace
Vždyť už jste konečně zjistil, že i v relačních databázích existují fulltextové indexy. To už jste to zase zapomněl?
Ne, akorát Ty jsi zapomněl, že jsem Ti už několikrát napsal, že i fulltextové indexy v SQL databázích trpí stejným problémem. Tedy že vyhledání i malého počtu štítků ve velkém počtu záznamů pomocí fulltextového indexu není tak rychlé, jako vyhledání téhož v normalizované datové struktuře.
Už jsem Tě několikrát vyzýval, abys - pokud s tím nesouhlasíš, ukázal jak k takovému účelu fulltext použiješ. Vždy jsi to nějak zakecal nesmyslama o spellchekrech apod. Tak tě vyzývám znovu: pokud tvrdíš, že Ti fulltext index pomůže, ukaž praktickou implementaci.

Citace
O dvě citace výš jste psal, že při implementaci našeptávání v SQL databázi narazíte na problém. Teď zase tvrdíte, že to žádný problém není. Tak která varianta platí?
Máš evidentně problém pochopit psaný text. V Tvé databázové struktuře to problém je. V normalizované struktuře to problém není.

Citace
Při řazeném stránkovaném výpisu B-Tree index pomůže, protože databáze pojede po tom indexu a bude počítat, kolik má unikátních záznamů, a až jich napočítá dost, tak skončí.
Ano, index pomůže v řazení. Nepomůže v tom, že bude muset projít všechny záznamy indexu pro daný štítek, což může být číslo značně větší, než počet štítků. Tedy neodstraní principiální problém, že náročnost té operace nebude záviset na počtu štítků, ale počtu oštítkovaných. O tomto problému Vašeho návrhu celou dobu mluvím a psal jsem to už asi dvacet postů dozadu.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Kit 26. 10. 2019, 15:47:39
Pomiňme, že Google pro tento účel nepoužívá SQL, ale vlastní databázi Big Table.

Jenže i v SQL tohle umíme. Stačí jen tu databázi normalizovat. Tabulka se nám rozpadne na tři tabulky a ejhle, najednou našeptávač neprochází milióny záznamů se štítky, ale jen stovky. Navíc je tabulka se štítky velmi úzká a tedy i rychlá. Samozřejmě má i svůj index.
Jenže tady vůbec nejde o databázi, ale o index. Našeptávač opravdu nemůže dělat fullscan tabulky, ani malé. Našeptávač musí vždy pracovat nad indexem. Teda pokud budete našeptávat z deseti hodnot, nemusíte to vůbec řešit v databázi a vyřešíte to na klientovi, ale o takovém případu se snad nebavíme.

Fullscan tabulky do tisíce záznamů je rychlejší, než použití indexu. Index pro více záznamů má význam až při selekci, tedy výběru podmnožiny, např. klauzulí WHERE, která vybere méně než cca 10-50 % záznamů.

Distinct je proveden teprve z této podmnožiny.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 26. 10. 2019, 16:25:50
Tady se opět mýlíš. Protože dohledání bude sice přes dva indexy, ale jejichž souhrnná velikost a tedy i hloubka bude plus mínus podobná tomu jednomu indexu, velikost a rychlost dohledání samotného štítku bude oproti dohledání těch záznamů zanedbatelná úloha. Ovšem paměťová náročnost bude podstatně větší, protože ten ohromnej "denormalizaovanej index" bude jinak k ničemu, zatímco v druhém případě se použije malinký index přes štítky plus primární klíč.
Ve výsledku tedy vzhledem k hierarchickému paměťovému systému bude na rozumně zatížené databázi řešení s dvěma indexy zpravidla rychlejší, protože se nebude muset sahat pro řídčeji používaný index do pomalejších pamětí (anebo ten index naopak z těch pamětí nevytěsní jiná data, což zpomalí ostatní dotazy).
To ale popisujete případ 1 entita = 1 štítek. Když použijete vazební tabulku mezi tabulkou entit a tabulkou štítků, abyste u jedné entity mohl mít více štítků, bude index nad touhle tabulkou ještě méně používaný, než index nad seznamem štítků. Na počet odkazovaných záznamů ale ten index bude stejně velký, jako ten „ohromný denormalizovaný index“.

Tys to ale od začátku razil jako normální běžný přístup
Ne, já jsem to na začátku uvedl jako příklad. „Takhle také někdy může vypadat struktura databáze, jak tam budete aplikovat vaše pravidla.“ A vůbec tam nešlo o žádné vyhledávání ani výpis všech štítků. Nemůžu za to, že jsou tu lidé, kteří neumí uznat chybu, tak se radši chytí něčeho nesouvisejícího a začnou se točit na tom.

A kolikrát Ti budeme muset zopakovat, že INDEXY V SQL DATABÁZI PROSTĚ NEJSOU (zpravidla) NAPSANÉ TAK, ABY "ELIMINOVALI DUPLICITY", TAKŽE VE VÝSLEDKU PŮJDE I PŘI POUŽITÍ INDEXU O "SEQUENTIAL SCAN" PŘES TY DUPLICITY, než Ti to dojde?
On vás někdo nutí, abyste to psal k naprosto nesouvisejícím komentářům? Bylo snad v mém textu, nebo v komentáři Kita, na který jsem reagoval, něco o duplicitách?

Slovo spellchecker jsi poprve použil v diskusi ty. A standardní implementace spellcheckru je hunspell algoritmus. Tedy toto téma jsi do diskuse zatáhl Ty - akorát, jak se ukazuje, ani nevíš, co to vlastně je.
Nikoli, já jsem o hunspellu nic nepsal. Psal jsem o spellcheckeru v souvislosti s našeptávačem a fulltextem.

Omyl. Spellchecker má za úkol zjistit, zdali je dané slovo součástí dané gramatiky. Ať už dané výčtem, nebo, což je daleko častější, generativní gramatikou. Umíš vůbec anglicky. Víš, co znamená to "check" v tom "spellchecker"?
Nabídka korekce není nic jiného než našeptávání, a je to jiná úloha, než spellchecker, byť s ním souvisí.
Omyl. „Check“ znamená kontrola – přičemž obě naše tvrzení popisují kontrolu. Problém bude v té druhé části, v tom „spell“. Jde o to, jestli to slovíčko znamená spíš „gramatika“ nebo spíš „hláskování“. Nabídka korekce je standardní součástí funkce spellcheckeru, bez ní by byl velmi uživatelsky nepřívětivý.

Už jsem Tě několikrát vyzýval, abys - pokud s tím nesouhlasíš, ukázal jak k takovému účelu fulltext použiješ. Vždy jsi to nějak zakecal nesmyslama o spellchekrech apod. Tak tě vyzývám znovu: pokud tvrdíš, že Ti fulltext index pomůže, ukaž praktickou implementaci.
PostgreSQL:
Kód: [Vybrat]
CREATE INDEX idx_stitky ON stitky USING GIN (to_tsvector('english', stitek);
SELECT *, ts_rank_cd(to_tsvector('english', stitek), query) AS rank
  FROM stitky, plainto_tsquery(…) query
  WHERE to_tsvector('english', stitek) @@ query
  ORDER BY rank DESC
  LIMIT 10;

Ano, index pomůže v řazení. Nepomůže v tom, že bude muset projít všechny záznamy indexu pro daný štítek, což může být číslo značně větší, než počet štítků. Tedy neodstraní principiální problém, že náročnost té operace nebude záviset na počtu štítků, ale počtu oštítkovaných. O tomto problému Vašeho návrhu celou dobu mluvím a psal jsem to už asi dvacet postů dozadu.
Ano, zvolil jste pro tuhle úlohu špatný index – B-Tree vám nepomůže tolik v odstranění duplicit. Ale není pravda, že nepomůže vůbec, pomůže alespoň v tom řazení.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 26. 10. 2019, 16:30:10
Fullscan tabulky do tisíce záznamů je rychlejší, než použití indexu. Index pro více záznamů má význam až při selekci, tedy výběru podmnožiny, např. klauzulí WHERE, která vybere méně než cca 10-50 % záznamů.
Pro našeptávač pak ale ještě potřebujete hledat v textech těch jednotlivých záznamů. Takže tím fullscanem tabulky by to neskončilo.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 26. 10. 2019, 22:17:50
Citace
To ale popisujete případ 1 entita = 1 štítek. Když použijete vazební tabulku...
Ty jsi mluvil o jednom či dvou indexech, což odpovídá tomuto modelu jeden štítek jedna entita. Ovšem i u M:N relace (kde jde o dva/tři indexy) je furt výhodnější normalizovaná struktura a tedy mít malý varchar index pro seznam štítků a velký integer index pro vazební tabulku. Furt to dohromady zabere méně místa v paměti, než jeden velký varchar index pro "vazební" tabulku. Průchod integer indexem je také o fous rychlejší.
Citace
Ne, já jsem to na začátku uvedl jako příklad. „Takhle také někdy může vypadat struktura databáze, a  jak tam budete aplikovat vaše pravidla.“
No právě. A my jste se Ti snažili vysvětlit, že takhle dobře navržená databáze nevypadná a proč.

Argumentovat nevhodností nějakého postupu tím, že nefunguje v blbě navržené db struktuře (nebo popř. v DB struktuře, která má smysl jen ve velmi raritním případě), je nesmyslná argumentace. Tedy pro to, abys obhájil svůj argument, musel bys obhájit to, že tvoje struktura není antipattern. Což nejde, protože to je antipattern, který mrví výkonnost dotazů (viz níž).

Citace
On vás někdo nutí, abyste to psal k naprosto nesouvisejícím komentářům? Bylo snad v mém textu, nebo v komentáři Kita, na který jsem reagoval, něco o duplicitách?
Ty jsi doteď ještě nepochopil, že jeden z velkých problémů Tvé DB struktury je to, že bude mít v indexu duplicitně uvedené štítky, takže není rychlá cesta, jak prohledávat názvy štítků? A že to je ta věc, kterou od začátku kritizujeme?

Citace
Nikoli, já jsem o hunspellu nic nepsal.
Psal. Psal jsi o klasickém algoritmu na spellchecking, což je prostě hunspell. To, že sis pod spelcheckingem představoval jiný algoritmus, než jak je v majoritě případů implementován, není moje chyba....

Citace
Omyl. „Check“ znamená kontrola – přičemž obě naše tvrzení popisují kontrolu.
Ne, návrh opravy chyby opravdu NENÍ kontrola správnosti, i kdyby ses postavil na hlavu. Navíc opět lžete a překrucujete, na počátku jste o spellchecku mluvil jako, cituji: "To je prostě množina slov, ve které se dá rychle vyhledat, jestli v ní dané slovo je nebo není.... té struktuře, která umožňuje rychlé vyhledávání, se říká – index.". Tedy na začátku jste definoval spellchecker jako něco, co kontroluje, jestli slovo patří do dané množiny.

Teprve když jsem vyvrátil Váš omyl, že ovšem standardní implementace spellcheckeru není implementována indexem, nýbrž generativní gramatikou, takže se to našeho problému vůbec netýká, tak jste začal jste překrucovat svoje slova i realitu, že podle Vás najednou není spellchecker něco, co kontroluje, jestli dané slovo patří do dané množiny či ne, ale nápověda v případě chyby. Což je úplně jiný problém.

Citace
Problém bude v té druhé části, v tom „spell“. Jde o to, jestli to slovíčko znamená spíš „gramatika“ nebo spíš „hláskování“.
Prosím, zjisti si, co znamená v programování gramatika, zas neznáš základní termíny a pleteš si pojmy s dojmy.
https://cs.wikipedia.org/wiki/Form%C3%A1ln%C3%AD_gramatikaSpellchecking (https://cs.wikipedia.org/wiki/Form%C3%A1ln%C3%AD_gramatikaSpellchecking), tedy kontrola hláskování, se v programování kontroluje gramatikami.

Citace
Nabídka korekce je standardní součástí funkce spellcheckeru....
To sice zpravidla je, ale jde o přibalení jiného algoritmu řešícího jinou věc, než samotný spellchecking. Auto se dnes také nedělá bez světel a bylo by bez nich uživatelsky nepřívětivé, ale mluvit o výkonu auta a myslet tím jak daleko dosvítí je nesmysl. Stejnětak mluvit o algoritmu spellcheckingu a myslet návrh korekce je prostě blbina.
Citace
PostgreSQL:
1) toto je vyhledávání štítku se stejným kořenem, respektive u víceslovných štítků, kde se shodují alespoň nějaké kořeny. Nijak to tedy neřeší původní problém: výpis všech štítků.
2) Neřeší to ani našeptávání štítků, protože na dotaz: "novikny" to nenajde "novinky". Není to ani podobnostní hledání, o kterém tu celou dobu mluvíš.
3) Užití GIN indexu tady vůbec nedává moc smysl: To je právě jeden z Tvých omylů, že se našeptávače implementují pomocí fulltextových indexů. Ano, někdy implementují, ovšem nikoli vždy, pouze pokud je k dané entitě přiřazený delší text. Pokud je k dané entitě přiřazený pouze jednoslovný text - jako např. zpravidla u štítků - je použití GIN indexu nesmysl. Daleko lepší výsledky dá vyhledávání pomocí trigram indexů. Toto už píšu asi po páté.

4) A PŘEDEVŠÍM TVŮJ PŘÍKLAD JEN DOKAZUJE, ŽE MÁME CELOU DOBU PRAVDU, PROTOŽE I V TVÉM DOTAZU SE NAČTOU VŠECHNY HODNOTY A PAK SE NA NICH PROVEDE UNIQUE. I toto Ti píšu asi po páté.

Kód: [Vybrat]
Indexes:
...
    "test2" gin (test)

=> explain select distinct test from translations where test @@ '''teaser_cards_temp''';
                                         QUERY PLAN                                         
---------------------------------------------------------------------------------------------
 Unique  (cost=113233.38..114264.78 rows=206281 width=27)
   ->  Sort  (cost=113233.38..113749.08 rows=206281 width=27)
         Sort Key: test
         ->  Bitmap Heap Scan on translations  (cost=1910.68..90086.19 rows=206281 width=27)
               Recheck Cond: (test @@ '''teaser_cards_temp'''::tsquery)
               ->  Bitmap Index Scan on test2  (cost=0.00..1859.11 rows=206281 width=0)
                     Index Cond: (test @@ '''teaser_cards_temp'''::tsquery)


Citace
Ano, zvolil jste pro tuhle úlohu špatný index – B-Tree vám nepomůže tolik v odstranění duplicit.
Já jsem nezvolil špatný index. Protože dobrý index (přinejmenším v mnoha běžných DB) Tvojí strukturu prostě neexistuje. Já jsem Ti demonstroval na jednom konrkétním indexu, že Tvoje představa nefunguje. Nemůžu za to, že nemáš evidentně praxi s databází, ale si chytrej jak rádio, takže místo toho, aby ses chytil za nos a nechal se poučit, tak nám nevěříš, že se to týká i jiných typů indexů, a dál meleš nesmysly.

Citace
Ale není pravda, že nepomůže vůbec, pomůže alespoň v tom řazení.
To, že pomůže při řazení ale nikdo nerozporoval ani nerozporuje. Celou dobu Ti tvrdíme, že neodstraní nutnosti nějaké formy sequential scanu přes všechny duplicitní záznamy, což je podstata problému, a to prostě neodstraní. Tak fakt nechápu, proč to sem furt taháš. To, že se dají kladivem dobře zatloukat hřebíky, nijak nemění, že používat ho  na krájení chleba je pitomost, byť s ním třeba ten chleba ukrojíš líp, než řemdihem.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 27. 10. 2019, 08:30:02
Ovšem i u M:N relace (kde jde o dva/tři indexy) je furt výhodnější normalizovaná struktura a tedy mít malý varchar index pro seznam štítků a velký integer index pro vazební tabulku. Furt to dohromady zabere méně místa v paměti, než jeden velký varchar index pro "vazební" tabulku. Průchod integer indexem je také o fous rychlejší.
Jestli je to výhodnější nezjistíte tak, že vypíšete výhody a zatajíte nevýhody.

Argumentovat nevhodností nějakého postupu tím, že nefunguje v blbě navržené db struktuře (nebo popř. v DB struktuře, která má smysl jen ve velmi raritním případě), je nesmyslná argumentace. Tedy pro to, abys obhájil svůj argument, musel bys obhájit to, že tvoje struktura není antipattern. Což nejde, protože to je antipattern, který mrví výkonnost dotazů (viz níž).
Zase si vymýšlíte. Já jsem štítky neuváděl jako argument pro vhodnost či nevhodnost nějakého postupu.

Ty jsi doteď ještě nepochopil, že jeden z velkých problémů Tvé DB struktury je to, že bude mít v indexu duplicitně uvedené štítky, takže není rychlá cesta, jak prohledávat názvy štítků? A že to je ta věc, kterou od začátku kritizujeme?
Nepochopil jsem, proč to musíte připojovat i k vláknům, která s tím nijak nesouvisí.

Psal. Psal jsi o klasickém algoritmu na spellchecking, což je prostě hunspell.
A další váš výmysl.

Citace
Omyl. „Check“ znamená kontrola – přičemž obě naše tvrzení popisují kontrolu.
Ne, návrh opravy chyby opravdu NENÍ kontrola správnosti, i kdyby ses postavil na hlavu. Navíc opět lžete a překrucujete, na počátku jste o spellchecku mluvil jako, cituji: "To je prostě množina slov, ve které se dá rychle vyhledat, jestli v ní dané slovo je nebo není.... té struktuře, která umožňuje rychlé vyhledávání, se říká – index.". Tedy na začátku jste definoval spellchecker jako něco, co kontroluje, jestli slovo patří do dané množiny.
V první větě rozporujete, že spellchecker není kontrola správnosti, abyste ve zbytku odstavce dokazoval, že to je kontrola správnosti. Spíš si to nejdřív ujasněte sám, a pak se teprve pouštějte do diskuse.

Teprve když jsem vyvrátil Váš omyl, že ovšem standardní implementace spellcheckeru není implementována indexem, nýbrž generativní gramatikou, takže se to našeho problému vůbec netýká, tak jste začal jste překrucovat svoje slova i realitu, že podle Vás najednou není spellchecker něco, co kontroluje, jestli dané slovo patří do dané množiny či ne, ale nápověda v případě chyby. Což je úplně jiný problém.
Problém je totiž v tom, že neustále vyvracíte věci, které jsem nenapsal.

Prosím, zjisti si, co znamená v programování gramatika, zas neznáš základní termíny a pleteš si pojmy s dojmy.
https://cs.wikipedia.org/wiki/Form%C3%A1ln%C3%AD_gramatikaSpellchecking (https://cs.wikipedia.org/wiki/Form%C3%A1ln%C3%AD_gramatikaSpellchecking), tedy kontrola hláskování, se v programování kontroluje gramatikami.
Další nesmysl. A to vám není hloupé odkazovat na neexistující stránku? To jste si myslel, že si toho nevšimnu? Navíc nemůžu za to, že znáte jenom jedinou metodu implementace spellcheckeru, u které navíc ani nevíte, jak funguje.

To sice zpravidla je, ale jde o přibalení jiného algoritmu řešícího jinou věc, než samotný spellchecking.
Ano, ale je dobré na to myslet už při návrhu algoritmu samotného spellcheckeru. Jinak byste také mohl navrhnout hash index, ve kterém budete zjišťovat existenci slov, a pak zjistíte, že pro návrh možných korekcí vám je ten index úplně k ničemu.

1) toto je vyhledávání štítku se stejným kořenem, respektive u víceslovných štítků, kde se shodují alespoň nějaké kořeny. Nijak to tedy neřeší původní problém: výpis všech štítků.
O tom vašem „původním problému“ už jsme si vysvětlili, že je to velmi raritní případ, tudíž je to nesmyslná argumentace.

2) Neřeší to ani našeptávání štítků, protože na dotaz: "novikny" to nenajde "novinky". Není to ani podobnostní hledání, o kterém tu celou dobu mluvíš.
Zjistěte si, co je to našeptávač. Našeptávač na dotaz „nov“ nabídne „novinky“.

3) Užití GIN indexu tady vůbec nedává moc smysl: To je právě jeden z Tvých omylů, že se našeptávače implementují pomocí fulltextových indexů. Ano, někdy implementují, ovšem nikoli vždy, pouze pokud je k dané entitě přiřazený delší text. Pokud je k dané entitě přiřazený pouze jednoslovný text - jako např. zpravidla u štítků - je použití GIN indexu nesmysl. Daleko lepší výsledky dá vyhledávání pomocí trigram indexů. Toto už píšu asi po páté.
Běžně se používají i víceslovné štítky. Navíc jste chtěl řešení ve standardním Postgresu, předpokládal jsem tedy PostgreSQL bez extenzí. Tak se předveďte, jak v PostgreSQL bez extenzí vytvoříte trigram index.

4) A PŘEDEVŠÍM TVŮJ PŘÍKLAD JEN DOKAZUJE, ŽE MÁME CELOU DOBU PRAVDU, PROTOŽE I V TVÉM DOTAZU SE NAČTOU VŠECHNY HODNOTY A PAK SE NA NICH PROVEDE UNIQUE. I toto Ti píšu asi po páté.
Kde v mém dotazu se provádí unique?

=> explain select distinct test from translations where test @@ '''teaser_cards_temp''';
Ano, tenhle dotaz je trochu podobný mému dotazu. Jsou tam stejná slova SELECT, FROM a WHERE. Ale to jsou klíčová slova jazyka SQL, vyskytují se prakticky ve všech dotazech.

Já jsem Ti demonstroval na jednom konrkétním indexu, že Tvoje představa nefunguje.
Kdybyste věděl něco o databázích, věděl byste, že to, že na něco nejde použít jeden typ indexu, neznamená, že jiný typ indexu selže také. Proto máme různé typy indexů, protože se každý hodí na něco jiného.

Nemůžu za to, že nemáš evidentně praxi s databází, ale si chytrej jak rádio, takže místo toho, aby ses chytil za nos a nechal se poučit, tak nám nevěříš, že se to týká i jiných typů indexů, a dál meleš nesmysly.
Obecně jiných typů indexů se to netýká, sám jste už vyjmenoval typy indexů, které to zvládnou v pohodě, jsou dokonce s tím záměrem vytvořené.

Věřit vám, že se to týká i jiných typů indexů, nebude nikdo soudný – velký kvantifikátor („pro všechna X platí“) nemůžete dokazovat příkladem (malým kvantifikátorem – „existuje X, pro které platí“).

Ten příklad, který jste uvedl, totiž závisí na mnoha faktorech, které jste neuvedl. Jedním je konkrétní implementace B-Tree – i B-Tree index je možné implementovat tak, že v něm každý klíč bude jenom jednou, a duplicity budou řešené seznamem odkazů na záznamy. Dál to závisí na tom, zda plánovač dotazů dokáže nebo nedokáže DISTINCT stlačit (push down) do podmínek.

To, že pomůže při řazení ale nikdo nerozporoval ani nerozporuje. Celou dobu Ti tvrdíme, že neodstraní nutnosti nějaké formy sequential scanu přes všechny duplicitní záznamy, což je podstata problému, a to prostě neodstraní. Tak fakt nechápu, proč to sem furt taháš. To, že se dají kladivem dobře zatloukat hřebíky, nijak nemění, že používat ho  na krájení chleba je pitomost, byť s ním třeba ten chleba ukrojíš líp, než řemdihem.
Já nerozporuju, že při použití pro raritní případ výpisu všech štítků bude muset PostgreSQL při použití B-Tree indexu projít přes všechny duplicitní záznamy. To jenom vy máte potřebu to pořád psát u nesouvisejících komentářů.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 27. 10. 2019, 11:18:44
Citace
Jestli je to výhodnější nezjistíte tak, že vypíšete výhody a zatajíte nevýhody.
Nevýhody - nutnost projití dalším, mělkým a paměťově řádově méně náročným indexem, nijak nezatajuji. Jen tvrdím, že pro celkový výkon DB to není tak velká nevýhoda, jako jí zaplácnout stovky MB paměti větším indexem. Vidíš tam ještě jiné nevýhody?

Citace
Já jsem štítky neuváděl jako argument pro vhodnost či nevhodnost nějakého postupu.
Jo, takže jsme se bavili o vhodnosti DB struktury, ty jsi přišel se štítkama, ale nebyla to ukázka toho, kdy je podle Tebe nějaká struktura vhodná. Aha.....
Citace
V první větě rozporujete, že spellchecker není kontrola správnosti,
Ano, přepsal jsem se. Myslím, že alespoň trochu inteligentní člověk z toho je schopen pochopit, co jsem chtěl napsat: že spellchecking není návrh správnosti, ale kontrola. Tak nevím.... nepochopil jste to? Anebo vaším cílem není diskutovat, ale něco jiného, a nepochopil jste to naschvál?

Citace
Problém je totiž v tom, že neustále vyvracíte věci, které jsem nenapsal.
Ne, problém je, že každou chvíli tvrdíte něco jiného, podle toho, co se zrovna povede vyvrátit tak, že už nemáte žaludek na tom dál trvat.Např. na začátku jste tvrdil, že

"To je prostě množina slov, ve které se dá rychle vyhledat, jestli v ní dané slovo je nebo není..."
chvíli poté
"Spellchecker má za úkol na základě vstupu najít možná podobná slova ze slovníku existujících slov."
a teď zas tvrdíte, že jste to netvrdil a že spellchecker je kontrola správnosti, takže první definice.

Citace
Další nesmysl. A to vám není hloupé odkazovat na neexistující stránku? To jste si myslel, že si toho nevšimnu?
Podle sebe soudím Tebe? Víš, normální člověk nediskutuje proto, aby z druhého dělal vola, a takovéto metody nepoužívá.Zkus to prosím také, diskuse začne být o mnoho kvalitnější. Odkaz se nějak pomrvil, správný odkaz je tady:
https://cs.wikipedia.org/wiki/Form%C3%A1ln%C3%AD_gramatika (https://cs.wikipedia.org/wiki/Form%C3%A1ln%C3%AD_gramatika)

Citace
Navíc nemůžu za to, že znáte jenom jedinou metodu implementace spellcheckeru, u které navíc ani nevíte, jak funguje.
Ne, znám standardní implementaci spellcheckru, která je použita v největších SW balících (libreoffice, mozilla, chrome). A vím, že alternativní spellcheckery (ispell, aspell, myspell, snowball) používají stejný princip. Takže prostě pokud mluvíte o spellcheckru a myslíte tím jiný přístup než generativní gramatiku, tak evidentně mluvíte o něčem, co vůbec neznáte.

A co se týče toho, kdo neví, jak spellchecker funguje, tak já nemluvil o spellcheckru jako o indexu....

Citace
Ano, ale je dobré na to myslet už při návrhu algoritmu samotného spellcheckeru.
Ano, je dobré myslet při návrhu auta na světla. Ale když někdo mluví o tom, na jakém principu jezdí auto, tak nemyslí světlo.

Citace
Jinak byste také mohl navrhnout hash index, ve kterém budete zjišťovat existenci slov,
No, a budete asi překvapen, ale zrovna majoritní implementace: hunspell - alespoň prokazatelně v OS software - na to prostě moc nemyslela a datovou strukturu na to připravenou prostě nemá. A vzhledem k tomu, že je to majoritní spellchecker, tak pochybuji, že jsou na tom ostatní o tolik lépe, některé určitě ne, možná o trochu líp Aspell se svojí implementací soundslikes, ale on to je z principu u hodně ohýbaných jazyků těžko řešitelný problém.

Citace
O tom vašem „původním problému“ už jsme si vysvětlili, že je to velmi raritní případ, tudíž je to nesmyslná argumentace.
Zaprve to sis vysvětlil možná tak sám sobě. Zadruhé jsi původně tvrdil, že to umíš a vysmíval ses ostatním, že to neumí.
Dobře, beru toto jako přiznání, že to neumíš. Že by ses omluvil od Tebe čekat asi nemohu.

Citace
Zjistěte si, co je to našeptávač. Našeptávač na dotaz „nov“ nabídne „novinky“.
Tak proč jste do toho celou dobu tahal cituji: "možná podobná slova ze slovníku existujících slov."? Najednou, když jste zjistil, že ani to neumíte, tak to také není potřeba? Dobrý našeptávač si poradí i s překlepy.

Citace
Běžně se používají i víceslovné štítky.
Zaprve o tom běžně bych pochyboval (ale to těžko dokážeme), zadruhé pokud už se používají, tak jejich text má význam jako celek, čili i tam nemá fulltext (který indexuje jednotlivá slova) zpravidla smysl.
Citace
Navíc jste chtěl řešení ve standardním Postgresu, předpokládal jsem tedy PostgreSQL bez extenzí. Tak se předveďte, jak v PostgreSQL bez extenzí vytvoříte trigram index.
pg_trgm je součástí distribuce postgresu, ač implementována jako modul. To je jako byste tvrdil, že do unixového jádra nepatří moduly a že se má člověk obejít bez nich.
Citace
Kde v mém dotazu se provádí unique?
Aha, vy to unique vlastně ani neprovádíte. Takže pokud ten dotaz poběží nad tou strukturou, kterou tu celou dobu prosazujete, tak vám to našeptá jeden stejný výraz tisíckrát. Tak to se omlouvám, to, že napíšeš dotaz vracející jiný výsledek než chceme jsem nečekal a myslel jsem, že máš na mysli dotaz s distinctem.
Že na to ještě ovšem upozorníš, jako by to byla přednost Tvého dotazu, nějak nechápu. Takže Tě prosím znovu, ukaž dotaz, který umí efektivně vrátit z Tebou prosazované datové struktury unikátní našeptávací návrhy. A klidně pomocí GIN indexu, pomineme, že dobrý spellchecker nabízí i korekce.
Jen Tě upozorňuji, abychom si ušetřili další kola Tvých marných pokusů, že Tvoje víra v schopnosti GIN indexu je mylná, protože kupodivu GIN neindexuje text jako celek, ale jednotlivá slova, takže to ani z principu nemůže umět. Fulltext index by mohl (kdyby byla taková funkcionalita zpřístupněna) efektivně vypsat unikátní použitá slova ve štítcích, nikoli unikátní štítky.

Citace
Obecně jiných typů indexů se to netýká, sám jste už vyjmenoval typy indexů, které to zvládnou v pohodě, jsou dokonce s tím záměrem vytvořené.

Právě jste překonal další metu: ve svém postu jsem Vám demonstroval, že to GIN index neumí, a vy na to bez jakéhokoli důkazu napíště, že to umí. Anebo jste myslel jiný index? Který konkrétně?

Citace
Ten příklad, který jste uvedl, totiž závisí na mnoha faktorech, které jste neuvedl. Jedním je konkrétní implementace B-Tree.....
Ano, a to co vám celou dobu tvrdíme je, že v databázích JSOU ty KONKRÉTNÍ IMPLEMENTACE TAKOVÉ, ŽE TO zpravidla PROSTĚ NEUMÍ, A TEDY JE VAŠE ŘEŠENÍ PRO PŘÍPAD SQL DATABÁZÍ ANTIPATTERN. Že možná vyškrábnete databázi X s indexem Y, která to jako výjimka umět bude, na té antipatternovosti nic nemění.

Celý problém naší debaty je v tom, že neznáte, jak věci implementované JSOU. A jen teoreticky přemýšlíte, jak by věci implementované být MOHLY. A když Vám ukazujeme, že se mýlíte, tak to neumíte přiznat. A nejste schopen připustit, že ač by index v databázi mohl být implementován tak, že by akcelerovat DISTINCT, že tak prostě v drtivé většině prostě NENÍ.
Úplně stejný problém je s tím spellcheckingem: myslel jste si, že je implementován jako index a samozřejmě, že by tak být implementován mohl. Ovšem prostě v majoritních spellchekrech tak implementován NENÍ. Běžné formáty slovníků pro spellchecking nedávají seznam slov výčtem, ale gramatikou.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 27. 10. 2019, 13:25:07
Nevýhody - nutnost projití dalším, mělkým a paměťově řádově méně náročným indexem, nijak nezatajuji. Jen tvrdím, že pro celkový výkon DB to není tak velká nevýhoda, jako jí zaplácnout stovky MB paměti větším indexem. Vidíš tam ještě jiné nevýhody?
Netuším, kde jste přišel na ty stovky MB a řády. Další nevýhodou je, že ten index bude efektivní jenom při hledání podle štítků – dotazy „štítek AND další podmínky“ budou mnohem méně efektivní.

Ano, přepsal jsem se. Myslím, že alespoň trochu inteligentní člověk z toho je schopen pochopit, co jsem chtěl napsat: že spellchecking není návrh správnosti, ale kontrola. Tak nevím.... nepochopil jste to? Anebo vaším cílem není diskutovat, ale něco jiného, a nepochopil jste to naschvál?
Alespoň trochu inteligentní člověk hledá jiná vysvětlení, než že jste hlupák. OK, takže už jsme si ujasnili, že na mé tvrzení, že samotný spellchecking slouží ke kontrole slov, jste reagoval tím, že to není pravda, že spellchecking přece slouží ke kontrole slov. Takže vaším cílem není diskutovat, ale hádat se? Když musíte rozporovat i to, co sám vzápětí napíšete stejně…

Ne, problém je, že každou chvíli tvrdíte něco jiného, podle toho, co se zrovna povede vyvrátit tak, že už nemáte žaludek na tom dál trvat.Např. na začátku jste tvrdil, že

"To je prostě množina slov, ve které se dá rychle vyhledat, jestli v ní dané slovo je nebo není..."
chvíli poté
"Spellchecker má za úkol na základě vstupu najít možná podobná slova ze slovníku existujících slov."
a teď zas tvrdíte, že jste to netvrdil a že spellchecker je kontrola správnosti, takže první definice.
To ovšem nevysvětluje, proč vyvracíte tu první definici, abyste ji vzápětí sám použil.

Odkaz se nějak pomrvil, správný odkaz je tady:
https://cs.wikipedia.org/wiki/Form%C3%A1ln%C3%AD_gramatika (https://cs.wikipedia.org/wiki/Form%C3%A1ln%C3%AD_gramatika)
No jo, jenže tenhle odkaz zase nijak nepotvrzuje vaše tvrzení.

A co se týče toho, kdo neví, jak spellchecker funguje, tak já nemluvil o spellcheckru jako o indexu....
Vždyť jsem to psal, že nevíte, jak spellchecker funguje.

Citace
Zjistěte si, co je to našeptávač. Našeptávač na dotaz „nov“ nabídne „novinky“.
Tak proč jste do toho celou dobu tahal cituji: "možná podobná slova ze slovníku existujících slov."? Najednou, když jste zjistil, že ani to neumíte, tak to také není potřeba? Dobrý našeptávač si poradí i s překlepy.
Už zase si pletete našeptávač a spellchecker. Citoval jste část věty, která celá zněla takhle: „Spellchecker má za úkol na základě vstupu najít možná podobná slova ze slovníku existujících slov.“

Takže pokud ten dotaz poběží nad tou strukturou, kterou tu celou dobu prosazujete, tak vám to našeptá jeden stejný výraz tisíckrát.
Ten dotaz nic nenašeptává, vrací seznam entit podle zadaného textu štítků.


Tak to se omlouvám, to, že napíšeš dotaz vracející jiný výsledek než chceme jsem nečekal
Ono je totiž těžké z vašich komentářů zjistit, co vlastně chcete – teda kromě toho, že se chcete hádat za každou cenu.


Takže Tě prosím znovu, ukaž dotaz, který umí efektivně vrátit z Tebou prosazované datové struktury unikátní našeptávací návrhy.

Kód: [Vybrat]
CREATE INDEX idx_stitky_gist ON stitky USING GIST(stitek gist_trgm_ops);

SELECT DISTINCT ON (stitek) AS nazev, stitek <<<-> query AS vzdalenost
  FROM stitky
  WHERE stitek <<% query
  ORDER  BY vzdalenost DESC, stitek
  LIMIT 10;


to co vám celou dobu tvrdíme je
Ne, tohle jste teď napsal poprvé. A ještě nejspíš píšete jen o PostgreSQL, ne obecně o relačních databázích (a už vůbec ne o databázích obecně).

TEDY JE VAŠE ŘEŠENÍ PRO PŘÍPAD SQL DATABÁZÍ ANTIPATTERN
Vidím, že vám dělá radost, že s vámi v něčem souhlasím, takže to budete pořád dokola opakovat, dokonce to musíte vyřvávat. Sice je to mimo téma diskuse, protože já jsem nikdy netvrdil, že je to doporučený postup, jak ve většině případů dělat štítky, ale když vám to dělá radost to pořád opakovat…

A nejste schopen připustit, že ač by index v databázi mohl být implementován tak, že by akcelerovat DISTINCT, že tak prostě v drtivé většině prostě NENÍ.
Opět se mýlíte. Já jsem se k DISTINCTu nevyjadřoval, protože to nebyla věc, kterou bych v téhle diskusi řešil. Když jsme si ujasnili, že vážně chcete na uživatele nasypat seznam všech štítků, potvrdil jsem vám, že pro takový případ opravdu není vhodná taková struktura databáze, jakou jsem popsal.

Úplně stejný problém je s tím spellcheckingem: myslel jste si, že je implementován jako index a samozřejmě, že by tak být implementován mohl. Ovšem prostě v majoritních spellchekrech tak implementován NENÍ. Běžné formáty slovníků pro spellchecking nedávají seznam slov výčtem, ale gramatikou.
Myslíte, že třída HashMgr je ve zdrojácích hunspellu jenom omylem a nepoužívá se? Nebo to podle vás není index?
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 27. 10. 2019, 17:13:05
Citace
Netuším, kde jste přišel na ty stovky MB
Netušíte, protože evidentně nemáte s DB zkušenost. Vemte si velkou tabulku, udělejte jí index nad varchar a integer sloupcem a koukněte se, jak je veliký... A to obzvlášť, když budete mít víceslovné, tedy dlouhé štítky.

Citace
a řády.
Pokud bude počet štítků řádově menší než počet oštítkovaný, tak bude kupodivu řádově menší index nad těmi štítky než nad vazební tabulkou. To musím vysvětlovat i takovéto primitivnosti?
Citace
dotazy „štítek AND další podmínky“ budou mnohem méně efektivní.
Udržíš moč? Protože myšlenku evidentně ne. :-) Teď se - na Tvůj popud - bavíme o situaci M:N, kde žádná taková výhoda denormalizace není.

Citace
Už zase si pletete našeptávač a spellchecker. Citoval jste část věty, která celá zněla takhle: „Spellchecker má za úkol na základě vstupu najít možná podobná slova ze slovníku existujících slov.“
Z té TVÉ věty je evidentní, že spellchecker s našeptávačem si pleteš dohromady TY. Už jsme se tedy doufám shodli, že návrh/našeptání korekce a spellchecker jsou dvě různé věci. Já se akorát ptal, proč návrh korekce (ať už jí nazýváš dobře nebo špatně), jsi do toho vůbec pletl, když teď tvrdíš, že taková funkcionalita vůbec není potřeba.

Citace
Ten dotaz nic nenašeptává, vrací seznam entit podle zadaného textu štítků.
A proč ho sem dáváš? Když celou dobu řešíme to, že Tvá databázová struktura není efektivní pro našeptávání štítků, a o vyhledávání entit se tu nikdo v této souvislosti nebavil? A když to byla tvá odpověď na: "....Tedy že vyhledání i malého počtu štítků ve velkém počtu záznamů pomocí fulltextového indexu není tak rychlé, jako vyhledání téhož v normalizované datové struktuře...", tedy na dotaz jak uděláš efektivní vyhledávání štítků a ne štítkovaných entit???,
 
Citace
Kód: [Vybrat]
CREATE INDEX idx_stitky_gist ON stitky USING GIST(stitek gist_trgm_ops);

SELECT DISTINCT ON (stitek) AS nazev, stitek <<<-> query AS vzdalenost
  FROM stitky
  WHERE stitek <<% query
  ORDER  BY vzdalenost DESC, stitek
  LIMIT 10;
Ufff. Zaprve, tendle dotaz je úplně špatně. Neumíte vůbec pracovat s DISTINCT ON. Pominu-li, že nevíte, že DISTINCT ON neříká, které sloupce mají být ve výstupu, takže DISTINC ON AS je nesmysl, tak máte blbě i ORDER BY, protože DISTINCT ON vyžaduje správný ORDER. Takovýto dotaz se musí napsat se subselectem (který vám mimojiné odhalí marnost vašeho počínání :-)). No a pak tam máte i blbé operátory, ale to jste asi jen blbě opsal manuál....

A zadruhé, když ty všechny chyby opravíte tak, že to bude fungovat, tak to opět bude stejná písnička, bude se tam provádět UNIQUE operace nad stejnými záznamy. Jen jste opět  prokázal, že to prostě napsat neumíte (protože to ani nejde). Ale aspoň jste si konečně zjistil něco o trigram indexes.


Citace
Ne, tohle jste teď napsal poprvé. A ještě nejspíš píšete jen o PostgreSQL, ne obecně o relačních databázích (a už vůbec ne o databázích obecně).
To je holt problém, když místo toho, co bys pořádně četl, co Ti tu lidé píší, tak jen dokolečka tvrdohlavě opakuješ svůj názor, dávno v diskusi vyvrácený.
Psal jsem Ti to např. tady:https://forum.root.cz/index.php?topic=21909.msg319312#msg319312 (https://forum.root.cz/index.php?topic=21909.msg319312#msg319312)a tady
https://forum.root.cz/index.php?topic=21909.msg319198#msg319198 (https://forum.root.cz/index.php?topic=21909.msg319198#msg319198)a psali Ti to i jiníhttps://forum.root.cz/index.php?topic=21909.msg319193#msg319193 (https://forum.root.cz/index.php?topic=21909.msg319193#msg319193)další výskyty mě už nebaví hledat.

A píšeme tam o jiných databázích, protože toto je zrovna věc, která funguje plus mínus všude stejně, nejoptimálnější implementace indexů prostě distinct akcelerovat neumí, a protože to v rozumných DB strukturách potřeba není, tak se zpravidla pro tento účel speciální indexy nezavádí.

Už chápete, proč radši některé věci zdůrazňuji "křikem", když je píšu poxté a doteď jste to ignoroval? Teď Vás to donutilo aspoň to vnímat.

Citace
Opět se mýlíte. Já jsem se k DISTINCTu nevyjadřoval,
Takže se tady celou dobu nebavíme o našeptávání štítků? ??? Které jaksi v té Tvé struktuře bez distinctu napsat prostě nejde? ??? ? Nebo tvrdíš, že to nějak napíšeš bez distinctu? A todle psal kdo? Mimozemšťan?
Citace
SELECT DISTINCT v takovém případě bude full table scan
O existenci indexů jste už slyšel?
Od toho debata začala a celou dobu po Vás chci, abyste ukázal, jak toto naimplementujete, a to buďto pro výpis štítků (kde jste se nejprve snažil a pak prohlásil, že to není potřeba), nebo alespoň pro našeptávání (kde jste si zatím netroufl tvrdit, že to není potřeba).Protože tvrdím, že to efektivně našeptat nejde a tedy že je vaše datová struktura nevhodná.

Citace
To ovšem nevysvětluje, proč vyvracíte tu první definici, abyste ji vzápětí sám použil....
Máš evidentně problém s pochopením psaného textu. Nevyvracel jsem, že spellchecker slouží k testování toho, že dané slovo patří do množiny. Vyvracím Ti, že je to index.

Citace
Myslíte, že třída HashMgr je ve zdrojácích hunspellu jenom omylem a nepoužívá se? Nebo to podle vás není index?
Auto má motor a používá ho a motor je v autě podstatný. Znamená to, že je auto motor? ??? ??? Spellcheker používá index, znamená to, že spellchecker je index? ??? Index je struktura, která slouží k dohledání záznamu v datovém souboru. Jelikož ovšem hunspell nemá žádný datový soubor, ale pouze pravidla pro generování validních slov, tak prostě není indexem.

Index se v hunspellu používá pouze k dohledání kořenů slov, nikoli k samotnému otestování, zdali je slovo validní, a je to technologicky nejméně zajímavá součást hunspellu. Takže přirovnání k autu a motoru tu vlastně nesedí, ten hashindex je v hunspellu asi v takové pozici, jako kola pro auto. Jo, auto bez kol nepojede: ale to, že umíte udělat kolo, ještě neznamená, že umíte udělat auto. A označovat kolo za auto je prostě nesmysl.

Btw. Teď jste si hezky sám vyvrátil své předchozí tvrzení, že spellcheckry přeci myslí na korekce: sám jste si dokázal, že hunspell během svého fungování používá hash a tedy nemá interní struktury optimalizované na korekce. Zkuste příště než zas plácnete nějaké "musí to tak být" tomu věnovat aspoň takovouto chvíli, jako teď, a bude diskuse o dost jednodušší. A kdybyste si ty zdrojáky hunspellu prohlédl trochu pozorněji, tak byste si ušetřil i tento omyl....
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Filip Jirsák 27. 10. 2019, 17:32:38
Omlouvám se, moje chyba. Když jsem na začátku zjistil, že 70 % vašeho komentáře evidentně reaguje na něco, co jsem nenapsal, mělo mi dojít, že i těch zbývajících 30 %, které se dají vyložit jako reakce na můj text, je na tom ve skutečnosti stejně.
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Logik 27. 10. 2019, 19:27:46
Jinými slovy, "když jsem zkusil asi pěti pokusy napsat efektivní dotaz a nikdy se mi to nepovedlo, a když jsem konečně zjistil, že to opravdu nejde, tak se z toho musím nějak vykecat."
Tak jo, beru to, čekal jsem, že líp uznat omyl nebudeš umět.

PS: Pro příště: méně trapné je radši neodpovědět vůbec, když už jsi příliš hrdý na to se omluvit.
 
Název: Re:MySQL - podmíněný SELECT přes dvě tabulky
Přispěvatel: Miroslav Šilhavý 27. 10. 2019, 19:31:10
radši neodpovědět vůbec, když už jsi příliš hrdý na to se omluvit.

Nezaměňujte hrdost s pýchou.