Not so much thinking about transactions, or avoiding straight queries with stored procs, more about returning large result sets as native queries rather than collections of cfc objects.
One possibility of course is to use ORM for single/composite record detail, and native cf queries for search/list etc. That would be looking at result lists as a reporting function, where you'd use different (non-ORM) techniques. Really just wondering if people are using ORM at scale, if they're running into performance/memory issues, and how they're being dealt with if so. Dave On Fri, Oct 22, 2010 at 8:54 AM, Russ Michaels <r...@michaels.me.uk> wrote: > > Well if you are doing A LOT of database transactions then you have to > consider the additional processing time and memory required by creating all > those objects. > Instantiating objects is nowhere near as much of a bottleneck as it used to > be, so it depends on your application and requirements. > It is a trade off at the end of the day, ORM increases productivity and > reduces complexity but at the same time you lose flexibility and control and > of course performance. > If performance and scalability if your big concern for your database then > you should perhaps be looking at using stored procedures, I don't know how > hibernate copes with these, if at all but as the SQL and logic is in the SP, > I can't see benefit to using ORM to call the SP anyway. > > -- > Russ Michaels > > FREE CFML hosting for developers > www.cfmldeveloper.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:338471 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
