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
