home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / database / 8029 < prev    next >
Encoding:
Text File  |  1992-11-22  |  3.5 KB  |  75 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!munnari.oz.au!manuel.anu.edu.au!sserve!ghm
  3. From: ghm@sserve.cc.adfa.oz.au (Geoff Miller)
  4. Subject: Re: DB Comparison - DISAPPOINTING RESULTS
  5. Message-ID: <1992Nov23.003743.1629@sserve.cc.adfa.oz.au>
  6. Organization: Australian Defence Force Academy, Canberra, Australia
  7. References: <168A2BF95.M22367@mwvm.mitre.org>
  8. Date: Mon, 23 Nov 1992 00:37:43 GMT
  9. Lines: 64
  10.  
  11. M22367@mwvm.mitre.org writes:
  12.  
  13. >Revelation - I worked with Rev/G for about 2 years.  It drove me right up a
  14. >      wall.  I managed to hack it into something reasonable, but I denounce
  15. >      what IMHO is an insurmountable design flaw - every field is variable
  16. >      length.  Rev fans no doubt are about to flame me, but consider: in most
  17. >      database applications, 90% of your data is of known *fixed* length or at
  18. >      least a reasonable maximum can be determined. The 'all variable' paradigm
  19. >      ignores this little fact of life with no profit.  I tried ARev v1 and
  20. >      found it overwhelmingly cumbersome.  Given the wide variety of reasonably
  21. >      good products on the market, I can't see investing the time in Revelation
  22. >      (zip up my Nomex suit for the flames-to-come).
  23.  
  24. (I was going to e-mail this, but I decided instead that it might be 
  25. worth opening up some discussion.)
  26.  
  27. The comments about ARev and variable fields apply to Pick variants in
  28. general.  I'm not going to flame, but merely enquire in a non-combustible
  29. manner why you see a particular problem with having fields with no
  30. defined fixed or maximum length?
  31.  
  32. I agree that many fields in database applications are of a definable
  33. fixed length (at any given time  -  the fields may change in length
  34. due to the introduction of a new coding system, for example), but I
  35. am far less convinced that it is easy to define a reasonable maximum.
  36. What happens when your "reasonable" value becomes "unreasonable"?
  37. How long does it take you to restructure your database?
  38.  
  39. Every time I have seen this tried I have seen it break.  Take the
  40. following cases  -  what do people consider to be reasonable maxima
  41. for them?
  42.  
  43. Surname
  44.  
  45. Address  (and if you break it up into separate fields, how many?)
  46.  
  47. Postcode  (don't forget to allow for overseas addresses)
  48.  
  49. Course Name
  50.  
  51. These are all specific items where I have been very glad that I have
  52. _not_ had to specify a specific maximum length in applications that I
  53. have worked on.  There is also the ability to include a comment field
  54. that can consist of as much text as the user wants to put in, rather 
  55. than having to worry (as I did with one other product) about how
  56. many characters per line and lines per paragraph to allow.
  57.  
  58. I certainly don't advocate Pick variants as the answer to every
  59. database problem  -  I do find it a very good environment for the
  60. kind of data where you require a very flexible structure.  To give
  61. a specific example  -  we have developed a database for our History
  62. department, covering a lot of data about Australians who served 
  63. overseas in WW1.  We have to some extent had to develop the structure
  64. of this database on the move, as problems have arisen during the
  65. data entry which we had not foreseen (and this was not bad planning  -
  66. you cannot check all the data sources for data on over 300,000 people
  67. to do a comprehensive analysis).  What we did do was ensure that we
  68. were working in an environment which would allow us to adapt the
  69. database easily, and we have (IMHO, and also in the opinion of the
  70. users) succeeded in this.
  71.  
  72. Geoff Miller (g-miller@adfa.oz.au)
  73. Computer Centre, Australian Defence Force Academy
  74.  
  75.