私は、Active Record で作成するのが難しすぎると感じた複雑な SQL の一部にSequelを使用することを検討しています。
Sequel と ActiveRecord を同じプロジェクトで使用する場合に注意することはありますか? （続編でAR検証がないなどの明らかなものに加えて...）
3298 次
2 に答える
22
免責事項: 私は Sequel のメンテナーです。
Rails を使用する場合、Sequel は ActiveRecord と一緒に、または ActiveRecord の代わりに簡単に使用できます。データベース接続を手動でセットアップする必要がありますが、それ以外の使用方法は似ています。Sequel モデル ファイルは app/models に入り、ActiveRecord モデルと同様に機能します。
データベース接続のセットアップは面倒ではありません。一般に、environment.rb の 1 行で follow を要求し、各環境ファイル (development.rb、test.rb、production.rb) の 1 行で次のようなことを行います。
DB = Sequel.connect(...)
したがって、4 行のセットアップ コードが面倒だと考えれば、面倒なだけです。
複数のデータベースをターゲットにしている場合を除き、通常、未加工の SQL を使用しても問題はありません。これを回避する主な理由は、冗長性の増加です。Sequel は、少なくとも ActiveRecord と同じくらい簡単に未加工の SQL を使用できますが、未加工の SQL を使用する必要がある場合は、Sequel では一般的にかなりまれです。
ところで、Sequel には複数の検証プラグインが同梱されています。validation_class_methods プラグインは、クラス メソッドを使用する ActiveRecord の検証に似ています。validation_helpers プラグインには、インスタンス レベルのメソッドを使用したより単純な実装がありますが、どちらもほぼ同じことを行うことができます。
最後に、必要な機能を実行する ActiveRecord コードが既に動作している場合は、機能を追加する予定がない限り、そのコードを Sequel に移植する価値はおそらくないでしょう。
于 2009-08-06T20:21:48.900 に答える
3
個人的には、私はそれをしません。多かれ少なかれ手動で接続を管理するだけでは、最初は面倒です。Sequel がより強力な選択肢だと感じた場合、Yehuda と共同作業が適切に行われている場合、ORM の切り替えがかなり簡単になるはずの Rails 3.0 を延期する (または Edge Rails に対して開発を開始する) 傾向があります。 . 少なくとも今よりずっとマーブらしい。
これは DHH の主題に対する見解でした (私はそれが福音の真実として受け取られるべきだと言っているわけではありませんが、いわば馬の口からのものです):
しかし、Sql はダーティではありませんか?
プログラマーがリレーショナル データベースの上にオブジェクト指向システムをレイヤー化し始めて以来、抽象化をどの程度深く実行するかという問題に苦労してきました。一部のオブジェクト リレーショナル マッパーは、SQL の使用を完全に根絶しようとしており、すべてのクエリを別の OO レイヤーに強制することによってオブジェクト指向の純粋さを追求しています。
Active Record はそうではありません。これは、SQL は汚いものでも悪いものでもなく、単純なケースでは冗長であるという考えに基づいて構築されました。焦点は、これらの些細なケースで冗長性を処理する必要性を取り除くことですが、難しいクエリの表現力を維持することにあります。タイプ SQL は、エレガントに処理するために作成されました。
したがって、find_by_sql() を使用してパフォーマンスのボトルネックまたは難しいクエリを処理するときに、罪悪感を感じる必要はありません。生産性と楽しみのためにオブジェクト指向インターフェイスを使用して開始し、必要に応じて表面下のディップを使用して、金属に近いエクスペリエンスを実現します。
(引用はここにあり、元のテキストは「ハンモック」の本であるAWDRWR のp334にあります)。
それは合理的だと思います。
find_by_sql処理できない何かについて話しているのですか？executeそれとも、処理できない複雑な SELECT 以外のものについて話しているのでしょうか?
私たちが見ることができる例はありますか？
于 2009-08-06T09:38:00.307 に答える