MySQL - podmíněný SELECT přes dvě tabulky

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #165 kdy: 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.


Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #166 kdy: 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:
  • založím kartu zaměstnance (budoucího vedoucího),
  • založím podřízeného
  • následně označím vedoucího, že je "vedoucí" a v tu chvíli bude CHECK plnit svoji funkci

Při výměně týmu byste musel postupovat složitěji:
  • Iterovat než dojdete k poslednímu členu týmu a odstraňovat je z týmu.
  • Před odstraněním posledního člena týmu byste musel odznačit příznak "vedoucí".
  • Teprve pak odstranit posledního člena týmu.

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.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #167 kdy: 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.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #168 kdy: 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.
 


Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #169 kdy: 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.


Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #170 kdy: 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.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #171 kdy: 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.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #172 kdy: 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.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #173 kdy: 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?

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #174 kdy: 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.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #175 kdy: 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.

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #176 kdy: 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.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #177 kdy: 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é.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #178 kdy: 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....).

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #179 kdy: 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".
« Poslední změna: 23. 10. 2019, 10:19:21 od Miroslav Šilhavý »