Mislim da je glavni problem, tj. glavna prednost dobro optimizovanog koga u odnosu na razne framework-e izbacivanje ORM-a. Jednostavno, kad performanse postanu bitne optimizacija kljucnih upita, tj. njihovo prepisivanje postaje jedini nacin dobijanja smisljenih performansi.... Glupoti koje sam nalazio u slow query log-u i koje npr. Eloquent pravi ostavljaju utisak da je to neko nogama pisao. Dodatno, cela filozofija je optimizovana za rad iz koda i niko nije predvideo nacin rada gde se dodaje neki trigger / stored procedura ili bilo sta slicno. Realno, modeli koje napravis tako obicno nemaju ni constraints, jer "to sve radi kod".
Vidjao sam herojske napore da se ostane u okviru ORM-a tako sto se kljucni upiti potrpaju u (nematerijalizovane, tj. jedine u mysql-u) view-ove, koje onda mysql tretira kao normalne upite, vidjao sam ljude koji jednostvno direktno naprave upit iz koda ignorisuci ORM na par kljucnih mesta u kodu, ali neko resenje mora da postoji - taj model je najbolje objasnio jedan kolega koji mi je rekao, parafraziram, "Vidi, Laravel+Eloquent su super za rapid prototyping, ali kad krenes u produkciju neke stvari MORAS da resavas drugacije".
S'druge strane, brzina samog framework koda, tj. ucitavanje klasa i slicno.... to sve popegla opchache, realno, danas sa php 7 lepo podesen server ne oseca razliku. Super je imati mali memory footprint i brzo ucitavanje, ali na sajtu koji ima 100K posetilaca brzina prvog je nebitna - a razlika u brzini se oseti, realno, samo na tom prvom. Moje misljenje kao nekog ko optimizuje servere za sajtove sa stotinama hiljada korisnika: Framework da, ORM oprezno i ne svuda. :)
Please do not feed the Trolls!
Blasphemy? How can I blaspheme? I'm a god!'