Ž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.
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.
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íš.... :-)
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...
...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í.
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).
Zobrazit příspěvky
