Na otázky súvisiace s výkonom je väčšinou správna odpoveď: zmeraj si to a uvidíš.

Určite nemá zmysel načítavať používateľov po jednom (edit: teda keď celkovo načítavaš viac článkov a viac používateľov), ale keď už z článkov vieš, akých používateľov budeš potrebovať, tak ti stačí druhá query pre načítanie potrebných používateľov (select where id in) a spojenie dát až na strane SQL klienta.

Na jednu stranu, jeden select dáva možnosť optimalizácie query na strane SQL servera, pri komunikácii máš len jeden request-response, SQL server parsuje query iba raz. Na druhú stranu jednotlivé SQL selecty dávajú viac priestoru na lepšie kešovanie, menej priestoru na zamykanie tabuliek, menej prenosu redundantných dát.

Nám vyšlo, že jednotlivé selecty boli pre náš prípad rýchlejšie.

K druhej otázke: Predpokladám, že keď budeš načítavať články, tak budeš vždy chcieť vedieť aj rubriku. V tom prípade ak budeš mať rubriku v tabuľke s článkom, tak sa pri ich selectovaní nebudú musieť spájať žiadne dáta (resp. maximálne dáta danej rubriky). Takže pri selecte článkov dajme tomu podľa dátumu pridania to bude rýchlejšie, ako keby SQL server ešte k tomu musel vyhľadávať z ďalšieho indexu, že v ktorej rubrike je daný článok.

Naopak, pri zobrazovaní článkov z danej rubriky, to je celkom jedno, pretože aj tak ideš podľa indexu s rubrika-článok a dáta článku sa dotiahnu z tabuľky s článkami. Či sú dáta indexu priamo v tabuľke s dátami alebo nie, už takú veľkú rolu nehrá (index si môžeš predstaviť ako samostatnú tabuľku). Ak ale potebuješ ešte usporiadať články z danej rubriky podľa času vytvorenia článku, tak má zmysel si do tej vedľajšej tabuľky ukladať aj ten čas vytvorenia a zahrnúť ho do indexu. Osobne by som to dal priamo do tabuľky s článkami.