I''m looking for some best practices suggestions here... As with many apps, the app we''re working on right now has lists of things, such as US states, countries, etc... When you guys are building apps with this data, do you usually throw it in the DB and just use normal associations or do you have arrays/hashes of the data specified somewhere and then just copy the value into a char field? I''ve done both and I''m not really sure which I like better. If I was going to go the non-db route with Rails, where would be the best place to put that? Cheers, Hunter
> When you guys are building apps with this data, do you usually throw it in > the DB and just use normal associations or do you have arrays/hashes of the > data specified somewhere and then just copy the value into a char field?Since this sort of stuff is unlikely to change, I''d probably say it didn''t belong in the DB: all those lookups will only slow you down.> If I was going to go the non-db route with Rails, where would be the best > place to put that?I''d go for a file in my app''s /lib/ directory, and require() the file from environment.rb. - M
Matt Powell wrote:>> When you guys are building apps with this data, do you usually throw >> it in >> the DB and just use normal associations or do you have arrays/hashes >> of the >> data specified somewhere and then just copy the value into a char field? > > > Since this sort of stuff is unlikely to change, I''d probably say it > didn''t belong in the DB: all those lookups will only slow you down. >That could be mitigated by loading once and having it available from the class: class States < ActiveRecord::Base @@all_states = States.find(:all) def all @@all_states end end
On 8/9/05, Matt Powell <matt-aUjHfZsTZX9iql55EdJREXTaI6DYlTYJ@public.gmane.org> wrote:> > When you guys are building apps with this data, do you usually throw it in > > the DB and just use normal associations or do you have arrays/hashes of the > > data specified somewhere and then just copy the value into a char field? > > Since this sort of stuff is unlikely to change,Famous last words ;)> I''d probably say it > didn''t belong in the DB: all those lookups will only slow you down.I''d stick it in, and only remove it when you''ve profiled your application and shown it to be a problem. -- Cheers Koz
I generally create a file in the "config" directory called
"application.yml" to store that kind of data. In the case of
Blinksale, it looks like this:
plans:
Free:
invoices: 3
users: 1
clients: 3
price: 0
ssl: false
...
currencies:
USD:
name: U.S. Dollar
symbol: $
EUR:
name: Euro
symbol: ''€''
...
etc.
Then, at the bottom of config/environment.rb, I have this:
APP_CONFIG =
YAML::load(File.open("#{RAILS_ROOT}/config/application.yml"))
Now, anywhere in my application (model, view, controller, or helper),
I can access that data like so:
APP_CONFIG[''plans''][''Free''][''invoices'']
# number of invoices allowed
with the Free plan
It''s quite handy, and the YAML format is very non-intimidating, so the
less technical members of the team feel comfortable editing it.
Best-
Scott Raymond
redgreenblu.com
Hunter Hillegas <lists-HAWAbpnI61OZ1JSuHaJ1sQC/G2K4zDHf@public.gmane.org>
wrote:> As with many apps, the app we''re working on right now has lists of
things,
> such as US states, countries, etc...
>
> When you guys are building apps with this data, do you usually throw it in
> the DB and just use normal associations or do you have arrays/hashes of the
> data specified somewhere and then just copy the value into a char field?
>
> I''ve done both and I''m not really sure which I like
better.
>
> If I was going to go the non-db route with Rails, where would be the best
> place to put that?
On Tuesday 09 August 2005 01:55, Matt Powell wrote:> > When you guys are building apps with this data, do you usually > > throw it in the DB and just use normal associations or do you have > > arrays/hashes of the data specified somewhere and then just copy > > the value into a char field? > > Since this sort of stuff is unlikely to change, I''d probably say it > didn''t belong in the DB: all those lookups will only slow you down.No need for repeated lookups class MyEnumClass < ActiveRecord::Base ALL = self.find(:all) ... end Actually, I''m using this def preload(options = {}) cattr_accessor :all private_class_method :all self.all = self.find(:all, options) end class MyEnumClass < ActiveRecord::Base preload ... end That way I can write choices = ar.respond_to?(:all) ? ar.all : ar.find(:all) I''ve pondered redefining #find with a wrapper around the original method so that it takes advantage of #all if it is defined, but I shied away as I didn''t want to damage the original functionality. Michael -- Michael Schuerig Those who call the shots mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Are never in the line of fire http://www.schuerig.de/michael/ --Ani DiFranco, Not So Soft
> No need for repeated lookups > > class MyEnumClass < ActiveRecord::Base > ALL = self.find(:all) > ... > endBut doesn''t that still do a big database lookup every time you run the app?
No, if you are running it under FastCGI(production setup), it loads it once per fastcgi process. The process stays in memory for a couple of hours usually. On 8/8/05, Matt Powell <matt-aUjHfZsTZX9iql55EdJREXTaI6DYlTYJ@public.gmane.org> wrote:> > > No need for repeated lookups > > > > class MyEnumClass < ActiveRecord::Base > > ALL = self.find(:all) > > ... > > end > > But doesn''t that still do a big database lookup every time you run the > app? > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Tuesday 09 August 2005 03:29, Matt Powell wrote:> > No need for repeated lookups > > > > class MyEnumClass < ActiveRecord::Base > > ALL = self.find(:all) > > ... > > end > > But doesn''t that still do a big database lookup every time you run > the app?You mean on every loading of the class? Yes, of course. In development environment that may mean once per request; in production environment that means once per app start. Regarding the "big", how do you suppose this to be different from a "big file read"? If you need the data you do need it. Michael -- Michael Schuerig The more it stays the same, mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org The less it changes! http://www.schuerig.de/michael/ --Spinal Tap, The Majesty of Rock