home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / database / 8833 < prev    next >
Encoding:
Text File  |  1993-01-06  |  2.5 KB  |  57 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!psgrain!neon!pail!servio!marcs
  3. From: marcs@slc.com (Marc San Soucie)
  4. Subject: Re: 500'000 records - who does best?
  5. Message-ID: <1993Jan5.223945.4180@slc.com>
  6. Organization: Servio Corp, Beaverton Oregon, US
  7. References: <18774@mindlink.bc.ca> <1993Jan1.021012.24215@news.arc.nasa.gov> <1993Jan1.182624.2993@uunet!tellab5!odgate>
  8. Distribution: na
  9. Date: Tue, 5 Jan 1993 22:39:45 GMT
  10. Lines: 45
  11.  
  12. Mike J. Kelly (mike@uunet!tellab5!odgate) writes:
  13.  
  14. > Hugh LaMaster (lamaster@pioneer.arc.nasa.gov) writes:
  15.  
  16. > > Mischa Sandberg (Mischa_Sandberg@mindlink.bc.ca) writes:
  17.  
  18. > >                                   With 30K records, you are dealing
  19. > >|> with blobs outside the normal record structure; you can run greater
  20. > >|> risks.
  21.  
  22. > >Is there a "correct" way to deal with this problem yet?  It can show
  23. > >up in surprisingly simple DBMS applications, such as where you want to
  24. > >search through a bunch of trouble calls for matches to a particular 
  25. > >problem.  1-2 years ago, when I inquired to this newsgroup, there was
  26. > >no RDBMS that could handle text searches efficiently.  (Efficiently,
  27. > >that is, compared to a text processing/retrieval system.)  Is this still
  28. > >the case?
  29.  
  30. > As far as I know, no one has yet integrated content-based retrieval (CBR)
  31. > with BLOBs and large text fields, which is what you really want.  Remember,
  32. > though, that BLOBs are relatively new and I would expect that something like
  33. > this will start happening in the next year or so.
  34.  
  35. BLOBs are not new to the Object-Oriented database community. An active
  36. OODB, which allows you to write methods that are stored and executed in the
  37. database engine, makes solution of this kind of problem quite routine. Such
  38. solutions that can be easily customized and tuned to match specific problem
  39. needs, and readily shared between applications.
  40.  
  41.  
  42. > It might be interesting to the vendors who are reading this group if we
  43. > were to start a thread on what a CBR-BLOB capability would look like.  The
  44. > way I conceive it, at its simplest, it would involve a new type of index
  45. > ("create text index"?) which would set up a varchar or BLOB column to be
  46. > retrieved via CBR operators, along with some new CBR operators (at least
  47. > contains, and probably more sophisticated stuff than that.)
  48.  
  49. Or use an OODB and save the need for a new syntax or a new set of 
  50. operators. Most OODB's handle this kind of work with their built-in access 
  51. mechanism.
  52.  
  53.     Marc San Soucie
  54.     Servio Corporation
  55.     Beaverton, Oregon
  56.     marcs@slc.com
  57.