home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / perl / 5748 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  2.1 KB
  1. Path: sparky!uunet!sun-barr!news2me.ebay.sun.com!jethro.Corp.Sun.COM!oogoody!tmhoff
  2. From: tmhoff@oogoody.Corp.Sun.COM (Todd Hoff)
  3. Newsgroups: comp.lang.perl
  4. Subject: Re: Using perl for databases - experiences req
  5. Date: 5 Sep 1992 18:41:53 GMT
  6. Organization: Sun Microsystems, Inc.
  7. Lines: 38
  8. Distribution: world
  9. Message-ID: <lahvrhINN169@jethro.Corp.Sun.COM>
  10. References: <1992Sep5.040819.2039@nugget.rmNUG.ORG>
  11. Reply-To: tmhoff@oogoody.Corp.Sun.COM
  12. NNTP-Posting-Host: oogoody.corp.sun.com
  13.  
  14. >The problem is that we now are in need of more than just bug databases.   
  15. >Specifically, we need a whole set of integrated databases to handle, bugs,  
  16. >tech-support contacts, technical issues, etc.
  17.  
  18. Which is why people use databases. The other reasons are a standard SQL
  19. interface, transactions, report writer tools, data dictionary, client/server support,
  20. superior speed, recovery mechanisms, mirroring, etc.. Your system looks cool, 
  21. but it realy isn't good enough for use by a general population of users and for continued expansion.
  22.  
  23. >1. Has anyone used perl to implement a multi-user database that handles  
  24. >thousands of records?  How well did it work?  Do you spend your whole life  
  25. >maintaining the thing.
  26.  
  27. I use a somewhat hacked version of sybperl for accessing Sybase. You get the
  28. best of both worlds then. 
  29.  
  30. >2. Does anyone know of a really bang-up bug/issue/call tracking database on any  
  31. >platform?  If there were such a thing in the PC world we could easily be  
  32. >convinced to put a PC on everyone's desk.
  33.  
  34. Wow, this is exactly what I'm working on, but not for PCs, although I do a lot
  35. work on DOS and some Windows programming.
  36.  
  37. >3. Where will my scheme break when I extend it from hundreds of records to  
  38. >thousands?
  39.  
  40. I would shudder to do a multitable join with a complicated projection using
  41. perl and the filesystem. 
  42.  
  43. >4. Other comments, experiences?
  44.  
  45. Think of the future. Go with a real database. Use a good interface builder
  46. and report writer. You can do a lot of your programming in perl. I'm also
  47. exploring the use of wafe with  perl and sybase for a really kick ass 
  48. development environment.
  49.  
  50.  
  51.  
  52.