Since the profile ids (and other ‘constants’ stored in the database) can only change if the sys admin changes their values before the deploy (editing seeds.rb), I though of using initializers to retrieve references to all those database constants (therefore opening less connections with the database during application usage):
I don’t think this will affect the number of connections to the database, although you will of course save some queries
I have tested this solution and it works perfectly fine. However, I would like to know from veteran Rails developers if this is a good (or acceptable) use of initializers (and if this should really increase performance).
Personally if this was worthwhile for my app I would load the profiles lazily rather than in an initializer. One reason is that initializers get run in a lot of cases where you probably don’t need those rows cached, eg rake routes.
Occasionally this sort of stuff can bite you too - depending on how you deploy the app, the profiles table might not exist (fresh deploy). So you run rake db:schema:load to set things up, but that would also load you initializer and would therefore blow up when that initializer tried to access the profiles table.