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