home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / database / 8461 < prev    next >
Encoding:
Internet Message Format  |  1992-12-12  |  2.2 KB
  1. Path: sparky!uunet!think.com!ames!pacbell.com!pacbell!osc!jgk
  2. From: jgk@osc.COM (Joe Keane)
  3. Newsgroups: comp.databases
  4. Subject: Re: DB Comparison - DISAPPOINTING RESULTS
  5. Summary: Fixed-size fields are bad.
  6. Keywords: length
  7. Message-ID: <5918@osc.COM>
  8. Date: 9 Dec 92 22:39:47 GMT
  9. References: <1992Nov23.003743.1629@sserve.cc.adfa.oz.au> <10286@blue.cis.pitt.edu.UUCP> <168B18556.M22367@mwvm.mitre.org>
  10. Reply-To: Joe Keane <jgk@osc.com>
  11. Organization: Versant Object Technology, Menlo Park, CA
  12. Lines: 42
  13. Weather: rain, high 55, low 46
  14. Moon-Phase: full
  15.  
  16. In article <168B18556.M22367@mwvm.mitre.org> M22367@mwvm.mitre.org writes:
  17. >Now, I know it's not just a personal problem ;-) about structure.
  18. >Look at your phonebook data -
  19. > 
  20. >Field         Length
  21. >-----------   ------
  22. >Last Name       40   (generous, but not loony)
  23. >First Name      20   (   "    ,  "   "    "  )
  24. >Street Addr1    30
  25. >Street Addr2    30
  26. >City            30
  27. >State            2
  28. >Zip              5
  29. >Ext Zip          4
  30. >Area Code        3
  31. >Phone Number     7
  32.  
  33. >Anything unreasonable about that?  You wind up with a record of fixed length
  34. >that can handle 99.99% of the data you will encounter.
  35.  
  36. Sorry, try again.  Your percentage is way too high.  The first and last names
  37. look safe, but you never know.  The street addresses are likely to break for
  38. some people.  The zip code is definitely not long enough, since ZIP+6 is just
  39. around the corner.  The phone number won't work at all for anyone outside the
  40. U.S. and Canada, but i guess that's OK for this application.  So that's one
  41. problem, your structure *will* break for some people, and they won't be happy.
  42.  
  43. However, the real problem with the fixed-size structure is that it wastes a
  44. lot of space.  Even though your structure only works sometimes, it still takes
  45. up a total of 171 bytes.  In contrast, a typical record will actually use
  46. around 60 bytes.  That means you're taking up *three times* as much space as
  47. you need.  Even considering some overhead for a variable-length field, they
  48. come out way ahead.
  49.  
  50. >My contention is that all-variable is not reason enough to buy Rev.
  51.  
  52. That's true, but providing only fixed-size fields is a good reason to not buy
  53. a product.
  54.  
  55. --
  56. Joe Keane, professional programmer
  57. jgk@osc.com (uunet!amdcad!osc!jgk)
  58.