> Thanks Isaac, > I think you answered my question by stating that most > frameworks don't help you with data access. If that > is the case, then I could use FB/MG/whatever and then > do the data access how I like. They might suggest I > put my queries in a specific location, but after that > I can make them 10 lines or 500 lines, and the > framework will work the same.
Yep, that's the gist of it. There might be exceptions, but generally speaking only if you went out of your way to find a specifically data-access framework. > As far as using views: we do use views here, and they > are very nice. But let me give a simple example to > explain why our queries can be complex. Say you have > financial data in 3 different databases, all built by > 3 different people. The reason there are 3 different > databases is because the data is gathered by 3 different > business units in the company. The Budgeting system > needs to gather data from all 3 systems. For example, > one page in the budget tool allows you to budget for a > department's payroll. In order to put the necessary > data on the screen (all of the info a manager needs > to create his payroll budget), you have to query the > budget database itself (for historical comparisons), > as well as the human resources and the ERP databases. > The reason for the first two is obvious, but the ERP > system is where employees charge their work orders > when they do capital labor jobs throughout the year. > So a data query for the payroll budget screen has to > join data from all three databases, hitting multiple > tables in each. This is not a simple report though, > because /every/ manager in the company will use this > tool, so every query will be unique to that manager's > department. Also, most of the data queries behind > this page are virtually useless in the rest of the > budget tool. We /could/ create a view that would > simplify the above queries, however this view would > be useless to any other page or tool because this > specific situation is very unique. > Am I making any sense? Yes and no. :) It may just be that the system is genuinely so complex that routine use of multi-hundred line queries is really necessary. It may be that I would have to actually sit down and look over the code and the db schema myself to understand that... But as a general rule I'm not inclined to think so... My money would be hedged on the idea that there is _some_ similarity between the payroll for one department and the next. If there's not, then I'd love to write a business case for your company outlining how they're hemoraging hundreds of thousands of dollars every year by making their programmers spend many, many extra hours coding by (among other things) reinventing payroll every time they create a new business unit. :P Actually (and I mean absolutely no disrespect by this) this conversation reminds me of another thread where someone was asking about how to programatically add columns to a table (or maybe tables to the db, I'm not sure). It turned out that their use for the extra tables was to create extra dimensions in a crud application. I don't remember the _precise_ details of their environment, but in essence they had a table that held the core records (example: workflow event) and then for each property that a user wanted to apply to those core records (example: status, priority) they would have the system programatically create another table for them. I was of course trying to explain that I felt this was a poor choice of architecture and they said, with no sarcasm "how am I supposed to do this without adding columns/tables"? I ended up sending a fairly detailed response which explained how to store id's and labels for the properties in one table and the values for properties in a 3rd so that the application would have only 3 tables and require no additional schema changes rather than continually adding columns or tables. (I had myself just recently implemented a similar 3-table workflow system.) If I remember correctly they never responded afterward. In any event, as I said, no disrespect intended. All I'm saying is that, while you could be correct in the assumption that there's not a good way to compress that code so it's not so verbose and easier to manage, I'm not inclined to think so because my own personal experience has been consistently different, but that it may be rather difficult for a) you to adequately explain your environment enough for me to fully understand the issues at hand or b) for me to adequately explain a proposed solution enough for you to implement it, particularly without my having a lot more (likely first-hand) exposure to your environment. s. isaac dealey 434.293.6201 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.fusiontap.com http://coldfusion.sys-con.com/author/4806Dealey.htm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:234562 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
