One thing to note is that an ORM bean can map to a database view. We've used this technique with great success in an Oracle db, keeping zero sql in our client application. Sure, we're using a tiny subset of ORM features because of this, but it has kept complexity down for us.
Dominic On 26 September 2011 21:35, Russ Michaels <r...@michaels.me.uk> wrote: > > It is a pretty easy test. > make 2 pages. > > 1 that uses cfquery > 1 that uses ORM > > get them both to do the same heavy database work > compare the execution times. > > ORM is clearly going to have some overhead by its very nature, so you > have to measure whether the convenience and portability outweighs the > performance hit. > > ORM has multiple uses, it is a RAD framework the same as CFML allowing > you to do complex tasks easily without underlying knowledge of the > database structure, it also creates portability so that the same code > will work on multiple database platforms. > For many ORM removes too much control as you are limited to the > confines of what ORM can do so you may find yourself unable to do > certain complex or dynamic queries without dropping back into regular > SQL. > There is also the fact that you are moving all your data abstraction > into the application layer, the stored proc advocates who prefer to > keep data abstraction within the database would say this is a bad > thing. > > It is really a case of weighing up the pros and cons of each method > and choosing which best suits you and your application. It you are > concerned with squeezing every cycle of speed and performance out of > your app, then ORM is probably not for you. > But overall I would say that most developers use CFML because of its > RAD speed and convenience, so ORM is really just an extension of that > so the performance hit is acceptable. > > On Mon, Sep 26, 2011 at 8:50 PM, Richard (J7 Group) <rich...@j7is.co.uk> > wrote: >> >> Thanks for your reply Jochem. >> >> This is some excellent advice and we will def look into it. >> >> I wonder if I am over complicating this issue. Basically our application is >> a Software as a Service (SaaS) and each client that accesses it really only >> needs to connect to their own data source due to the type of data our >> application processes... and regulations in the industry say their data must >> be separated. >> >> So, the actual objects in the database may vary but only *very* slightly. >> The only real issue we have here is not that the objects will vary but how >> do I get ORM to point to purely a different data source name - but use the >> same set of objects. >> >> >> >> >> >> >> -----Original Message----- >> From: Jochem van Dieten [mailto:joch...@gmail.com] >> Sent: 26 September 2011 20:22 >> To: cf-talk >> Subject: Re: ORM overhead >> >> >> On Mon, Sep 26, 2011 at 8:07 PM, Richard (J7 Group) wrote: >>> Performance overhead, especially in an application that could be linked to >>> thousands of data sources? >> >> I think an application with thousands of datasources is so far out of >> the experience of other users that we will have no way of answering >> your question. I do have a few questions that may be helpful in >> finding the right questions and answers yourself. >> >> 1. What would you consider an acceptable overhead in terms of GB of RAM? >> 2. What would you consider an acceptable overhead ni terms of seconds >> delay of application startup? >> >> Once you have answered that, run the following experiment: >> 1. For one database, generate the CFCs for the tables using a code >> generator (such as the plugin to CF Builder). >> 2. Add the database to the orm configuration in application.cfc >> 3. Add the CFC folder to the orm configuration in application.cfc. >> 4. Measure startup time. >> 5. Repeat step 1-3 for 9 more databases. >> 6. Measure startup time. >> 7. Extrapolate. >> >> With thousands of datasources even a small number of tables per >> datasource means on startup CF has to compile and process tens or even >> hundreds of thousands of CFCs to build all the right relations and >> objects. I expect that to be prohibitively expensive on startup time >> (question 2) long before you have a problem with RAM (question1), even >> if you use HBMXML files to store the relations. Since my experience >> does not go further then close to 200 tables in one application I have >> no idea what the result will be and am very interested in what your >> measurements will tell. >> >> Jochem >> >> -- >> Jochem van Dieten >> http://jochem.vandieten.net/ >> >> >> >> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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:347740 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
