5 ms·
I have a hard time believing that no one anywhere on the original teams understood that caching database calls was good/standard practice. I think even basic e
by mgkimsal 13y ago
I have a hard time believing that no one anywhere on the original teams understood that caching database calls was good/standard practice. I think even basic examples like that point out the lack of management problem. I can easily envision someone on the team bringing up basic data caching and getting overruled by other people on the team for trivial/stupid/political reasons. With no proper or clear management in place, there's no one to take this stuff to.
- untog 13y agoOr just a lack of testing. There's no way to know how many database calls are too many without actually testing the damn thing.
- shpiel 13y agoWhat type of database did they use? What type of caching would be desirable? Most modern RDBSes, like Postgre, Oracle, or Microsoft SQL server, have internal LRU caching already implemented. InnoDB tries to store everything in memory. I wonder if they meant that the default caching was turned off, or that all the queries had "no cache" clauses, or that an additional caching layer (Redis, Memcached) was not implemented?
- watwut 13y agoThey used markLogic NoSQL store http://blogs.wsj.com/cio/2013/12/03/healthcare-govs-heart-beats-for-nosql/ http://blogs.wsj.com/cio/2013/12/03/healthcare-govs-heart-be... Just for the record, contractor did not wanted to use it and argued the team have no experience with it. Someone in government decided it must be done that way (in spring or summer).
- hga 13y agoYeah, a database with an unfamiliar paradigm in a project with late and constantly changing requirements, a major one of "no window shopping" in August, and others through the week before launch, is an obvious recipe for an extra big disaster. Some people have theorized that Accenture's new role is to quietly replace much of the current code base with their not quite so horrible California exchange code.