Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re: Selecting the right database for perl

by Abigail-II (Bishop)
on Aug 19, 2003 at 21:13 UTC ( [id://285038]=note: print w/replies, xml ) Need Help??


in reply to Selecting the right database for perl

100,000 rows, 20 columns with at most 20 chars per column? That's only 40 Mb of data. The only reason you might need a database is for its transactional support. But 40 Mb of data is enough to keep in memory on a modern day low entry box.

But if you get more data, or if your data is highly volotile, you might want to use a database. But which database is appropriate doesn't depend on the fact you happen to work with Perl. It depends on your data. How much data, what are you going to do with it, how intensive is it accessed/modified, how fast does it need to be, how much support is needed, how much can you spend on a license. Those are important question, that's what determines your database. Perl will happily interface with almost all databases. Don't let Perl determine your database, let your data determine it. Perl will adapt.

Abigail

  • Comment on Re: Selecting the right database for perl

Replies are listed 'Best First'.
Re: Re: Selecting the right database for perl
by waswas-fng (Curate) on Aug 19, 2003 at 21:36 UTC
    Build it into hashes and arrays in perl and it will pop up to at least 100mb, get sloppy and copy instead of use refs and you can grow that amount very qucikly and cause big slowdowns. modify in memory and delay writes to disk and you can kiss it goodbye on poweroutage/system crash. Even though it may be possible (or even prudent) to do it in all memory understand the risks and problems you may be up against. If you have oracle/sybase/ms-sql licenses use what you have, else there are free databases such as mysql and postgres.

    -Waswas
      modify in memory and delay writes to disk and you can kiss it goodbye on poweroutage/system crash.

      I took an exception on transaction support. He didn't specify what kind of database he needs - if it's being modified heavily, you want to have something that makes sure no data gets lost on a crash. But if all he does is querying, having it all in memory is what you want.

      Abigail

        This is not going to be heavily modified by any means. Adding records will occur at a specific time each day. From that point on it is mostly a query and calculations of the data gathered, and then throwing results into an output file that will be read by a person.

        It is the calculations that I will do that worry me about memory.

Re: Re: Selecting the right database for perl
by bean (Monk) on Aug 19, 2003 at 21:35 UTC
    If you decide to keep it in memory, check out Tie::Persistent.
    Update
    However, I'd suggest using MySQL - it's free, fast, and an excellent choice for simple database applications. Easy to administrate too (another thing to consider).

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://285038]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (5)
As of 2024-04-16 05:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found