home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / 8760 < prev    next >
Encoding:
Text File  |  1993-01-01  |  2.7 KB  |  56 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!newsserver.pixel.kodak.com!laidbak!tellab5!odgate!mike
  3. From: mike@uunet!tellab5!odgate (Mike J. Kelly)
  4. Subject: Re: 500'000 records - who does best?
  5. Message-ID: <1993Jan1.182624.2993@uunet!tellab5!odgate>
  6. Organization: Odesta Corporation
  7. References: <18774@mindlink.bc.ca> <1993Jan1.021012.24215@news.arc.nasa.gov>
  8. Date: Fri, 1 Jan 1993 18:26:24 GMT
  9. Lines: 45
  10.  
  11. lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:
  12.  
  13. >In article <18774@mindlink.bc.ca>, Mischa_Sandberg@mindlink.bc.ca (Mischa Sandberg) writes:
  14.  
  15.  
  16. >|> We run Sybase on Suns and RS6000's. We chose Sybase because, within our
  17. >|> domain, they beat Oracle down quite handily (they also didn't try to
  18. >|> fudge the benchmark). 
  19.  
  20. >Would anyone care to comment on the ad campaign that Oracle is 
  21. >running right now, showing Oracle 7 to be 3-4X faster than Sybase on
  22. >TPC-A?  Unfortunately, in their long list of systems compared, there
  23. >is very little overlap in the system configurations run between the
  24. >different vendors. The same ad has appeared in a number of trade rags.
  25. >The "headline" is: Sybase Best: 183 TPS   Oracle 7 Best: 645 TPS.
  26.  
  27. I would be very skeptical of any Oracle benchmark claims because Oracle's
  28. license prevents the publication of any benchmark results without Oracle's
  29. permission.  Therefore, the only Oracle benchmark results you will see are
  30. the "good" ones.
  31.  
  32. >                                   With 30K records, you are dealing
  33. >|> with blobs outside the normal record structure; you can run greater
  34. >|> risks.
  35.  
  36.  
  37. >Is there a "correct" way to deal with this problem yet?  It can show
  38. >up in surprisingly simple DBMS applications, such as where you want to
  39. >search through a bunch of trouble calls for matches to a particular 
  40. >problem.  1-2 years ago, when I inquired to this newsgroup, there was
  41. >no RDBMS that could handle text searches efficiently.  (Efficiently,
  42. >that is, compared to a text processing/retrieval system.)  Is this still
  43. >the case?
  44.  
  45. As far as I know, no one has yet integrated content-based retrieval (CBR)
  46. with BLOBs and large text fields, which is what you really want.  Remember,
  47. though, that BLOBs are relatively new and I would expect that something like
  48. this will start happening in the next year or so.
  49.  
  50. It might be interesting to the vendors who are reading this group if we
  51. were to start a thread on what a CBR-BLOB capability would look like.  The
  52. way I conceive it, at its simplest, it would involve a new type of index
  53. ("create text index"?) which would set up a varchar or BLOB column to be
  54. retrieved via CBR operators, along with some new CBR operators (at least
  55. contains, and probably more sophisticated stuff than that.)
  56.