1

まず、これがこれを処理する最良の方法であるとは確信していません...代替ソリューションを完全に受け入れています。

第二に、私は明らかなことを見逃しているように感じます...しかし、私はまだそれを見逃しているので、質問することを誇りに思いません!

UPDATE : SQL 2005 を使用する .NET 3.5 環境なので、動的 linq のようなことが可能ですが、私は常に、あらゆる種類の動的 (オンフライでビルド) クエリを不格好なものと考える傾向があります。維持するPITA。

UPDATE 2 : Northpole への対応として、疑似コード / 記述された単語ロジック / sql / linq / C# はすべて受け入れ可能 (!) ... コードの種類の質問が必要というよりも、概念的な「良いアプローチとは何か」のほうが多いです。

次のような「靴」の表があるとします。

  靴ID プロパティ名 プロパティ値
  1 カラーレッド   
  2カラーレッド   
  2 サイズ 11
  3カラーレッド   
  3 サイズ 11   
  3 メーカー グッチ

そのような靴を照会する方法が必要です

COLOR=RED を返す

  1
  2
  3

COLOR=RED および SIZE=11 が返されます

  2
  3

COLOR=RED および SIZE=11 および MANUFACTURER=GUCCI が返されます

  3

設計時には、異なるプロパティがいくつあるかも、クエリ パラメータがいくつあるかもわかりません。

うまくいけば、これは理にかなっています...そうでない場合は、それに応じてコメントしてください。もう一度試します.

4

3 に答える 3

1

したがって、これが最善のアプローチであるかどうかは、多くのことに依存します。たとえば、異なる（互換性のない）属性を持つ可能性のある異なるクラスのエンティティ（靴とドレスなど）をサポートする必要がありますか？または、エンティティの推定数はいくつですか（10Kで十分に機能するものは、100Mでは機能しません）。または、そのようなクエリをどのくらいの頻度で処理する必要があり、どれだけうまく実行する必要がありますか？

これに関する2つの最も一般的な考え方は、EAVモデルです。これは、多かれ少なかれあなたが持っているものであり、エンティティのプロパティ（色、サイズなど）がそれぞれ別々の列にマップされる列ベースのアプローチです。それぞれに長所と短所があり、最大のものは前者の柔軟性/パフォーマンスと後者のテーブル構造を動的に変更する必要性です。

既存のモデルを使用する場合は、プロパティ名を別のテーブルに移動し、「shoes」テーブルを変更してFKをそのテーブルに設定することをお勧めします。property_id次に、（ 、 ）にインデックスを作成し、shoe_id次のようにクエリを生成できます。

SELECT shoe_id FROM shoes S_1 [, shoes S_2, ..., shoes S_X]
 WHERE S_1.property_id = 3 /* FK for 'color' */
  /* the following 3 lines will be repeated for each 'property' you need to query on */
   AND S_X.property_id = 4 /* FK for 'size' */
   AND S_X.shoe_id = S_1.shoe_id
   AND S_X.property_value = 'RED'

靴の数が多すぎず、属性がほぼ均一に分布していれば、これはかなりうまく機能するはずです。

于 2009-08-13T19:49:14.777 に答える
0

動的SQLが役立ちます。何かのようなもの：

ALTER PROCEDURE [dbo].[sp_GetFilteredRecords]
(
...
@ConditionList nvarchar(MAX) = null
)
AS
BEGIN
  DECLARE @sql        nvarchar(MAX), 
          @paramlist  nvarchar(MAX)

  SELECT @sql = 'select ... '
  ...
  SELECT @sql = @sql + ' where 1=1 '
  ...
  SELECT @sql = @sql + ' ' + @ConditionList + ' '


  SELECT @paramlist = ...

  EXEC sp_executesql @sql, @paramlist

確かにツールによって若干異なる場合があります。

ボリス。

于 2009-08-13T19:29:09.600 に答える
0

私の理解が正しければ、前もって知られていない任意の数のフィールドに基づいた条件を持つクエリを作成できるようにしたいと考えています。それは大変です....

ほとんどの RDBMS はある種の「動的 SQL」機能を提供しますが、これらのアプローチは使いにくいか、遅いか、またはその両方である傾向があります。

もちろん、C#、Java、PHP など、クライアント コードで SQL ステートメントを連結することもできますが、これも扱いにくく、SQL インジェクション攻撃を受けやすく、一般的には扱いにくいものです。

また、リクエストごとに異なるクエリがある場合、RDBMS はクエリ プランをキャッシュすることができず、まともなクエリ パフォーマンスを得るために適切なインデックスを作成することは、よくても難しく、最悪の場合は不可能です。

そのため、私はその要件を完全に理解していますが (ほぼ毎日自分でそれと戦わなければなりません)、実際にはうまく機能しません。むしろ、最も頻繁に使用される検索とその基準を特定し、それらが正常に機能し、高速であることを確認したいと思います。適切なクエリ パフォーマンスを実現するために、ユーザーの柔軟性を制限します。古典的なトレードオフ - 完全に柔軟にすることができますが、パフォーマンスが低下するか、頻繁なクエリを高速に実行できますが、ある程度の柔軟性が失われます。

テキスト フィールドでフリー テキストを検索する場合、何かを得る可能性のある領域の 1 つです。SQL Server のような RDBMS は全文検索の概念をサポートしているため、ある程度の柔軟性と優れたパフォーマンスが得られます。テキストフィールドがたくさんある場合は、それを確認してください。

マルク

于 2009-08-13T19:30:44.027 に答える