home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / perl / 5745 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  4.9 KB
  1. Path: sparky!uunet!sun-barr!ames!purdue!yuma!csn!nugget.rmNUG.ORG!nugget.rmNUG.ORG!scott
  2. From: scott@corybant.rmnug.org (Scott Meyer)
  3. Newsgroups: comp.lang.perl
  4. Subject: Using perl for databases - experiences requested
  5. Keywords: database
  6. Message-ID: <1992Sep5.040819.2039@nugget.rmNUG.ORG>
  7. Date: 5 Sep 92 04:08:19 GMT
  8. Sender: scott@nugget.rmNUG.ORG
  9. Organization: Rocky Mountain NeXT Users' Group
  10. Lines: 96
  11.  
  12.  
  13. My question is this:
  14.  
  15. What sort of experience have people had using perl to implement databases?   
  16. What pitfalls (performance, etc.) have been discovered, how were they  
  17. surmounted.  The motivation for this posting is my need to decide between  
  18. continuing with an ad hoc perl-based approach (which has been quite effective  
  19. to date) or scrapping it and going with a commercial solution.  Unfortunately,  
  20. things seem to be pretty polarized between those who refuse to consider  
  21. anything other than a "real" database and those who can't conceive of a reason  
  22. not to use a bunch of scripts... :-(
  23.  
  24. To guide the discussion a little bit, I'll describe the database that
  25. I have implemented in perl.  Basically, about 8 months ago, I needed a system  
  26. to keep track of bugs (sad but true).  Begin familiar with perl and unix tools,  
  27. I was able to cobble together a database which solved my problems and did so  
  28. nicely enough that most of the other developers at work adopted it too.   
  29. Basically, each bug (read record) was kept in a separate file under RCS.  The  
  30. name of the file (a number) was the bug id.  Inside the file, things looked  
  31. something like this:
  32.  
  33. %{  # beginning of record
  34. %STATE open   # the bug is open
  35. %TITLE This is a sample bug
  36. %DESCRIPTION
  37.     This is a description of the sample bug, it can go on
  38.     for several lines and may contain arbitrarily formatted
  39.     ASCII text
  40. %END_DESCRIPTION
  41. ... # lots more fields elided
  42. %}  #end of record
  43.  
  44. The way in which one could parse this stuff using perl is fairly obvious: in  
  45. perl the record is just a set of variables, $bug_state, $bug_description, etc.
  46. when you parse the beginning-of-record sentinal, these variables are set to
  47. their default values, as records are read, the field is parsed and the  
  48. corresponding variable set.  At the end of the record, all the record variables  
  49. are set and the program gets to do whatever it wants to with the record  
  50. (usually write it out or discard it based on some criteria).  Reading a record  
  51. is encapsulated by a function called get_rec which retreives the next record on  
  52. the input stream, writing by a function called put_rec which writes the current  
  53. record out (to standard output).
  54.  
  55. Using this basic read/write functionality, it is easy to construct filters  and  
  56. formatters which can be piped together.  The pipe
  57.  
  58.     dump_bdb | f_open | f_after 92 08 01 | fmt_brief
  59.  
  60. would create a brief report of all open bugs filed after August 1, 1992.  The  
  61. filters represent ANDs in the query.  One can use back quotes (or temp files)  
  62. to handle ors.  The filter mechanism is not particularly fast but can generate  
  63. moderately complex reports from a database with several hundred records in a  
  64. matter of seconds.  There is plenty of room for optimization (using assoc.  
  65. arrays or linking "interesting" records (files remember) into separate  
  66. directories so it seems like this scheme could be made to work reasonably well  
  67. for thousands of records.  Modifying records is very simple, just check out the  
  68. file and edit it.  There are convenience scripts that make certain  
  69. modifications automatically or allow you to edit only certain fields.
  70.  
  71. The problem is that we now are in need of more than just bug databases.   
  72. Specifically, we need a whole set of integrated databases to handle, bugs,  
  73. tech-support contacts, technical issues, etc.
  74.  
  75. The commercial systems I have seen are far from plug-and-play, are hard to  
  76. change (add a new field, etc.), and are decidedly unix-hostile (no more grep,  
  77. vi, etc.).  The up-side is that they can be much more powerful (nice gui  
  78. interface, very tight integration) than my home-brew, and, they are implemented  
  79. by *someone else* (I have no intention of spending my life maintaining  
  80. databases).
  81.  
  82. So, I have lots of questions:
  83.  
  84. 1. Has anyone used perl to implement a multi-user database that handles  
  85. thousands of records?  How well did it work?  Do you spend your whole life  
  86. maintaining the thing.
  87.  
  88. 2. Does anyone know of a really bang-up bug/issue/call tracking database on any  
  89. platform?  If there were such a thing in the PC world we could easily be  
  90. convinced to put a PC on everyone's desk.
  91.  
  92. 3. Where will my scheme break when I extend it from hundreds of records to  
  93. thousands?
  94.  
  95. 4. Other comments, experiences?
  96.  
  97. Please email me, I'll summarize responses.
  98. Thanks in advance,
  99.  
  100. -Scott
  101.  
  102. PS. If anyone wants my current bug DB code, this can probably be arranged.   
  103. Before everyone requests it, I should point out that it is really very simple  
  104. and probably quite boring reading to boot.
  105. -- 
  106. Scott Meyer
  107. scott@corybant.rmNUG.ORG - NeXT mail is welcome.
  108.