Re: Configuration Files

I'm guessing that you mean something different when you say 'configuration' than what most people do. When I say 'configuration' I'm talking about something:

Small. The largest configuration file I've ever needed had around 50 values organized in 10 blocks. Apache configs usually come in around this size if you slice out all the defaults, for example.
Human readable and editable. Generally in an Apache-esque format using Config::ApacheFormat.
Not Performance Critical. Typically I'll load configuration data at Apache start-up and forget about it. It's just a hand-full of scalars and hashes, how bad could it be?

It sounds to me like you're dealing with a beast of a different stripe. You're storing data in a non-readable format and you're worried about memory size and access speed. So what are we really talking about? And what's all this noise about being more reliable than the database?

-sam

Comment on Re: Configuration Files

Replies are listed 'Best First'.
Re^2: Configuration Files by Mutant (Priest) on Nov 02, 2004 at 17:41 UTC
Yeah, fair point, I am talking about something different than a 'usual' configuration. What I'm working on is a generator of applications, each with a configuration stored in complex data structures. Maybe 'config's not even the correct term - it's really 'application data'. Human readable is not necessary (and possibly not even desirable) since the config is controlled by the meta-application. As for reliability, see the discussion in the replies above.	[reply]
Re^3: Configuration Files by samtregar (Abbot) on Nov 02, 2004 at 17:50 UTC
Ok, then I'm with the rest of the monks. You need a real database and you need one now. Trying to use Storable to house performance-critical application data is just going to lead to tears. It won't scale and it encourages a level of laziness that will quickly outrun your ability to manage change. It can be a nice way to prototype an application in a hurry but it's just not the right tool for your job. -sam	[reply]