home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / database / 8822 < prev    next >
Encoding:
Internet Message Format  |  1993-01-05  |  2.6 KB

  1. Path: sparky!uunet!gossip.pyramid.com!pyramid!unify!Unify.com!jde
  2. From: jde@Unify.com (Jeff Evarts)
  3. Newsgroups: comp.databases
  4. Subject: Re: 500'000 records - who does best?
  5. Message-ID: <0g3avp6@Unify.Com>
  6. Date: 5 Jan 93 18:09:00 GMT
  7. References: <18971@mindlink.bc.ca> <0t0avvy@Unify.Com> <brent.725766347@cc.gatech.edu>
  8. Sender: news@Unify.Com (news admin)
  9. Organization: Unify Corporation (Sacramento)
  10. Lines: 64
  11.  
  12. In article <brent.725766347@cc.gatech.edu>, brent@terminus.gatech.edu (Brent Laminack) writes:
  13. > >I believe that this thread started out as a "can anyone do this REASONABLY"
  14. > >UNIFY 2000 can handle this (500K rows @ 30K per row). If you have the disk space,
  15. > >we have the database. :-)
  16. > >Mischa is right... its not the users, it's the size of the database. The
  17. > >UNIFY 2000 database package can have individual table segments in the 16+Mb
  18. > >category, allowing over 500 rows per segment, so the table would only require
  19. > >10000 segments.
  20. > Is this the same Unify company that tells me to try to keep all tables
  21. > to 16 or fewer segments? After that performance is said to degrade? If
  22. > memory serves, 10000 >>> 16
  23.  
  24. Cute... but
  25.  
  26. Performance _can_ degrade by one _virtual_ read per row access IF:
  27.  
  28.     1. You have more than 16 segments in a table, AND
  29.     2. You are short on ram, AND
  30.     3. The row requested is not in a recently used segment.
  31.  
  32. On a system wanting to keep 1.5TB of data
  33.  
  34.     1. A lack of RAM is not likely.
  35.     2. Other latencies will overshadow the additional read.
  36.  
  37. So it should not be a problem.
  38.  
  39. > >You would still have plenty of room for indices and the rest.
  40. > >Performance is impossible to judge without getting your hands a little dirty.
  41. > >It depends on hardware, access patterns, indexing strategies, and a whole lot
  42. > >more, but in general UNIFY 2000 is very hard to beat in the performance area.
  43. > There are other considerations, however. Ask Unify to do an outer join.
  44. > They can't.
  45.  
  46. Hmmm. not _strictly_ true. There are many ways to do this in UNIFY, from within
  47. SQL and out. We do not have a DIRECT mechanism to do this because we try to be
  48. ANSI SQL compliant and ANSI SQL uses UNIONs to do what other database companies
  49. use outer joins to do. So although we do not have a nifty way to do this directly,
  50. you can get the job done (often more efficiently) by taking other routes.
  51.  
  52. > No brag, just facts.
  53. > Brent Laminack (brent@cc.gatech.edu)
  54. >                     
  55. >                     -Brent Laminack (brent@cc.gatech.edu)
  56.  
  57. Really, though. The base conversation was "can anyone handle this", and
  58. "can they handle it REASONABLY". The answer is still yes to both questions.
  59.  
  60. Disclaimer: I'm a techie, not a sales-ie
  61.  
  62. -Jeff Evarts
  63. --jde@unify.com
  64. ---#include <sys/disclaimer>
  65.