Zobrazit příspěvky
2191
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« 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 fungovatCo 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.
