あなたがしようとしているものには大きな難点がありますが、まず質問に答えてお答えします。
JobsControllerにクラスレベルのアクセサを作成し、Saveおよびdestroyイベントの後にJobsControllerを適切に変更するObserverをJobCategoryクラスに書き込みます。
class JobsController < ActionController::Base
@@categories = JobCategory.find(:all)
cattr_accessor :categories
# ...
end
class JobCategoryObserver < ActiveRecord::Observer
def after_save(category)
JobsController.categories[category.name] = category.id
end
def after_destroy(category)
JobsController.categories.delete(category.name)
end
end
名前の変更を許可する場合は、古い名前を削除する追加のロジックが必要になります。 ActiveRecord::Dirtyの方法がそれを助けるでしょう。
だから、つかまります。このようなアプローチの問題は、通常、複数のプロセスが要求を処理していることです。 job_categories
テーブルを変更することはできますが、その変更は1つのプロセスでのみ更新されます。他はもう古くなっています。
job_categories
テーブルは小さくなる可能性があります。任意の頻度でアクセスされている場合は、OSまたはデータベースサーバーによってメモリにキャッシュされます。十分にクエリを実行すると、そのクエリの結果がデータベースによってキャッシュされることさえあります。あなたが頻繁にそれを照会していない場合は、とにかくJobsController
の中にキャッシュしようとすることに気にする必要はありません。
メモリに絶対にキャッシュする必要がある場合は、memcachedを使用する方がよいでしょう。それから、すべてのRailsプロセスが動作し、失効したデータがない単一のキャッシュを取得します。
少なくともRails DBのスキーマ管理の意味ではないが、これはマイグレーションと関係があるようには聞こえません。 –