Příspěvky

1021

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

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

1022

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

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

1023

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

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

1024

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

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

1025

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 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.

1026

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 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é.

1027

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 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.

1028

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 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.

1029

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 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.

1030

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 21. 10. 2019, 14:30:30 »

Nejlepším databázovým API je SQL.

Amen.

1031

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 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.

1032

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 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.

1033

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 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.

1034

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 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.

1035

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 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.