Railsの静的ページルートvs：constraints => {：url => /.+/} - 賛否両論

Question

Page admin setupを作成しています。ページにはサブページが含まれている可能性があり、末尾のURL文字列を作成するための機能がたくさんあります。とにかく、ここで賛否両論が何であるか不思議です。速度面または私は本当に（他のルートマッチングと多分もう少し/少ない柔軟性さておき）を考慮していないもの：

オプション1 - ページにすべてを一致：

get ':url' => 'pages#show', :constraints => { :url => /.+/ } 
# with @page = Page.find_by_url("/"+params[:url]) in my controller 

オプション2 - ページへの静的マップのルートがあり、いずれかの方法では、単に好奇心..同じようにうまくいくかもしれ

if Page.table_exists? # Otherwise on rake db:migrate this file will be called and throw an error 
    Page.all.each do |page| 
    match page.url, :controller => 'pages', :action => 'show', :page_id => page.id 
    end 
end 
# Then after pages save it calls MyApp::Application.reload_routes! 

を保存し、それぞれの後にルートを再ロードします。

Answer 1

Option-1は優れており、展開環境に関係なく実際には正常に動作しますが、通常の配置ではOption-2が失敗します。

2つのWebサーバープロセスがあるとします。P1とP2。それらは同じマシン上にあっても、別のマシン上にあっても、あるいは同じマシン上の別々のVM内にあってもよい。ある人が新しいページを保存したとしたら、たった今P1に行きます。 P1は、データベース（P1とP2の間の共有リソース）を更新し、ルーティングテーブルを再構築します。しかし、現在P1には正しいルーティング情報がありますが、P2には何か変更があったと誰も言わなかったので、古いものが貼り付けられています。

ポーリングやブロードキャストのシステムをセットアップすることもできますが、Option-1が現状のまま正常に動作する場合は、それは無意味な複雑さです。

Answer 2

あなたは、ルートの制約を使用することができます。

get ':url' => 'pages#show', :constraints => lambda {|request| Page.all.map(&:url).include?(request.path[1..-1]) } 

はまだ

get '*not_found' => 'page#not_found' 

http://guides.rubyonrails.org/routing.html#advanced-constraints