Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: Databases and tied hashes.

by AgentM (Curate)
on Feb 11, 2001 at 05:54 UTC ( #57687=note: print w/replies, xml ) Need Help??


in reply to Databases and tied hashes.

Definitely go with a real SQL server like MySQL. For your intentions, this file-based DB is simply not extensible enough. The standard DBFile engines have a pretty much similar routine: tie the file in, read and write hashes loading them on demand with zero amortization- that means, while they are simple to set up and use, their use really burns out at more than a few users, especially since no more than one user can access the DBFile at a time! (As far as I know, none of them implement record locking.) I see this as as a case of "I see no choice but to upgrade my existing systems to something that will be scalable enough to handle the load." Good luck!

Update: Yes, tilly. Very good, tilly. Next time read the main node and make sure that what you say is relevant- e.g. ala GDBM.

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

Replies are listed 'Best First'.
Re (tilly) 2: Databases and tied hashes.
by tilly (Archbishop) on Feb 11, 2001 at 07:53 UTC
    Please stop spreading FUD. Something doesn't have to have a SQL interface to be powerful. Berkeley DB supports applications with multi-threaded concurrent read-write access to databases of hundreds of terabytes at rates of over 30,000 accesses per second. Much of this native functionality is not available through the DB_File interface, but it is through BerkeleyDB.

    Now if you care about the complexity of your data model, then MySQL wins. If you care about preserving your data, in my professional opinion a good dbm used properly is as good or even a better choice than MySQL. If you want both, then you can use Postgres, Oracle, etc. But while I admit that the tied Perl interface is not the snappiest (though as some have discovered, it is pretty good), I do not believe that for straight lookups you are going to find any relational database that will beat a C application using Berkeley DB. It ain't going to happen, and it ain't going to happen for a lot of reasons.

    So unless you know something about scalability that I, Sendmail, Cisco, Ask Jeeves et al don't, please don't fall into the trap of thinking that dbms are just lightweight toys.

    For more information I suggest you visit Sleepycat Software.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://57687]
help
Chatterbox?
[Cosmic37]: I have 2 files each with datetime and other data in unknown order and I want to find rows from both files matching by datetime and output them combined/ concatenated
[Corion]: Sure
[Corion]: Do you have any specific interests or general Perl knowledge?
[Cosmic37]: should I slurp? should I grep? Noble Lords I wish you good karma and beg your advice
[Corion]: Cosmic37: Ah, see perlfaq4, about How do I compute the intersection of two arrays
[Cosmic37]: I am out of practice; I use Perl for scientific programming for number crunching
[Corion]: Cosmic37: Basically, you read one file into a hash, keyed by your key, and then match the lines from the second file to that hash
[Cosmic37]: note that the two files only have datetimes which may match whereas other data per line is different format in file1 and file2 - is that really intersection?
[jedikaiti]: Hi Monks
[Corion]: Cosmic37: Well, if you want to use only parts of a line for the key, see split or whatever other mechanism to extract the key from the line

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (8)
As of 2017-06-29 16:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How many monitors do you use while coding?















    Results (672 votes). Check out past polls.