On Thu, 20 Feb 2003, Wiggins d'Anconia wrote: > Date: Thu, 20 Feb 2003 19:08:51 -0500 > From: Wiggins d'Anconia <[EMAIL PROTECTED]> > To: John Baker <[EMAIL PROTECTED]> > Cc: Colin Johnstone <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: Text file or database > > John Baker wrote: > > A work-mate of mine and were having the same discussion recently. > > I'm not a big fan of dbases, but maybe that's because I don't have > > to be...yet. > > > > A couple things that could factor when considering dbases: > > 1. speed > > 2. additional middleware technology > > > > Is the speed of accessing dbase info more efficient than > > text files with regexes? > > > Much for large amounts of data. > That was the implicit conclusion my work-mate and I came to, basically.
> 200 e-mail addresses, probably not. > Agreed. > > Also when you implement dbase (middleware) code, you've > > added an additional layer of complexity. And another > > technology to learn, and I'm all about adapting to > > technology, but I'm more a fan of the KISS principle. =) > > > > Ah the beauty of DBI. Write the Perl code once in DBI then just change > one line of code no matter what OS or DB you are using. > > To the original question.... > > 1 word. Network. What happens when all of a sudden your data has to be > stored on a different server, but your application stays put. Sure > there is NFS, but then your security could be shot to hell and your > speed really drops. Or multiple users are hitting the resource at the > same time? Have you built in all of the proper locking, etc. Or > multiple local users have to access the same resource with the proper > locking, etc. better make sure those permissions are correct, etc. > 1 word. CVS. One app aggregates the data feeds it into CVS and other machines pull down the tree. > Point being there is a reason why you chose Perl in the first place, > because it was probably written by someone who knew more than you, or at > the very least more people had the chance to look at it and work on it > so it is far more likely to catch all of the little things that take the > most time to handle and that end up coming back to bite you later. If > flat text files is the way to go for you, > say because your boss who > can't seem to work his e-mail wants (thinks he wants) to make a change, > then by all means check out DBD::CSV, etc. > Hmm, no comment, my boss might be subscribed to this list. =) > Then later when he leaves > for the weekend, install a real DB, change a couple lines of code, and > when he comes back, make up a story about insecurity of the old system > and why you should get a raise ;-)... > Point taken. There are some situations where DBs, particularly DBI, are useful; others, they're not. > Always use a DB? No, those 6 configuration values you don't want to hard > code using constants that only change every 6 months, sure, throw them > in a text file and forget about it. Production data...well hopefully not > mine. > Or if you have 500+ production devices and want to store each of their configs in seperate text files instead of adding an additional layer of complexity with a DB (http://www.shrubbery.net/rancid/). jab -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
