On 22 Aug 2018, at 19:39, Sam <[email protected]> wrote: > This seems like a simple schema, not sure what caching would buy you unless > the DB is not a local service on the same box or network (or getting several > hundred requests per second).
Yeah, it's definitely getting hundreds of requests a second :) > Generally, in my apps when it comes to more complex queries, I first write > the query in raw SQL and benchmark it. Then I convert it over to a DBIC > resultset (which normally means using the prefetch option) and bench mark > that. If it much slower than the raw SQL query, I might look into only > fetching the columns I need (via the 'columns => []' property). If that > doesn't speed it up enough, I'll then switch to using the hashref inflator > resultsource class which usually brings it right in line raw SQL performance. Right, of course. But that doesn't making a compelling case to migrate to DBIC class. I already have an ad-hoc SQL version which has been benchmarked and optimised. It's the abstraction that I want. Thanks.
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
