home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / mac / database / 1661 < prev    next >
Encoding:
Text File  |  1993-01-06  |  1.9 KB  |  41 lines

  1. Newsgroups: comp.sys.mac.databases
  2. Path: sparky!uunet!stanford.edu!CSD-NewsHost.Stanford.EDU!Xenon.Stanford.EDU!michaelh
  3. From: michaelh@Xenon.Stanford.EDU (Mike Hennahane)
  4. Subject: Re: Looking for ideas on large mac databases
  5. Message-ID: <michaelh.726374388@Xenon.Stanford.EDU>
  6. Sender: news@CSD-NewsHost.Stanford.EDU
  7. Organization: CS Department, Stanford University, California, USA
  8. References: <1ig04bINN72j@merlin.resmel.bhp.com.au>
  9. Date:  7 Jan 93 02:39:48 GMT
  10. Lines: 29
  11.  
  12. paulm@steelmel.bhp.com.au writes:
  13. [...]
  14. >Since we only report on historical data occasionally, I thought I would keep
  15. >history on a tape, and copy it onto a disc when I need to use it.  I also
  16. >thought I would keep a separate database for the most recent two years.
  17. [...]
  18. >But I was wondering if anyone has some thoughts on ways to manage historical
  19. >data.  Sometimes I will want to report on time periods which overlap years
  20. >(hence I have one big historical database instead of a few smaller ones-is it
  21. >possible to overcome this difficulty in the new version of 4th dimension?). 
  22. >Any ideas on managing large databases on a pc would be appreciated.  Also, any
  23. >ideas on designing a faster database would also be of interest.
  24.  
  25. if the problem is that having the extra info around is confusing, then
  26. you might consider archiving old data to another table of the database
  27. instead of off onto tape. that way, you can still browse the old data
  28. in the historical section, but you only have a more manageable amount
  29. of current data in the current section. these two tables can have
  30. identical structures, so that you can run reports from either one, or
  31. you can implement an un-archive function to merge some/all of the old
  32. data back in with the current data to run reports.
  33.  
  34. as for designing a faster database, that depends mostly on the quirks
  35. of 4d (the obvious way is not always the best), on whether you have
  36. compiled your database, or on whether you are running the new 4d
  37. server software.
  38.  
  39. --mike
  40.  
  41.