ruby-on-rails-3 - 大量のクエリデータをブラウザに永続化するためのRailsの規則はありますか？

Question

ユーザーが多数の列を持つ単一の大きなテーブルからデータをドリルダウンできるようにするアプリケーションがあります。それはこのように動作します：

画面には、個別の最上位テーブル値のリストがあります。
ユーザーがそれをクリックすると、リストはクリックされたものすべての個別の次のレベルの値に変わります。
ユーザーはこれらの値の1つをクリックし、第3レベルの値などに移動します。

通過できる属性は約50ありますが、通常は3または4になります。ただし、これらの3または4は50の可能な属性間で異なるため、選択をブラウザーに保持する必要があります。今、私はそれを恐ろしくてかさばる隠された形でやっています。それは機能しますが、繊細で最適ではありません。それが機能するために、画面上の任意のレベル属性の値がクリックイベントの非表示フォームの適切な場所に入力され、jQueryAjaxPOSTがフォームを送信します。ぶさいくな。

Backbone.jsも調べましたが、他の簡単な規則が欠けている可能性があるため、このプロジェクトに別のツールキットを組み込みたくありません。このようなことをするための基準はありRails Wayますか、それとももっと良い方法の期間がありますか？

score 2 · Accepted Answer

単一テーブルのドリルダウンへの可能なアプローチ

多数の列セットを持つ単一のテーブルから列選択を実行する場合は、いくつかの基本的なアプローチを検討する必要があります。

クライアント側のJavaScriptライブラリを使用して、オンデマンドで列を表示/非表示にします。たとえば、DataTablesを使用して、最後に選択した値（または値のセット）に関連するものに基づいて、表示される列を動的に調整できます。
ビューのフォームを使用して、関連する列名をセッションまたはparamsハッシュに渡し、次のレベルにドリルダウンするときにビューにレンダリングする列についてそれらの値を調べることができます。
次のサーバー側のリクエストには、対象の列のリストを含めることができ、コントローラーはそれらの列名を使用して、SELECTまたは#pluckを使用してカスタムクエリを作成できます。このようなクエリには汚染されたオブジェクトが含まれることが多いため、その入力を完全にサニタイズし、注意して処理してください。
データベースがビューをサポートしている場合、ユーザーは次のコントローラーアクションから事前定義されたビューまたは動的ビューを選択できます。これにより、パフォーマンスが向上する場合とそうでない場合があります。少なくとも追求する価値のあるアイデアですが、これを慎重にベンチマークし、SQLインジェクションや管理しにくい数の事前定義されたビューを維持することにならないようにする必要があります。

いくつかの警告

この種の機能をクライアント側とサーバー側のどちらで処理するかを決定する場合、通常、メモリと遅延の間にはトレードオフがあります。また、一般に、巨大な非正規化テーブルの背後にあるビジネスロジックを再検討し、問題のドメインをより管理しやすいRESTfulリソースのセットに分解できないかどうかを調査する価値があります。

考慮すべきもう1つのことは、Railsは、基本的なリソース指向のMVCパターンに違反することを阻止しないということです。あなたの質問から、各データリソースの標準的な表現がないという暗黙の仮定があります。この方法でRailsにアプローチすると、複雑さが増すことがよくあります。アプリケーションの要件を満たすためにその複雑さが本当に必要な場合は問題ありませんが、基本的な設計目標を慎重に評価して、機能のトレードオフと長期的なメンテナンスの負担に見合う価値があるかどうかを確認することをお勧めします。