I haven't followed this entire chain, but I have always maintained that when using an ORM, or I call a DAO ( Data Access Object ) there is always the need to append custom functions that do crazy queries when you need to be as efficient as possible. When your using tools like an ORM, it's so that 80% of your work is handled for you, fast and efficient, but it's not to ensure you have to use it for everything.
Another thing to think about, when you can't seem to get the speed from an ORM you would like, in order to get the best performance from your code, and to keep your code DB independent, that's when stored procedures come into play. This will keep your code generic, and put the emphasis on the DB of choice, and you can't get better scale or speed for complex needs than just developing the process on the DB. Regards, David McGraw Oyova Software, LLC http://www.oyova.com On Fri, Oct 22, 2010 at 9:07 AM, enigment <enigm...@gmail.com> wrote: > > 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:338472 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
