6

ORM（これまでのLLBLGenProとEntityFramework4）での限られた経験の中で、クエリは本質的にすべての列のデータを返すことに気づきました。NHibernateがもう1つの人気のあるORMであることは知っています。これが当てはまるかどうかはわかりませんが、当てはまると思います。

もちろん、回避策があることはわかっています。

  • SQLビューを作成し、ビュー上にモデルとマッピングを作成します
  • ストアドプロシージャを使用して、返された結果セットにモデルとマッピングを作成します

特定の慣行を順守することで、これを軽減できることを私は知っています。

  • データを選択するときに行数が合理的に制限されていることを確認する
  • テーブルの幅が広すぎないことを確認します（多数の列や大量のデータ型）

だからここに私の質問があります：

  1. 上記の方法で十分ですか、それとも返される列の数を制限する方法を見つけることを検討する必要がありますか？

  2. 上にリストしたもの以外に、返される列を制限する他の方法はありますか？

  3. プロジェクトでは通常、これにどのようにアプローチしますか？

前もって感謝します。

SELECT *更新：この種のことは、悪い習慣として考えられている概念に由来します。このディスカッションを参照してください。

4

7 に答える 7

8

ほぼすべての種類のORMを使用する理由の1つは、これらの下位レベルの懸念事項の多くを遅らせ、ビジネスロジックに集中することです。結合を適切に保ち、テーブルの幅を適切に保つ限り、ORMはデータの出し入れを容易にするように設計されており、行全体を使用できるようにする必要があります。

個人的には、テーブルの幅が原因で行き詰まる特定のケースに遭遇するまで、この時期尚早な最適化のような問題を検討します。

于 2011-03-03T05:22:23.057 に答える
2

最初の：素晴らしい質問、そして誰かがこれを尋ねた頃！:-)

はい、ORMが通常データベーステーブルのすべての列を返すという事実は、システムを設計するときに考慮する必要があるものです。しかし、あなたが言及したように、これを回避する方法があります。

私にとっての主な事実は、これが起こることであることに注意SELECT * FROM dbo.YourTableすることです-、、または（より良い）SELECT (list of all columns) FROM dbo.YourTable。

オブジェクト全体とそのすべてのプロパティが本当に必要な場合、これは問題ではありません。いくつかの行をロードする限り、それも問題ありません。利便性は、生のパフォーマンスよりも優れています。

データベース構造を少し変更することを考える必要があるかもしれません-次のようなものです：

  • BLOBのような大きな列を、ベーステーブルへの1：1リンクを使用して別々のテーブルに配置する場合があります。そうすれば、親テーブルを選択しても、それらの大きなデータのblobがすべて取得されるわけではありません。

  • たぶん、特定の状況でのみ表示される可能性のあるオプションの列のグループを別々のテーブルに配置し、それらをリンクします。これも、ベーステーブルを無駄のない状態に保つためです。

また、ORMを「アームレスリング」して一括操作を実行しようとすることは避けてください。これは、ORMの長所ではありません。

そして：パフォーマンスに注意を払い、特定の操作をストアドプロシージャなどに変更できるORMを選択してみてください-EntityFramework4ではこれが可能です。したがって、削除によってユーザーが殺された場合はDelete、そのテーブルのストアドプロシージャを記述して、その操作を別の方法で処理するだけかもしれません。

于 2011-03-03T05:51:31.123 に答える
1

ここでの質問は、あなたの選択肢をかなりうまくカバーしています。基本的に、HQL/SQLの手作りに制限されています。これは、スケーラビリティの問題が発生した場合に実行したいことですが、私の経験では、非常に大きなプラスの影響を与える可能性があります。特に、ディスクとネットワークのIOを大幅に節約できるため、スケーラビリティが大幅に向上します。ただし、すぐに行うことはありません。分析してから最適化します。

于 2011-03-03T05:27:26.563 に答える
1

上にリストしたもの以外に、返される列を制限する他の方法はありますか？

NHibernateを使用すると、クエリにプロジェクションを追加できるため、列を制限するためだけにビューやプロシージャを使用する必要はありません。

于 2011-03-03T06:31:24.757 に答える
0

私にとってこれは、テーブルに30を超える列がたくさんある場合、または列に多くのデータがある場合、たとえばフィールドに5000文字を超える場合にのみ問題になります。

私が使用したアプローチは、別のオブジェクトを既存のテーブルにマップすることですが、必要なフィールドのみを使用します。したがって、テーブルに100行を入力する検索の場合、MyObjectLiteがありますが、クリックしてその行の詳細を表示すると、GetByIdを呼び出して、すべての列を持つMyObjectを返します。

もう1つのアプローチは、カスタムSQL、Stroed procを使用することですが、パフォーマンスの向上が本当に必要で、ユーザーから不満がある場合にのみ、このパスをたどるべきだと思います。したがって、パフォーマンスの問題がない限り、存在しない問題を修正しようとして時間を無駄にしないでください。

于 2011-03-03T05:24:02.607 に答える
0

ここで、ProjectionとTransformers.AliasToBeanおよびDTOを使用して、返される列の数を制限できます。CriteriaAPIでの外観は次のとおりです。

.SetProjection(Projections.ProjectionList()
    .Add(Projections.Property("Id"), "Id")
    .Add(Projections.Property("PackageName"), "Caption"))
.SetResultTransformer(Transformers.AliasToBean(typeof(PackageNameDTO)));
于 2011-03-03T14:08:57.717 に答える
0

LLBLGen Proでは、返されるフィールドを定義できるだけでなく、データを結合して複数のテーブルからフィールドのカスタムリストを取得できる、型付きリストを返すことができます。

全体として、ほとんどの状況で、これは時期尚早の最適化であることに同意します。

LLBLGenや他のORMを使用することの大きな利点の1つ（LLBLGenについては、最初から使用しているので自信を持って話すことができます）は、データアクセスのパフォーマンスが、問題をよく理解している人々によって最適化されていることです。平均的なクマ。

彼らがコードをさらに高速化する方法を見つけたときはいつでも、データレイヤーを再生成するか、新しいdllをインストールするだけで、「無料」でそれらの変更を取得できます。

あなたがデータアクセスコードを書くことの専門家であるとあなたが考えない限り、ORMはおそらくほとんどの開発者の有効性と正確さを改善します。

于 2011-09-08T02:06:52.873 に答える