Best Practices for Global Variables?

I have a Rails application that manages several websites. Each site
has certain variables specific to that site. For example:

Sites

title = My Bookstore
domain = mybookstore.com
subtitle = Selling books since 1985
google_merchant_id = 03248203840329
google_merchant_key = 2039488lskdfj23498
show_prices = 1

title = My Parts Warehouse
domain = mypartswarehouse.com
subtitle = We have the parts you need
google_merchant_id = 242039483098899
google_merchat_key = 223j3ga4f3j4677jh
show_prices = 0

And so on.

Currently I’m storing all of this in the ‘sites’ table and hitting the
database for it on every page. I imagine the table will grow to 50 or
100 columns, with the various site settings I’ll need.

Does anyone have any opinion of a better place to store this stuff?
For example, I could put all these variables in a file and require the
file in the application controller. I’m not sure which would be
better for performance or whether there is a standard way of handling
these things.

Thanks in advance for any advice.

On Feb 19, 2007, at 04:15, Jay Jansheski wrote:

I have a Rails application that manages several websites. Each site
has certain variables specific to that site. For example:
[snippet]
And so on.
Currently I’m storing all of this in the ‘sites’ table and hitting the
database for it on every page. I imagine the table will grow to 50 or
100 columns, with the various site settings I’ll need.
Does anyone have any opinion of a better place to store this stuff?
For example, I could put all these variables in a file and require the
file in the application controller. I’m not sure which would be
better for performance or whether there is a standard way of handling
these things.

That really depends on whether you need to update that piece of
information on every request. If not, either store the information
as Ruby code and require it the way you described, or use several
config files (yaml or json) and read them in beforehand. If the
information needs to be updated for each request anyway, the overhead
is a constant.

If not, you could store the information (an AR record) as part of the
session, then only the entry points (such as login/logout) need to
handle the loading/unloading. This may be the way that fits your
current design.

My two cents.

d.