[development] Variables, lookups, and memory usage

[Donald A. Lobo]

with civicrm we've gone back-n-forth with what model
to use for various settings. We store all settings in
the DB (makes it easier to configure/tweak/translate
etc).

However, we ended up going down the road of creating
different tables for each setting (quite a few of the
tables share the same code). Probably the big factor
was the minor variation each setting had which needed
to be accomodated rather than shoe-horned into one
generic table. a good example is:

most settings just need: name , is_active, is_reserved

a few like state/country also need additional
attributes like:

abbreviate, country_id (for state)
idd_prefix, ndd_prefix (dialing code prefixes for
country), iso_code etc

ultimately we decided to go with seperate tables. In
retrospect, i would probably combine the table for the
generic case (which we'll probably do in 1.4) which
match the need exactly and keep the specific ones in
seperate tables

lobo

 
--- Allie Micka <allie at pajunas.com> wrote:

> >> I think discussed adding "domains" to the
> variable table a while back
> >> on this list.
> >
> > Yes,. It was actually the first test DEP that I
> wrote. You can  
> > probably search the mailing list for it.
> 
> I admit I didn't take the time to absorb it fully,
> but It seems that  
> the cascading variable system is about values and
> overriding them  
> (think vertical),  where the lookup stuff is more
> about segmenting/ 
> grouping data (think horizontal)
> 
> I could be convinced that they're the same thing,
> but right now I  
> feel like they're different.  Storing
> states/countries/etc in lookup  
> makes it a completely separate function from
> variables.  But I  
> considered storing expensive module settings here,
> got into a grey  
> area, and came here for advice.
> 
> To clarify, my main goal is to store settings while
> reducing memory  
> consumption by not loading values on every page
> load.  I'm inclined  
> to go with a component module for now as a proof of
> concept, but  
> input on making my strategy more
> generic/core-friendly is welcome.
> 
> Mostly, I need to finish up these dependent modules
> soon, and I'd  
> rather move forward than discuss it ad nauseum. 
> With this list's  
> input, I hope to move forward in a more
> informed/holistic way.
> 
> > I look forward to seeing you in february. I am
> seeing you in  
> > febs ,right ?
> 
> I'm sure gonna try!
> 
> 
> Allie Micka
> pajunas interactive, inc.
> http://www.pajunas.com
> 
> scalable web hosting and open source strategies
> 
>