home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / database / 8521 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  3.0 KB
  1. From: Bruce.Feist@f615.n109.z1.fidonet.org (Bruce Feist)
  2. Sender: Uucp@blkcat.UUCP
  3. Path: sparky!uunet!blkcat!Uucp
  4. Newsgroups: comp.databases
  5. Subject: Logical design experiences?
  6. Message-ID: <724514440.AA00000@blkcat.UUCP>
  7. Date: Wed, 16 Dec 1992 07:21:26 -0500
  8. Lines: 56
  9.  
  10. Hi, Mark;
  11.  
  12.  g> Please tell me of any positive or negative experiences you
  13.  g> have had with developing databases with or without quality logical
  14.  g> designs.  Any stories would be more than welcome.  If you know of any
  15.  g> studies along these lines, please let me know.  Thank you very much.
  16.  
  17. Ah, the tales I can tell...  I can think of three offhand.  Here goes...
  18.  
  19. Story the First:
  20.  
  21. Organizational units could have any *one* of three possible types of code
  22. associated with them.  There are overlapping values between the codes (for
  23. instance, 'X' might be valid for both a type 1 code and a type 2 code).  Users
  24. tend not to think about there being separate types codes, though.
  25.  
  26. In an old design, there were *four* code fields: a generic one, plus one for
  27. each of the three types (only the correct one was to be filled out).  Which one
  28. was filled out indicated the type of code; the 'generic' one was there, I
  29. believe to simplify indexing.
  30.  
  31. I was asked to help in a redesign.  I pointed out that the current design was a
  32. structure; what if a berserk program filled out *two* of the type-specific
  33. fields, or none at all?  It would be better to store a single code value, along
  34. with an indicator specifying what type of code was being stored.  The original
  35. designer explained that in practice that would never happen.
  36.  
  37. I then looked at the data.  It had *already* happened.  My proposed change went
  38. through.
  39.  
  40. Story the Second:
  41.  
  42. Same system.  Organizational units can have two addresses -- a home address and
  43. and a current one (they move around).  This suggested to me that other addresses
  44. might be useful in the future -- possibly an address for a standard training
  45. site, for instance.  I proposed normalizing the location information out into
  46. another table.  The original designer explained that there was no way that more
  47. than these two locations would ever be required.  The project manager called in
  48. a user later during the meeting; he mentioned in passing that they were thinking
  49. about storing a third type of location.
  50.  
  51. Story the Third:
  52.  
  53. Different portion of the same system; this happened in the personnel portion.
  54. Normalization resulted in many (call it 20) tables to describe personnel.  For
  55. 'efficiency', the original designer (same fellow as above) decided to include a
  56. status flag in each of them; the idea was that this would speed up selection. In
  57. practice, it has turned out that queries almost invariably specify a single
  58. master table (possibly joined with others), which is where the status flag
  59. really belongs.  So, there is minimal speedup in queries -- but their update
  60. program, which must frequently update the status flag, takes 12 hours or so to
  61. run -- roughly 20 times longer than necessary.  As far as I know, the status
  62. flags are in synch from table to table -- but I wouldn't bet on it.
  63.  
  64. Bruce
  65.  
  66.