1

Railsアプリでより高度な（したがってより複雑でより大きな）SQLクエリを整理するためのオプションは何ですか？

目的：

  • SQLと関連する仕様を従来の場所に保持します。
  • より大きく、より再利用可能なSQLをSQL関数、ビュー、トリガーに抽出します（関数、ビューのコードを維持する方法は？移行はおそらく最良の選択ではありません）
  • SQLのスニペットをARの一部として、またはスタンドアロンとして再利用します。
  • 基盤となるデータベース機能のほとんどを活用します（PostgreSQL CTE、FTS、拡張機能など）。
  • SQLを管理しやすく、保守しやすくします。
4

1 に答える 1

1

すべてをスタンドアロンの gem/Rails Engine としてパッケージ化することを検討します。

必要なすべてのカスタム SQL 移行 (ビュー、関数、ストアド プロシージャなどを作成するためのコード) を配置することが/db/migrations/sqlでき、カスタム Rake タスクを記述してこれらの移行を実行することができます。

その後、あらゆる種類のテスト/仕様を記述して、データベース固有のビュー、関数、ストアド プロシージャなどを実行できます。

この gem には独自のソース リポジトリがあり、メイン アプリとは独立した独自のライフ/リリース サイクルを持つことができます。これは、Ruby の専門家 (gem、spec、ライブラリー) と SQL の専門家 (当然) のペアによって維持される可能性があります。

このライブラリ/API が適切に作成されている場合、メイン アプリケーションを低レベルのデータベース固有のコードから抽象化するという追加の利点が得られます。つまり、アプリケーション開発者は、Widget.complex_sql_query戻り値を呼び出して処理することだけを気にするだけでよく、メンテナンスを気にする必要はありません。逆に、データベース バックエンド チームは、コードがどのように使用されるかについてそれほど心配する必要はありません。ただし、両方のチームが API 契約に同意し、テスト カバレッジが全体的に良好である限りはそうです。

これはメイン アプリに統合されたすべてのコードで実行できますが、すべてを個別の gem として使用すると、物理的および心理的な障壁が課せら​​れ、両方のチームがそれぞれの責任領域により簡単に集中できるようになります。

于 2013-01-17T03:18:37.600 に答える