home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / 8773 < prev    next >
Encoding:
Text File  |  1993-01-03  |  1.5 KB  |  43 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!swrinde!gatech!cc.gatech.edu!terminus!brent
  3. From: brent@terminus.gatech.edu (Brent Laminack)
  4. Subject: Re: 500'000 records - who does best?
  5. Message-ID: <brent.725766347@cc.gatech.edu>
  6. Sender: news@cc.gatech.edu
  7. Organization: Georgia Tech College of Computing
  8. References: <18971@mindlink.bc.ca> <0t0avvy@Unify.Com>
  9. Date: Thu, 31 Dec 1992 01:45:47 GMT
  10. Lines: 31
  11.  
  12.  
  13. >I believe that this thread started out as a "can anyone do this REASONABLY"
  14.  
  15. >UNIFY 2000 can handle this (500K rows @ 30K per row). If you have the disk space,
  16. >we have the database. :-)
  17.  
  18. >Mischa is right... its not the users, it's the size of the database. The
  19. >UNIFY 2000 database package can have individual table segments in the 16+Mb
  20. >category, allowing over 500 rows per segment, so the table would only require
  21. >10000 segments.
  22.  
  23. Is this the same Unify company that tells me to try to keep all tables
  24. to 16 or fewer segments? After that performance is said to degrade? If
  25. memory serves, 10000 >>> 16
  26.  
  27. >You would still have plenty of room for indices and the rest.
  28.  
  29. >Performance is impossible to judge without getting your hands a little dirty.
  30. >It depends on hardware, access patterns, indexing strategies, and a whole lot
  31. >more, but in general UNIFY 2000 is very hard to beat in the performance area.
  32.  
  33. There are other considerations, however. Ask Unify to do an outer join.
  34. They can't.
  35.  
  36. No brag, just facts.
  37.  
  38. Brent Laminack (brent@cc.gatech.edu)
  39.  
  40.  
  41.                     
  42.                     -Brent Laminack (brent@cc.gatech.edu)
  43.