@Dejan Vu
Klingt sehr vernünftig. "Das" richtige Vorgehen gibt es nicht, die Theorie mag noch so perfekt sein, wenn die Realität das nicht mit vertretbarem Aufwand abwickeln kann, muss eine pragmatische Lösung für den Einzelfall her.
Wer lange genug in dem Umfeld arbeitet, hat irgendwann seinen Erfahrungsschatz oder kennt jemanden mit dem Erfahrungsschatz für Problem X, jemanden für Problem Y... und dann wird (unter Zuhilfenahme von Creativität und einer gewissen Verspieltheit) die bestmögliche (umsetzbare und bezahlbare) Lösung gesucht.
Habe mal ein System neubauen müssen, dass vorher mit ausgereifter Software von der Analyse bis zur Implementierung (die von den Werkzeugen generiert wurde - sowohl Datenbank, als auch Programm), nach allen Regeln der Kunst erstellt wurde.
Das war seinerzeit die "Innovation" (seit dem hasse ich dieses Wort).
Preformance für die Tonne und als die "bekloppten Anwender" ein Feature haben wollten, dass diese Systeme nicht abbilden konnten, war es nicht möglich, die passenden Änderungen in den generierten Quelltext einzubauen.
Also Delphi genommen, Erfahrungsschatz dazu und vier Wochen fast ununterbrochen gearbeitet. Und dann war das fertig, pfleg- und wartbar und sauschnell.
PS.:
Schlecht implementierte Abfragen werden durch viel
RAM nicht besser, sondern man verdrängt das Problem, bis das Mehr an Speicher irgendwann auch nicht mehr ausreicht (und der Zeitpunkt kommt immer, meist dann, wenn man nicht damit rechnet oder es extrem ungünstig ist - halt Murphy).
Unser o. g. Performanceprobleme hatten wir auf einem Datenbankhobel mit "nur" 64 CPUs und ich weiß nicht mehr 256 oder 512 GB Speicher. Ist fast ein Jahrzehnt her...