3 ms·
Having worked with Hibernate recently on a smallish database (that isn't expected to grow too big), my take away is to minimize the network trips. If you have t
by noisy_boy 6y ago
Having worked with Hibernate recently on a smallish database (that isn't expected to grow too big), my take away is to minimize the network trips. If you have to check something for a list/set of things and all of that can be done from, say, two not so big tables, fetch the superset of records via a join with as much criteria pushed to predicates as efficiently possible and handle rest of the logic in application code. It is so much more quicker. Of course, like most things in software, conditions apply like network latency/total no. of records being fetched by the query/potential for data to suddenly grow etc.
- bernawil 6y agoNot to cache simple trips to the database is pretty uncontroversial, the are more controversial cases elsewhere. Say you consume a Restful API to hidrate order data in another system. Do you fetch orders as: /orders?ids=id-1,id-2,id-3 or separate calls to /orders/id-x which can be cached and retrieved by id as a memoized function? Well if you had to pick only one the second is probably better, but the best would be abstracting away order fetching in application code to always fetch single orders and behind the scenes looking up the cache for singles and pooling all the misses into a single request to the plural endpoint.
- flukus 6y agoIf this is a common occurrence the former would almost always be better, the second would be absolutely glacial. > but the best would be abstracting away order fetching in application code to always fetch single orders and behind the scenes looking up the cache for singles and pooling all the misses into a single request to the plural endpoint. Unless a significant amount of requests have 100% cache hits then I doubt a local cache will make much of a difference at all, all it's saving is a bit of bandwidth.