One other thing that I use DBD::CSV for is configuration. I maintain a system which has multiple users each with a profile. I maintain a separate directory for each user with CSV files in it. I can "connect" to the particular user's database easily at the start of the process.
-----Original Message----- From: Jeff Zucker [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 8:45 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Performance of CSV Databases [EMAIL PROTECTED] wrote: >in some cases one don't need really high performance but a well >organized place to store data. In this case DBD::CSV may could >be the solution. But what happens if the amount of data grows? > When the data grows, you can easily migrate from DBD::CSV to any other DBD. You can use DBD::CSV itself to help load the data into the new system and your scripts won't have to change very much since DBDs work pretty much (with exceptions) the same. >Is there any performance comparision between DBD::CSV based >applications and others (like DBD::Oracle or so)? > There's no shadow of a doubt, for large, complex data, Oracle , or PostgreSQL, or MySQL, or any of the others are faster and better. But for a few dozen tables with a few thousand rows, DBD::CSV can be quicker in some circumstances (e.g. where you have to connect to the server for each request, DBD::CSV is faster than the others at the actual connection). DBD::CSV and its cousin DBD::AnyData (which does CSV, XML, Fixed Length, and many other kinds of formats) can be great tools for prototyping applications since you can set up some basic tables and relations quite easily. The strengths of these two are: 1) being good prototyping tools 2) being able to handle existing data, 3) being able to create portable data files that can be moved from one platform to another without change, 4) being able to create human-readable data files 5) not requiring installation of a separate rdbms. If those kind of things are not of concern, then, by all means, go straight to PostgreSQL or one of the big players or, for something quick and easy, try SQLite. [disclaimer: I'm prejudiced since I maintain DBD::CSV and DBD::AnyData] -- Jeff
