home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / database / 7915 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  3.6 KB
  1. Xref: sparky comp.databases:7915 comp.databases.ingres:1921 comp.databases.informix:2452 comp.databases.oracle:2230 comp.databases.sybase:337
  2. Newsgroups: comp.databases,comp.databases.ingres,comp.databases.informix,comp.databases.oracle,comp.databases.sybase
  3. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!nsisrv!stars.gsfc.nasa.gov!thompson
  4. From: thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
  5. Subject: Connectivity between databases
  6. Message-ID: <17NOV199217095298@stars.gsfc.nasa.gov>
  7. News-Software: VAX/VMS VNEWS 1.4-b1  
  8. Sender: usenet@nsisrv.gsfc.nasa.gov (Usenet)
  9. Nntp-Posting-Host: stars.gsfc.nasa.gov
  10. Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
  11. Distribution: usa
  12. Date: Tue, 17 Nov 1992 21:09:00 GMT
  13. Lines: 51
  14.  
  15. I'm currently in the market for a Unix RDBMS, and the selected software needs
  16. to be able to communicate with other people's databases which will probably be
  17. from other vendors (Oracle and Sybase for certain).  I was looking for insight
  18. as to how this would work, and whether people had any experience of how well
  19. the different database products work with other SQL databases.  I want to hear
  20. from users--I've already talked to the vendors.
  21.  
  22. What we would be doing would be to compare our databases against other people's
  23. databases.  The database would contain information about our scientific
  24. observations, and we would want to correlate our observations with the
  25. observations of other instruments--e.g. when were we pointed at the same
  26. target, etc.  The users would *not* be storing or updating any data in the
  27. remote database--just looking at it.  In fact, I don't really expect the user's
  28. to be writing to the local databases either, except for temporary tables used
  29. to store the results of queries.
  30.  
  31. However, the database software will only represent a small fraction of the
  32. activities that will be going on at our site (say 5-10%), so we don't want to
  33. put a lot of manpower into putting together a sophisticated distributed
  34. database.  We have also looked at transaction managers, and have decided that
  35. those would be inappropriate since they require that everything can be
  36. expressed in well-understood and predefined transactions--we want to keep a
  37. lot of flexibility open in the system.
  38.  
  39. It seems that there are several ways to go about it:
  40.  
  41.     1.  The local database software could spawn a shell script which starts
  42.         a session on the remote database which extracts the requested data
  43.         and writes it to one or more flat ASCII files.  These ASCII files
  44.         are then imported to temporary tables in the local database and
  45.         manipulated locally.  This probably would be sufficient for our
  46.         needs.  Also, if we did this we could probably use any database
  47.         package, since (I believe) any of them can spawn OS commands, and
  48.         import/export ASCII text files.  Does anybody have any experience
  49.         working this way, and can comment on how well it works?
  50.  
  51.     2.  We could use gateway products from one vendor to another.  I
  52.         believe this requires buying additional software for at least one
  53.         of the machines.  I don't know how well these gateways work, and
  54.         expect that the gateways from one vendor are different from those
  55.         from another vendor.  I'd be interested in hearing about people's
  56.         experiences with gateways from Oracle, Ingres, Sybase, Informix,
  57.         etc., and whether they think one is better than another.
  58.  
  59.     3.  We could use 3rd party front-ends which have their own gateways.  I
  60.         don't know much about this either--up to now I've only been
  61.         studying the problem of the back end.
  62.  
  63. Thank you in advance,
  64.  
  65. Bill Thompson
  66.