...my $.02 I was recently reading about this very issue, and read this... "Welcome to the nightmare that is Stored Proc version control!"
For what it's worth, I do most of that functionality in UDF's. There is probably good sound reasons for converting them to CFC's. Life is complicated enough. I use MySQL as a datastore and write the sql as vanilla as I can. Don't have time for DB issues. Agreed, I'm not writing Twitter, and would probably change my tune if I were. For now, I'll keep as much of my logic as possible in one place in one language .... the app server. C On Wednesday, May 23, 2012 4:10:15 PM UTC-5, Jason Allen wrote: > > Hi Alan, > > That was kind of my original idea. > > Now that I have 95% of the app done (at least first phase) I want to go > back and reframe everything so that development will be easier in the > future. My idea was to take all my data processes and write them up as > functions and build them into a single CFC. I think once this is done, I > can reduce the text in my code by 60% or more. > > Also, it's going to be much easier for me to scale out/up the webservers > than it will be the database. Logically, it's much simpler to add more > webservers via load balancer and have them all hit the database, than it > would be to scale out the database. Not that I can't scale out the DB, but > the webserver can simply be duplicated and added to a pool. I was thinking > that even if creating the functions in the DB would yield slightly better > performance, it would be nearly as good as a trade off as leaving the DB > alone as much as possible (just using it as a datastore) and putting the > work on the webserver/openbd. > > -Jason > > On Wed, May 23, 2012 at 3:59 PM, Alan Holden <[email protected]> wrote: > >> Abstract each data process to a single cffunction in a cfc. Your >> application would call this single event from the multiple places - >> wherever it's needed. That's basic DAO. >> >> It makes the whole mess easier to maintain: You can swap your dynamic SQL >> with a SP whenever your volume needs it. You can change out the DB platform >> - and only need to adjust the DAO in a single place. The rest of your app >> never needs to change its naming schema. You can encase the core DAO method >> within another public method that (checks security and) returns the result >> set as JSON or whatever - as part of an API for outsiders. The list goes on. >> >> Some frameworks - like FW/1 - have all this architecture already in >> place. But you can also create your own version. That way, if your >> application never gets anywhere - you can always push out the "framework >> part" to the CFML community and become famous. >> >> I'm old-fashioned - in thinking that a database should just be >> responsible for the bare basics of taking my data and returning it back to >> me. Assigning PK's, indexing and some sparse logging triggers can be a part >> of that - but I prefer to keep as much "business-model" logic OUT of the >> database as possible. Just my opinion. >> >> Al >> >> >> On 5/23/2012 12:35 PM, Jason Allen wrote: >> >>> Hi Guys, >>> >>> I've ported my apps database from MS-SQL to mySQL and so far so good. >>> >>> Since I've got most of my scripts working right, I'm now looking at the >>> best way to create those scripts as a function. >>> >>> >> -- >> online documentation: http://openbd.org/manual/ >> http://groups.google.com/**group/openbd?hl=en<http://groups.google.com/group/openbd?hl=en> >> > > -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en
