A kézzel leprogramozást úgy értem, hogy lefuttatod az alqueryt és annak az eredményét kiveszed resultsetként, majd visszafeedeled a következő query-be úgy, hogy az értékeket sorba beleírod a lekérő SQL-be. Alapvetően hülyeség ilyet csinálni, de mégis néha érdemes, például mert így látjuk mi mennyi ideig tart önmagában. Bár aki ismeri az adatbázisát, az valószínűleg abból is ki tudja nyerni a részeredményeket.
További ötlet lehet, hogy a max date bejegyzést a salary és a title táblában is egy boolean-nal megjelölöd. Így nem kell ezeket mindig kinyálazni, egyből rendelkezésre áll - pláne, ha be van indexelve ez a flag. Nyilván a frissítésekkor ezt a flaget kezelni kell. Az indexelésnél lényeges, hogy ne egy adat alapján legyen, hanem a teljes halmazon, amire a lekérdezés vonatkozik. Ugyanis ha egy-egy oszlopon van index, és kettőre vonatkozik a kérdés, akkor még mindig két eredményt őssze kell fésülni. Azonban ha például van egy (latest_entry, salary) összetett indexed, akkor egy where latest_entry and salary>10000 kérdés teljesen indexből kiszolgálható.
A Duplicate entry fogas kérdés. Akármelyik al-lekérdezésnek ha több értéke van véletlenül, az okozhatja. Például a department, ha a dept_no véletlenül nem zárja ki az ismétlést. Vagy ha a date alapú lekérdezésben van két egyforma dátum (ez valószínűbb) és az duplikált sort okoz. Nem logikus, hogy valakinek egyazon dátumon két különböző címe van, de ez a tipikus, hogy a való életbeli adatbázisok tele vannak ilyenekkel. Pláne amiket emberek töltenek fel! Úgy kell megfogalmazni a query-ket, hogy ezek ne okozhassanak bajt! Tesztelni úgy lehet, hogy a lekérdezést lefuttatod akár kulcs nélküli táblába, majd abban keresel duplikátumot valahogy így: https://chartio.com/learn/databases/how-to-find-duplicate-values-in-a-s…
Amúgy én sem vagyok egy SQL mágus, a tananyagot elég jól megtanultam, az adatszerkezetek a véremben vannak, de ritkán használom, és amikor kell, akkor folyton keresnem kell, hogy mit hogy is kell leírni SQL-ben.