Thanks, another good strategy for us to consider! -----Original Message----- From: Dominic Watson [mailto:[email protected]] Sent: 27 September 2011 13:11 To: cf-talk Subject: Re: ORM overhead
And this of course implies that the db is created first - and that the application is not DB agnostic. This works for us in this particular situation where CF application is secondary to the database (and as such should not control the creation of database objects). On 27 September 2011 13:08, Dominic Watson <[email protected]> wrote: > 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 <[email protected]> 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) <[email protected]> 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:[email protected]] >>> 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:347750 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
