home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / 8755 < prev    next >
Encoding:
Text File  |  1992-12-31  |  2.6 KB  |  55 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!rsoft!mindlink!a269
  3. From: Mischa_Sandberg@mindlink.bc.ca (Mischa Sandberg)
  4. Subject: Re: BLOBS (was: 500'000 records)
  5. Organization: MIND LINK! - British Columbia, Canada
  6. Date: Fri, 1 Jan 1993 04:10:11 GMT
  7. Message-ID: <19085@mindlink.bc.ca>
  8. Sender: news@deep.rsoft.bc.ca (Usenet)
  9. Lines: 44
  10.  
  11. > Hugh LaMaster writes:
  12. >                                    With 30K records, you are dealing
  13. > |> with blobs outside the normal record structure; you can run greater
  14. > |> risks.
  15. >
  16. > Is there a "correct" way to deal with this problem yet?  It can show
  17. > up in surprisingly simple DBMS applications, such as where you want to
  18. > search through a bunch of trouble calls for matches to a particular
  19. > problem.  1-2 years ago, when I inquired to this newsgroup, there was
  20. > no RDBMS that could handle text searches efficiently.  (Efficiently,
  21. > that is, compared to a text processing/retrieval system.)  Is this still
  22. > the case?
  23.  
  24. Seems to be still the case, among the mainstream database products.
  25. You might have some luck with middle-users (as opposed to end-users)
  26. such as those providing db's for, say, the publishing industry ---
  27. a wonderful source of solutions to problems that I, thank goodness,
  28. seldom see (think about how you store the articles and pictures in
  29. a magazine; this ad must NOT be near *that* ad, etc.) And, if you
  30. REALLY want to see the leading edge in OODB technology and really
  31. awesome record size and relationship problems, take a peek at
  32. where office automation systems are going (no, I'm being serious).
  33.  
  34. I agree, though, that really usable blobs would find instant use.
  35. We started off trying to move our E-Mail/CIM system into a standard
  36. SQL database. Turned out to be more hassle than the old system, which
  37. created (compressed) files in a standard unix directory and stored
  38. the filenames in the database; directories could be nested within
  39. directories; links could be made for multiple copies; etc.
  40.  
  41. The standard database, with 1970's technology for locking, journalling
  42. and space management isn't a very promising engine for such applications.
  43.  
  44. Pardon me: one exception: Revelation. With 1-64kb records as part of
  45. the basic file system,and extremely flexible dictionaries, AREV
  46. can probably handle just about anything you'd like to put on a PC
  47. or a LAN. But that's a rather limited domain.
  48. --
  49. Mischa Sandberg ... Mischa_Sandberg@mindlink.bc.ca
  50.                  or uunet!van-bc!rsoft!mindlink!Mischa_Sandberg
  51. *-*-*-*-*-*-*-*-*-*-*
  52. Engineers think equations are an approximation of reality.
  53. Physicists think reality is an approximation of the equations.
  54. Mathematicians never make the connection.
  55.