home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / 8634 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  9.3 KB
  1. Path: sparky!uunet!pipex!bnr.co.uk!uknet!comlab.ox.ac.uk!oxuniv!mjl
  2. From: mjl@vax.oxford.ac.uk
  3. Newsgroups: comp.databases
  4. Subject: Cancer Research database: need advice.
  5. Message-ID: <1992Dec21.111601.10931@vax.oxford.ac.uk>
  6. Date: 21 Dec 92 11:16:00 GMT
  7. Organization: Oxford University VAX 6620
  8. Lines: 206
  9.  
  10. I wonder  if the  experience of the net could offer some opinions
  11. on our problems with finding a suitable database solution. I give
  12. below some background and experience so far.
  13.  
  14. For many  years my  Group(CCRG) has maintained a large 'database'
  15. consisting of  data on childhood cancer cases in UK, known as the
  16. National Registry  of Childhood  Tumours(NRCT). I  use ''  around
  17. database because  the data  is  held  in  a  sequential  'binary'
  18. formatted file  on our  VMS Vax.  Numeric data  is held in 4 byte
  19. integer format,  and most  character information is held in ASCII
  20. after  ciphering.  This  character    information  is  stored  as
  21. truncated delimited  strings. Thus  the space  used is  efficient
  22. with no wasted white space.
  23.  
  24. There are over 50,000 records: each has 160 4 byte integer values
  25. and 25  strings. The  integers cover  such data  as birth  dates,
  26. region codes  and medical  diagnostic codes.  The strings include
  27. normal names, addresses, postcodes(separately) etc.
  28.  
  29. This file  is  managed  by  means  of  several  third  generation
  30. language programs  which carry  out extensive  checking and  data
  31. validation. There  are probably  hundreds of  lines of code which
  32. can  be   drawn  upon   depending  what   is  being   altered  or
  33. added/deleted. This  is far  beyond the  typical range checks and
  34. simple rules which I believe can be built into most DBMS systems.
  35. Many of  the 160 variables can be inter-related, and even strings
  36. have to  be checked for validity, eg postcodes are quite complex.
  37. Checks between  the rows(cases)  do not  currently get  routinely
  38. performed in  the code, although we wish to do this in the future
  39. for checking  duplicate entries  etc. Currently this is done by a
  40. combination  of   interactive  searching(see  below)  and  manual
  41. methods. All  the programs  work  by  batch  running  data  files
  42. containing, often, large numbers of cases( eg 1000), which may be
  43. existing cases  being edited,  or new cases. This is the way CCRG
  44. validates and  maintains the  integrity of  the 'database'.  Case
  45. problems are  flagged and  dealt with  individually, possibly  by
  46. different people,  and then the job resubmitted, and only allowed
  47. onto the   datafile  when all  problems are  accounted for. Proof
  48. reading also  plays an  important part. The result is a data file
  49. of great  integrity, which could not be maintained by interactive
  50. _direct_ data entry alone. Much data entry is of course done into
  51. satellite databases which are then used to create the batch runs,
  52. but nothing goes into the real datafile until 100% verified.
  53.  
  54. CCRG wishes  to change  to the  use of  a proprietary database to
  55. replace the  entire reliance on 3rd generation language programs,
  56. and in particular to take advantage of DBMS query facilities. For
  57. example, we already are maintaining an INGRES database containing
  58. an exact  copy of the contents of the datafile. This allows us to
  59. test out  use of  Ingres for  queries in  parallel with  the  old
  60. system. Although  we used  3rd generation programs in the past to
  61. do case selection etc for research, the ability to run simple SQL
  62. queries on  the  data,  AND  do  interactive  searching  is  very
  63. welcome. Currently  the data  on file is still _managed_ with the
  64. 3rd generation  programs, and  data recopied  across to INGRES at
  65. intervals.
  66.  
  67. This is where we have found problems which seem to be inherent in
  68. SQL or  Ingres, and  which make  us think that Ingres( or SQL) is
  69. not the  best answer.  In fact, I am now forming the opinion that
  70. using Ingres  would be so restrictive that we would be better re-
  71. writing the  3rd  generation  programs  (which  incidentally  are
  72. written in  Algol68. Algol68,  although laughed off by many as an
  73. obsolete joke,  is in fact a very powerful language on a par with
  74. structured languages  like C,  but scorned  since it  is  out  of
  75. fashion).
  76.  
  77. Some of the problems we found with Ingres are:
  78.  
  79. 1)   The complex  type of  queries we would often write with ease
  80.      in Algol  become totally  bogged down  using  SQL.  All  the
  81.      advice points  to approaching  the query a different way. So
  82.      we rewrite  our  nice  Boolean  based  Algol  code  creating
  83.      temporary tables  all over the place willy-nilly. This seems
  84.      to be  hopelessly unwieldy, and it is extremely inefficient.
  85.      SQL seems  to be  far too  weak a  tool to  replace our  3rd
  86.      generation queries.  We have also got incorrect results from
  87.      particular approaches,  something which we never experienced
  88.      with  Algol68!  It  had  bugs  but  did  not  return  subtle
  89.      inaccuracies. (see recent Subject 'HELP! SQL Ingres problem'
  90.      in Comp.Databases.Ingres)  Our users  have to  have complete
  91.      confidence in the database accuracy of course.
  92.  
  93. 2)   A user  creating a  table  cannot  himself  make  his  table
  94.      accessable to  anyone else.  The DBA  cannot do this either,
  95.      the table must be recreated by the DBA.
  96.  
  97. 3)   On VMS  anyway, there  is no  way  of  controlling  the  CPU
  98.      resources used  by a  batch running SQL job. Our queues have
  99.      CPU limits but the server simply carries on regardless. Thus
  100.      a bogged down user job(of which there are plenty) can sit in
  101.      a queue monopolising it, and the server, for hours.
  102.  
  103. 4)   SQL just  does not  seem to  be designed  to be  used  in  a
  104.      research type  environment where serious large queries, many
  105.      of which must be batch run, occur
  106.  
  107. 5)   There is  a gap,  from the  point of  view  of  easy  report
  108.      writing, between the simplicity of SQL and the complexity of
  109.      writing a Report. A user needs better control over a default
  110.      report layout.  This can  be worked  around, if  rather  in-
  111.      ellegantly, through ESQL.
  112.  
  113. Of course,  I have not mentioned the obvious disadvantages of the
  114. vast amount   of  extra space  required by Ingres tables. Whereas
  115. the datafile  took up about  30 Mb; the Ingres version uses 80Mb.
  116. Some of  this is  attributable to  many   string slots  which are
  117. partially empty.  The length  of one  string  variable  can  vary
  118. between zero  and 60  in some  cases, with  an average of say 25.
  119. This could be improved by a different breakdown of tables.
  120.  
  121. My question is this.
  122.  
  123. Does anyone  with experience of other SIMILAR Size databases in a
  124. research environment  have any  suggestions for  what alternative
  125. dbms we should look at and why?. This should be in the context of
  126. our main problems as I see them:
  127.  
  128. 1    Complex queries  are not  at all  uncommon, see long example
  129.      below. Should be PROVEN for this type of work.
  130.  
  131. 2    Batch running as well as interactive queries essential
  132.  
  133. 3    Must integrate  with  a  3rd  generation  language  for  the
  134.      integrity checking,  unless someone  can suggest  a DBMS  so
  135.      good it can handle this sort of thing.
  136.  
  137. Any suggestions should be for _relational_ systems.  Although we 
  138. really would prefer something which will run under VMS, I  would
  139. not impose that as a definite restriction if all else was viable.
  140.  
  141. Many thanks in advance for any suggestions.
  142.  
  143. Martin Loach
  144. Childhood Cancer Research Group
  145. University of Oxford
  146. England
  147.  
  148. e-mail MJL@UK.AC.OXFORD.CHILD-CANCER-RESEARCH
  149.  
  150.  
  151. Below, by  way of  reference, I  give an  example  complex  query
  152. showing the sort of functionality we need, not that infrequently.
  153.  
  154. ----------------------------cut here--------------------------
  155.  
  156. IF
  157. BOOL flag code ok := v[nhscr flag] < 1;
  158. BOOL carcinoid app :=
  159.    IF v[med type icdo] /= -1 AND v[med type icdo] % 100 = 824
  160.    AND (v[med site icdo] % 10 = 159 OR v[med site icdo] = 1535)
  161.    THEN TRUE
  162.    ELSE FALSE
  163.    FI;
  164. BOOL nat :=
  165.    IF v[newdiaganniv] = 141 THEN TRUE
  166.    ELSE FALSE
  167.    FI;
  168. BOOL ca app or nat := carcinoid app OR nat;
  169. BOOL is a scots case :=
  170.    IF v[registry] >= 21 AND v[registry] <= 25
  171.    THEN TRUE
  172.    ELIF v[registry] /= -1
  173.    THEN FALSE
  174.    ELIF is a scots hospital(v[trtmt centre])
  175.    THEN TRUE
  176.    ELIF is a scots hospital(v[uk reg hosp])
  177.    THEN TRUE
  178.    ELSE {NOT a Scots Trial or UKCCSG case, so . . . } FALSE
  179.    FI;
  180. BOOL pre 71 alive not flag 0 := v[anniv year] < 71
  181. AND v[anniv year] /= -1
  182. AND v[death year] = -1 AND v[nhscr flag] /= 0;
  183. BOOL foreign ukccsg only := v[residence] /= -1
  184. AND v[residence] /= "EWS" AND v[residence] /= "BFPO" ;
  185. BOOL is 71 to 87 := IF 71 <= v[anniv year]
  186. AND v[anniv year] <= 87 THEN TRUE
  187.    ELIF v[anniv year] /= -1 THEN FALSE
  188.    ELSE 71 <= v[diag year] AND v[diag year] <= 87
  189.    FI;
  190. BOOL is 71 to 87 without dc := is 71 to 87
  191. AND v[dc status] = -1;
  192. BOOL dc with poor birth date:=
  193.    v[birth day] = -1 AND v[death year] > 69
  194. AND v[dc status] /= -1 ;
  195. BOOL pre 71 := IF v[anniv year] /= -1
  196. AND v[anniv year] < 71 THEN TRUE
  197.    ELIF v[anniv year] >= 71 THEN FALSE
  198.    ELSE  { anniv year = -1 so . . . }  v[diag year] < 71
  199.    AND v[diag year] /= -1
  200.    FI;
  201. BOOL pre 71 with 71 on death over 14 := pre 71
  202.      AND v[death year] >= 71
  203.      AND v[age at death] > 14;
  204. NOT is a scots case AND flag code ok AND NOT ca app or nat
  205.    AND NOT foreign ukccsg only
  206.    AND(is 71 to 87 without dc OR dc with poor birth date
  207.    OR pre 71 with 71 on death over 14
  208.        OR pre 71 alive not flag 0)
  209. THEN
  210.  
  211. {list etc}
  212.  
  213.  
  214. Note- things like 'is a scots hospital' are already defined
  215. elsewhere for common use.
  216.