On Sun, 2 Jun 2002 23:30:49 -0700, Avi Nahir <[EMAIL PROTECTED]> wrote: >IMHO, however, it makes more sense to use a local "helper" database when >the following is true: > >You want to reduce the load on the database server. >The data doesn't change a lot, so that sending it to clients pays for >itself over time. >A large (but not huge) amount of data is needed to answer user queries. >The results are obtained through joins and aggregate funtions. > >In such a scenario I think it would make sense to let the local database >process the queries. > >Does this make sense?
In this scenario are you sure that _every_ user will make good use of this locally stored data? If not, then you could potentially sending an awful lot of data across the wire for nothing. The cost being both network bandwidth and initial large database query result sets (and would this happen at the beginning of the day say, when everyone starts logging on?!). It sounds like what you really have is a "reporting" requirement, so wouldn't it be neater to have a replicated copy of the database which is used for these read-only large-data-set reports. Combine this with a chunk of memory on the reporting database server(s) and perhaps pinning some tables to ensure in-memory operations. Likewise, if reporting results are shared amongst users, perhaps pre- empting these reports into temporary tables or caching them in temporary tables after the first user makes the report request. The report result sets could then also be stored locally on the workstation as XML files, which gives some querying capability (but obviously not a full RDMS functionality, so only useful for some requirements). So, IMHO, I would not go down a route of installing Access databases on each of the workstations, especially when also considering the additional maintenance and workstation dependency issues mentioned elsewhere on this thread. Cheers, Lee. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
