21

私の同僚は現在、次のようなSQLクエリを設計して、外部データクエリを介してExcelファイルに表示されるレポートを作成しています。現在、DB上のレポートプロセスのみが必要です（CRUD操作は不要です）。

Rails / Sinatraアプリでデータを表示できるようにするには、RubyORMを使用する方がよいと彼に説得しようとしています。

データを表示することには明らかな利点がありますが、SequelやDatamapperなどのORMの使用法を学ぶ上で彼にはどのような利点がありますか？

彼が書いているSQLクエリは明らかに非常に複雑であり、SQLに比較的慣れていないため、非常に時間がかかり、混乱を招くと不満を言うことがよくあります。ORMで非常に複雑なクエリを書くことは可能ですか？もしそうなら、どれが最も適切ですか（Sequelはレガシーデータベースに適していると聞きました）？複雑なデータベースクエリを作成する際に、ルビーを学習してORMを使用することと、プレーンSQLを使用することの利点は何ですか？

4

6 に答える 6

29

私はDataMapperのメンテナであり、複雑なレポートにはSQLを使用する必要があると思います。

いつかSQLのパワーと簡潔さを提供するDSLができると思いますが、これまで見てきたことはすべて、複雑なクエリに対してSQLよりも多くのRubyコードを記述する必要があります。同じ複雑な操作を説明するために、10〜15行のRubyコードよりも5行のSQLクエリを維持したいと思います。

複雑だと言っていることに注意してください。単純なものがある場合は、ORMの組み込みファインダーを使用してください。ただし、SQLがより単純になる線を越えることができると私は信じています。現在、ほとんどのアプリはレポートだけではありません。CRUDタイプの操作がたくさんあるかもしれませんが、ORMは完全に適しており、手作業で行うよりもはるかに優れています。

ORMが通常提供するものの1つは、アプリケーションロジックに対するある種の編成です。同じファイル内の各モデルに基づいてコードをグループ化できます。通常、コントローラーに埋め込むのではなく、複雑なSQLクエリを配置します。例：

class User
  include DataMapper::Resource

  property :id,   Serial
  property :name, String,  :length => 1..100, :required => true
  property :age,  Integer, :min => 1, :max => 130

  def self.some_complex_query
    repository.adapter.select <<-SQL
      SELECT ...
        FROM ...
       WHERE ...
       ... more complex stuff here ...
    SQL
  end
end

次に、を使用してレポートを生成できUser.some_complex_queryます。このコードをさらにクリーンアップする場合は、SQLクエリをビューにプッシュすることもできます。

編集：上記の文の「ビュー」とは、MVCコンテキストでのビューではなく、RDBMSビューを意味します。潜在的な混乱を解消したかっただけです。

于 2010-01-15T23:33:24.717 に答える
6

手作業でクエリを作成している場合は、クエリを最適化する機会があります。そのクエリを見ると、最適化の可能性があります（E.ICGROUPNAME LIKE'％san-fransisco％'またはE.ICGROUPNAME LIKE'％bordeaux％'はインデックス=テーブルスキャンを使用しません）。

レポートにORマッパー（ネイティブオブジェクト/テーブル）を使用する場合、結果のSQLクエリをまったくまたはほとんど制御できません。

ただし、そのクエリをビューまたはストアドプロシージャに配置し、ORマッパーを使用してそのビュー/プロシージャをマップすることができます。クエリを最適化し、アプリケーションフレームワークのすべての機能を使用できます。

于 2010-01-15T17:39:32.317 に答える
5

オブジェクトを扱っているのでない限り、ORMは必要ありません。友人は単にレポートを生成する必要があるようです。その場合、彼が何をしているかを知っている限り、純粋なSQLで問題ありません（たとえば、SQLインジェクションの問題を回避する）。

ORMは「オブジェクトリレーショナルマッピング」の略です。「O」（オブジェクト）がない場合は、アプリに適していない可能性があります。ORMが本当に優れているのは、オブジェクトをデータベースに永続化し、データベースからロードすることです。

于 2010-01-15T17:43:56.107 に答える
4

ORMはObjectRelationalMappingの略ですが、クエリを見ると、友達が合計やその他の項目のかなり具体的なテーブルを求めているようです...私はRubyのSequelを使用していませんが、HibernateとPythonのSQLAlchemy（ Django / Turbogears）そして、この種のクエリを実行することはできますが、それが彼らの強みだとは思いません。

ORMの力は、Foo-> Barオブジェクトの関係を見つけることができることから得られます。たとえば、FooのフィールドのすべてのBarオブジェクトをXより大きくする必要があります...そのようなことです。したがって、私はORMを「良い」ソリューションとして分類しませんが、Rubyのような実際のプログラミング言語に移行し、Excelの代わりにそれを介してSQLを実行します...それ自体が勝利です。

ちょうど私の2セント。

于 2010-01-15T17:34:03.677 に答える
3

そのような状況では、おそらく手で書くか、ビューを使用します（使用しているDBがビューをサポートしている場合）

于 2010-01-15T17:43:28.190 に答える
1

ORMは、オブジェクト（ビジネスオブジェクト）がある場合に使用されます。したがって、最終的にデータベースに保存されるビジネス・オブジェクトを作成および管理するためのアプリケーションがあると想定しています。あなたが持っているなら、あなたはほぼ間違いなく関係のいくつかの表現とあなたがレポートで使用しようとしている計算の多くを手に入れました。SQLを使用してレポート用のデータベースに直接アクセスする場合の問題は、単に保守性です。通常、ビジネスオブジェクトがデータベースの詳細を非表示にすることに多大な労力を費やします。ビジネスルールを実装し、ビジネスオブジェクトで一般的な計算を行います。チームのすべてのメンバーなどに共通の言語を構築します。次に、ORMを使用してデータベースにマップし、Habaneroを使用します。またはNHibernateまたはそのようなものでこれを行います。これはすべて素晴らしいです。私たちはこれをすべて保守性の名の下に行っており、素晴らしいです。アプリケーションを移行して、設計などを変更できます。

ここで、SQLを記述して、何百ものレポートがある時間の経過とともにレポートを実行します。まず、BusinessObjectsにすでにあるロジックを複製することがよくあります（通常はテストなし）。さらに悪いことに、Bham Dambの保守性は低下し、そのフィールドを1つのテーブルから別のテーブルに移動することを忘れ、そのテーブルを2つに分割してその関係を変更することなどを忘れます。予期せず壊れそうなレポートがたくさんあります。

ドメインオブジェクト/ビジネスオブジェクトを検索する際の問題は、単にパフォーマンスの1つです。

要約すると、ドメイン駆動設計またはビジネスオブジェクトの概念を使用している場合は、これらをレポートに使用してみてください。（パフォーマンス上の理由から、SQLまたはストアドプロシージャを使用してDBから直接実行する可能性がありますが、最初にビジネスオブジェクトを使用してからSQLを使用するように制限してください）。もちろん、もう1つのオプションは、別のレポートデータベースを使用することです（一部のBIコンセプトと同様）。したがって、トランザクションDBからレポートDBへのマッピングは一箇所で行われ、設計を変更する場合に簡単に変更できます。

ドメインオブジェクト（ビジネスオブジェクト）とORMには、ドメイン用語を使用しながらデータベース上で直接実行される高性能クエリの構築を開始するためのすべての知識があります。これらが現実になるまで進化し続けることを期待しましょう。

それまでは、アプリケーションでBusiness Objectsを使用している場合は、パフォーマンスがSQLの問題である場合は、それらをレポートに使用してみてください。

于 2010-01-27T18:49:48.233 に答える