I'm all for building apps as infrastructure neutral as possible, I'm sorry, this is pretty stupid. If you're going to pick the lowest common denominator from ALL DB platforms (or even all common ones), you're going to be hurting. Unless you're building an app for distribution that has to run on a bunch of platforms (or building a DB abstraction framework <cough> Isaac <cough>), leverage the database wherever possible. Structure your code so that you can replace the DB with another with a minimum of fuss should you need to, but use your database.
Note that I'm not advocating not using caching, but rather relying on caching just to avoid database dependance. Caching is very valuable, and can give HUGE performance increases. cheers, barneyb On 8/30/05, S. Isaac Dealey <[EMAIL PROTECTED]> wrote: > > Like pretty much everyone else, I have always used the > > following method for > > paging through result sets, > > > <cfoutput query="whatever" startfrom="#startfrom#" > > maxrows="#maxrows#"> > > > And altering those variables to allow 200 records per page > > or whatever, > > > But this means querying ALL records form the database each > > time, which can > > be very excessive when your dealing with a very large > > database. > > Has anyone come up with a good solution of only querying > > the records you > > actually need (rows 40 -59 for example). > > Don't use the db for that -- it's different for every database... and > not like a character or two... massively, completely, incompatibly > different... > > I like to use one of these methods: > > 1) post the search form to a page that runs the query, stores it in a > session variable and forwards the user on to the page that will > display results from the stored session variable - this has the > disadvantage of removing the search variables from the url so they > can't send it to someone else or bookmark the search (oh, did i > mention I don't like to use "post" for search forms?) The user will > continue to use the same search results until they submit the form > again. > > 2) create a "key" for the query (something that identifies all the > variables being used in the where clause), then store the results for > that key in the application scope with a timestamp and allow those > results to live there for a couple minutes at a time. This has the > advantage that if a person sends their search url to someone else, the > other person's request will use the same cache when they hit that url. > Of course, if the query is filtered by your application security (i.e. > a user is only allowed to see certain records), then the first > approach is probably a better idea. > > Or some combination of these. > > Yeah, it's heavier on the first request, but that's not entirely > unexpected with a search. > > > s. isaac dealey 954.522.6080 > 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 > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:217226 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=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
