[eluser]Bulk[/eluser]
The way I implemented memcached was very straight forward - essentially it takes the query and makes an md5 hash from it, then uses the hash as the key for the result of that query stored in memory. Then if the same query is done, it can look up the data in memcached and return that instead of doing the query. The drawback with this method is it doesn't give much control. For instance there is no way to "expire" a query manually using this method (memcached expires after a time you set automatically) - this causes problems if data changes (say if a user makes an update) - at the moment we just have to wait for the cache to expire on its own.
If I could go back to the start I would have put memcached in from the start - or at least left a way in the code that I could easily add it in later. If you aren't expecting your code base to be very complicated it's quite feasible to do it later - it all depends how big (in terms of features) your site will be
The folder/code structure is essentially 100% the same, we still have folders for views, controller & models etc all in the same places they are by default.
To be honest I've not missed any type of ORM system at all - we just use a simple mix of the built in active record class for simple queries and just straight queries for the more complex ones (I believe active record has gotten better in later versions, so many of our queries could probably be done as AR now). We didn't feel it was worth adding another layer of abstraction on top of the already quite powerful database class. Your mileage may vary
