dejane, ovo sto si napisao je samo jedan od mogucih nacina dobar za jedan broj aplikacija a opet je vrlo opst i generalizujuci ... kao sto si i sam napisao, generalizacijom samog sistema oduzimas mu agilnost ... da ne spominjemo sta se desava kada generalizujes ceo sistem ...
svaki problem ima svojih n resenja, i svako to resenje zavisi od velikog broja promenjljivih ... ono sto ja radim za leba je bas to, uzimam u obzir veci broj promenjljivih nego sto neko ko radi arhitekturu obicno uzima u obzir i u osnovu na to dajem preporuku koji put je najbolji za taj set varijabli ... nekada je dovoljna mala promena u setu zhatevnih varijabli koja kompletno menja "najbolje resenje", zato, po nti put kazem, nema srebrnog metka, ne postoji resenje koje je univerzalno dobro ...
ja sam se u zivotu nagledao situacija gde inzenjer 3 dana crta uml, 2 dana pise dokumentaciju i 2 dana pise kod za obican glupi parser za neki log fajl koji se koristi "samo jednom interno", dakle umesto da je napakovao za 5 minuta awk skriptu i odradio posao on je izgubio 56 radnih sati da bi odradio taj posao i onda ga "bacio" ... mozda deluje kao glup primer, ali tako bacenih sati u jednoj prosecnoj firmi srednje velicine ima zastrasujuce mnogo...
drugi primer je recimo ORM, vrlo popularan tip frameworka zadnjih desetak godina ... jako popularan zadnjih 5-6 .. to je, recimo, najskuplja greska koju firma moze da napravi .. da me ne shvati neko pogresno, ORM nije uvek greska, ali kada se ORM koristi gde ne treba to moze taaaaaaaaako mnogo da kosta ... ako je neko citao moje primere "debilnih pitanja", vrlo cesto se provlaci "na test serveru je radilo super a sada na produkciji ne radi" (zato sto su na test serveru radili sa datasetom od 100M a na produkciji imaju dataset od 2G) ... u 99% slucajeva kriv je ORM... ako pogledate upite koje prosecan ORM izvrsava - to je da sednes i places.. a ne mozes im nista, ne mozes da ih optimizijujes (iako je vidljivo sa kilometar kako bi mogli da se optimizuju) posto ne mozes da utices na to kako ih orm generise ... onda takva firma kaze "sql je sr4nje, aj sad da koristimo no-sql" i onda pisu prilagodjenje upite za no-sql .... naravno 10000x jeftinije im je bilo da su sada te upite pisali optimizovano u sql-u dobili bi resnje odma koje provereno radi ... (imamo nekoliko primera velikih na netu koji su napravili ceo krug sa ORM->noSQL->SQL kao na primer digg)... opet u mnogo slucajeva, orm resava mnogo vise problema nego sto ih pravi (ERP na primer) pa ma koliko je prica sa bazom iz razloga ORM-a spora, toliko se to isplati sa druge strane....
izbor data storage-a je takodje ogroman faktor ... jeste "sql" univerzalan, ali nacin na koji neke stvari rade ovde i onde nije ... glupo poredjenje mysql i pgsql-a .. 2 najjaca open source rdbms-a na svetu ... ako imamo hiljade jednostavnih upita mysql je neuporedivo brzi dok ako imamo stotine kompleksnih upita (koji odradjuju isti posao u manje upita nego oni jednostavni) pgsql ce odrati mysql... ja rdbms necu odabrati po tom kriterijumu vec po drugim kriterijumima (npr ako mi treba testirano dobra replikacija uzecu mysql, ako mi sa druge strane treba potpuno otvorena licenca i necu da se smaram sa advokatima uzecu pgsql) pa cu onda u odnosu na to koju sam bazu odabrao da resim jedan problem u 3 jednostavna upita ili u jednom kompleksnom .. da ne spominjemo oracle, db2, teradata i ostale "velike" baze podataka ...
dakle svaki odgovor na originalni post koji preferira bilo koje resnje spada u domen mrmota i cokolade.... CPU jeste dzaba i tacno je da se mnogo povecao, HDD space jeste dzaba i mnogo se povecao, RAM jeste relativno jeftin a nije bas nesto mnogo poskocio (ja trosio 64-128G masine pre 10 godina, sad trosim 128-256G masine ... i nije neki drastican pomak, samo duplo) ali ako uporedimo koliko je data danas veca, data se povecala mnoooooooooooogo vise nego sto se povecao i cpu i hdd i ram ... sredne preduzece sada operise sa mnogo vise date nego sto je operisalo pre 10 godina, da ne spominjemo pre 20 godina ... da ne spominjemo "velika" preduzeca i velike sisteme ili nedaj boze socijalne mreze i online aplikacije koje su odavno prevazisle komparaciju sa enterprise aplikacijama posto jedna velika socijalna online aplikacija barata sa vise podataka nego ogromna spediterska kuca...