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
