Re: Re: algorithm help for determining efficient db data retrieval

in reply to Re: algorithm help for determining efficient db data retrieval
in thread algorithm help for determining efficient db data retrieval

Well, it's good to know that transferring a little vs a lot isn't a huge issue. That I did not know. I'm less concerned with my ability to pull some or all of a single object's properties than i am with the possibility of having to pull a small set of properties for say 400 objects, but then wanting a larger set of properties for 10 of them. While each object may be fairly lightweight (say a few hundred to a thousand Kbytes), i'm worried what happens when i've got to deal with objects en masse.

I am aware of Storable and FreezeThaw, but at least for the time being a relational database is best for me because it allows for robust searching out of the box, and is a platform for modeling relationships between objects.

That said though, i fully appreciate the warning about digging that hole

Comment on Re: Re: algorithm help for determining efficient db data retrieval

Replies are listed 'Best First'.
Re: Re: Re: algorithm help for determining efficient db data retrieval by tachyon (Chancellor) on Apr 06, 2004 at 03:06 UTC
If by efficiency you mean speed the simple fact is that you spend memry to get more speed. Accessing a DB (on disk) is slow compared to accessing data in memory. You can spend memory in two ways. Give your DB huge ammounts of memory to cache disk pages and indices (so it does not have to hit the disks as often) or simply pull all the data you need into memory one pass. With RAM priced at a few hundred bucks a GB and programmer time to code a more memory efficient solution at a similar level per day there is a very good business case for throwing lots more memory at a problem to save code complexity and thus programmer time and debugging time and future maintenance issues. Perl loves lots of memory. So do RDBMS. If you are doing much work with either a small investment on more RAM has long term wide ranging benefits. cheers tachyon	[reply]

Replies are listed 'Best First'.

Re: Re: Re: algorithm help for determining efficient db data retrieval
by tachyon (Chancellor) on Apr 06, 2004 at 03:06 UTC

If by efficiency you mean speed the simple fact is that you spend memry to get more speed. Accessing a DB (on disk) is slow compared to accessing data in memory. You can spend memory in two ways. Give your DB huge ammounts of memory to cache disk pages and indices (so it does not have to hit the disks as often) or simply pull all the data you need into memory one pass. With RAM priced at a few hundred bucks a GB and programmer time to code a more memory efficient solution at a similar level per day there is a very good business case for throwing lots more memory at a problem to save code complexity and thus programmer time and debugging time and future maintenance issues.

Perl loves lots of memory. So do RDBMS. If you are doing much work with either a small investment on more RAM has long term wide ranging benefits.

cheers

tachyon

[reply]

In Section Seekers of Perl Wisdom