The thing is, you've got an overhead because of all the factories and objects and the general architecture that makes you take up so much of the workload within your application - a place which is too far away from the data to be able to optimise itself effectively.
As a result of this inefficiency, you are using a cache to compensate, and regaining some of what you have lost. This is great, I'm glad your application is working faster as a result, but please don't mistake it for anything other than a band-aid compensating for your architectural choices. To be clear, I'm not bagging on this approach, every application architecture is a litany of compromises between the problem, the proposed solution, and the capabilities and resources of the developers and the client, and mine are no exception. The choice to utilise an ORM with a cache is not flawed, nor is it uncommon or unreasonable. However, as professional developers it is not wise to make the mistake of convincing ourselves that our tradeoffs are optimal. When we do this, we lose sight of what the ideal is, and find ourselves habitually implementing band-aids even when there is no longer reason to do so. In general, the closer to the data you are when you chose to manipulate it, the better the performance. For relational databases, this means the use of stored procedures, views, checks, indexes, partitions and all the other things that an RDBMS can provide that lets you manipulate the dataset from a distance. Effective use of these tools dramatically reduces the number of queries, the number of connections, and the amount of load placed on the database. This has grown even more true in the last decade as databases have gained more powerful operators, such as PostgreSQL window functions. There are times when a cache is the appropriate tool for the job, however it is also the first place people turn for a band-aid when their architecture is compromised and it comes at a cost in terms of data coherency. This is why I tell people not to cache until they need to, for fear they will miss a solution that fits better with their need. Regards, Richard. On 2 February 2010 17:29, Bruce <[email protected]> wrote: > Hi Richard, > > We use an OO model with a factory design-pattern. The factory loads > objects from the database only once and then caches them for the > entirety of a particular transaction. Once the transaction is > finished the cache is dropped. We got an 70-90% performance > improvement just using this approach. > > Cheers, > Bruce > > -- > NZ PHP Users Group: http://groups.google.com/group/nzphpug > To post, send email to [email protected] > To unsubscribe, send email to > [email protected] -- NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected]
