CompuServe Messages

Rich, My limited experience with databases so far suggests that 200 – 400 MB is a good size for a corporate database on CDROM. If your tables support lots of relations you go towards the lower number. If your tables are pretty much self-sufficient you can go towards the higher number. How to keep multiple copies of your data depends on what your client needs. The client I am working with now regularly uses two consultants – I write apps in Access, and the other consultant is a "Clipper-head". For the first CD I decided to include all the tables in a lowest-common-denominator format (dBase III+ with .NDX indexes). As a result, his apps are poor performers and I hit a wall because Access does not support (contrary to all advertisements) attaching a dBase table and index on a CDROM. This time all the data is going onto the CD in *both* Access and Clipper formats. One trick I am learning is to make better use of temporary and scratch tables on the fixed disk. One of my apps is a '90 Census report generator. The client wants to build a list of geographic areas (cities, counties, tracts, etc.) and then print reports from the data. I've put all the selection data into one set of tables (States, Counties, MCDs, Census Places, etc.) so that the app doesn't get bogged down reading data fields until a region has been selected. Then, before the reports get generated, I pull all the data for selected regions into a temporary database on the fixed disk. The reports this client wants tend to make heavy use of relations and analysis (lots of number crunching), and seem to overwhelm the simple caching algorithms built into Access (lots of disk reads). There are two downsides to this approach: 1) CDROM looses a bit of its cost effectiveness when you put a 300MB database on it instead of a 600MB database. 2) Keeping multiple versions of a table synchronized adds cost to [OzCIS: Continued in next msg]