home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / 8715 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  2.4 KB
  1. Path: sparky!uunet!olivea!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: <0t0avvy@Unify.Com>
  6. Date: 30 Dec 92 03:08:53 GMT
  7. References: <18971@mindlink.bc.ca>
  8. Sender: news@Unify.Com (news admin)
  9. Organization: Unify Corporation (Sacramento)
  10. Lines: 51
  11.  
  12. In article <18971@mindlink.bc.ca>, Mischa_Sandberg@mindlink.bc.ca (Mischa Sandberg) writes:
  13. > > Michael Perry writes:
  14. > > >500,000 records, averaging 30K *each*. Forget Sybase and Oracle on Suns;
  15. > > >go for a Teradata.
  16. > > Hmmm... given the price/performance of a Teradata I can only say:  HUH?
  17. > >
  18. > > Makes _no_ sense [to me, anyways] to spend millions of dollars for Teradata
  19. > > stuff when a smaller SMP box would be a LOT more practical.
  20. > :-) Yes, it WOULD be a lot more practical, if it did the job. IF.
  21. > >
  22. > > >and what you are suggesting is probably outside the envelope already.
  23. > >
  24. > > Hmmm... outside the envelope.  Kinda hard to imagine a 30-40 user system
  25. > > being outside the envelope, at least without a LOT more data to gnaw on.
  26. > 
  27. > It isn't the number of users, it's the basic size of the tables.
  28. > One of our clients has pushed a table to 900k rows, 250Mb on an RS/6000
  29. > with 50Mb memory dedicated to the Sybase server. Working with it
  30. > feels like retiling the bathroom while an elephant uses the john.
  31. > 
  32. > On a practical level: can you segment your app to use several servers
  33. > (I mean multiple boxes, not processes)?
  34. > 
  35. > --
  36. > Mischa Sandberg ... Mischa_Sandberg@mindlink.bc.ca
  37.  
  38.  
  39. I believe that this thread started out as a "can anyone do this REASONABLY"
  40.  
  41. UNIFY 2000 can handle this (500K rows @ 30K per row). If you have the disk space,
  42. we have the database. :-)
  43.  
  44. Mischa is right... its not the users, it's the size of the database. The
  45. UNIFY 2000 database package can have individual table segments in the 16+Mb
  46. category, allowing over 500 rows per segment, so the table would only require
  47. 10000 segments.
  48.  
  49. You would still have plenty of room for indices and the rest.
  50.  
  51. Performance is impossible to judge without getting your hands a little dirty.
  52. It depends on hardware, access patterns, indexing strategies, and a whole lot
  53. more, but in general UNIFY 2000 is very hard to beat in the performance area.
  54.  
  55. You might check us out: 1-800-24UNIFY
  56.  
  57. -Jeff Evarts
  58. --jde@unify.com
  59.  
  60. Disclaimer:
  61.     I work for UNIFY corporation, in technical support. These are my words,
  62.     not those of UNIFY.
  63.