home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / 8674 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  2.5 KB
  1. Xref: sparky comp.databases:8674 comp.databases.oracle:2630 comp.databases.sybase:561
  2. Path: sparky!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsc!cbfsb!att-out!rutgers!ucla-cs!ucla-mic!agsm!ddruker
  3. From: ddruker@agsm.ucla.edu (Daniel Druker)
  4. Newsgroups: comp.databases,comp.databases.oracle,comp.databases.sybase
  5. Subject: Re: 500'000 records - who does best?
  6. Message-ID: <1992Dec23.132155.15738@mic.ucla.edu>
  7. Date: 23 Dec 92 21:21:54 GMT
  8. References: <1992Dec21.182948.16832@bernina.ethz.ch>
  9. Organization: Anderson Graduate School of Management, UCLA
  10. Lines: 40
  11. Nntp-Posting-Host: risc.agsm.ucla.edu
  12.  
  13. In article <1992Dec21.182948.16832@bernina.ethz.ch> Florian.Gutzwiller@open.ch writes:
  14. >If you'd have to realize a server client based database with Suns as servers  
  15. >and NeXT as clients. Single records would be an average of 30KB in size and  
  16. >there would be a number of 20 concurrent users. 
  17. >
  18. >Would you choose Sybase or Oracle ?
  19. >Who has experience with similar solutions/environments ?
  20.  
  21. I'd choose Oracle, hands down, based on backup and recovery issues. 500k recs
  22. of 30kb each means you have a pretty large database. Figure in additional
  23. space for indexes and sorting space and you might be talking 30 Gigabytes
  24. or more. Sybase will have serious problems backing up a database of this
  25. size. It will probably take DAYS to perform a backup, load, or restore. 
  26. Oracle treats large databases much better, and includes lots of parallel
  27. stuff which really helps on multi-processors. I expect query speeds will
  28. be similar since you're really only gated by how fast the disk spins, 
  29. and with a database of this size you probably wont want to allow many
  30. (or ANY) full table scans, ad hoc stuff, etc..., especially on a sun
  31. with a limited number of procs...
  32.  
  33. Oracle has a very large database group which they can put you in touch with
  34. to get some practical experience of users with I think up to 100 or so gigs   
  35. of data. 
  36.  
  37. Hope this helps, 
  38.  
  39. - Dan
  40.  
  41. Daniel Druker
  42. Anderson Graduate School of Management at UCLA
  43.                    
  44.  
  45. ----------------------------------------------------------------------------
  46. | Dan Druker                                                               |
  47. | agsm mail     : ddruker                                                  |
  48. | internet     : ddruker@agsm.ucla.edu                                    |
  49. | oracle*mail    : unix:ddruker@agsm.ucla.edu                               |
  50. ----------------------------------------------------------------------------
  51.  
  52. Disclaimer:  None. I'm a student now and I don't care what you think. 
  53.