home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / database / ingres / 1941 < prev    next >
Encoding:
Text File  |  1992-11-19  |  3.4 KB  |  66 lines
  1. Xref: sparky comp.databases.ingres:1941 comp.databases.sybase:363 comp.databases:7954
  2. Newsgroups: comp.databases.ingres,comp.databases.sybase,comp.databases
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!gsbacd.uchicago.edu!cs_mj
  4. From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
  5. Subject: re: Validating data imported from text files.
  6. Message-ID: <1992Nov19.134218.1@gsbacd.uchicago.edu>
  7. Lines: 54
  8. Sender: news@uchinews.uchicago.edu (News System)
  9. Organization:     
  10. Date: Thu, 19 Nov 1992 19:42:18 GMT
  11.  
  12. In <18NOV199217192059@stars.gsfc.nasa.gov>, thompson@stars.gsfc.nasa.gov
  13. (William Thompson, code 682.1, x2040) writes:
  14.  
  15. > I was just told something startling.  In an E-mail message from Myron China
  16. > <mryo@ind_maroon.gwl.com>, I was told
  17. > 
  18. >    problem with flat file xfers is verifying successful completions of both
  19. >    the dump and the import.  oracle products, for instance, always signal 
  20. >    a 0 return code whether or not it had a problem.  so you end up spooling
  21. >    log files and checking them for errors yourself.  we also check file
  22. >    record layouts for validity before anything goes through.
  23. > 
  24. > That's an astonishing statement to me!  Our current plan calls for *ALL* data
  25. > imported into the database to come from flat ASCII files generated by other
  26. > programs.  Populating the database is supposed to be an automatic process that
  27. > works unattended.  Problems are supposed to be signalled when they occur.
  28. > 
  29. > Is this the same with the other major SQL databases: Ingres, Sybase, Informix?
  30.  
  31. I can only speak for INGRES.  I think this reflects a bias in relational
  32. databases in general and SQL in particular towards small transactions. 
  33. In INGRES, bulk loads from flat files (using the SQL "copy table"
  34. statement) are optimized for fast operation.  This means that, in
  35. particular, all integrities on the table are ignored.  So you could end
  36. up with data in the table that violates the integrities.  I think that
  37. there are other properties of a table that are ignored by "copy", but
  38. I'm not sure which ones (possibly unique indexes, enforcement of
  39. noduplicates, or triggers and rules).
  40.  
  41. However, INGRES _is_ smart enough to detect certain kinds of errors, and
  42. has options for (1) aborting the whole operation on the first error, or
  43. after n errors; (2) continuing on errors and writing the bad input
  44. records to another file.  If you choose the abort option (the default),
  45. then I'm pretty sure that the "copy" statement returns an SQL error code
  46. in the SQLCODE if there's an error.
  47.  
  48. Ingres recommends changing the storage structure of your tables to heap
  49. (no index) before loading them with "copy table", and only _then_
  50. applying indexing, integrities, etc.
  51.  
  52. If you want the full power of the database for enforcing rigid rules on
  53. the data, then you will have to write a program to load the data one row
  54. at a time, using the SQL "insert" statement instead.  This will give you
  55. full error handling and assurance that what's in the table is what you
  56. expect.  If you use INGRES's repeated queries, or database procedures,
  57. the performance may not be bad either.  It would be interesting to do a
  58. benchmark comparison of these.
  59.  
  60. --Mark Jaeger                internet: cs_mj@gsbvax.uchicago.edu
  61. Graduate School of Business        yellnet:  (312) 702-0328
  62. University of Chicago            faxnet:   (312) 702-0233
  63. Disclaimer: My opinions are my own and not those of my employer.
  64. Ich bin ein Virus.  Mach' mit und kopiere mich in Deine .signature.
  65.  
  66.