問題タブ [unique-index]

移行ファイルには次のものがあります

product_id が指定されている場合は一意であることを確認したいのですが、null も許可したいので、モデルに次のように記述します。

うまく機能しますが、移行ファイルにインデックスを追加する必要があります

product_id に 2 つの null 値が挿入されると、明らかに例外がスローされます。移行で単にインデックスを省略することもできますが、次に示すように、同じ product_id を持つ 2 つの PaymentAgreements を取得する可能性があります:同時実行性と整合性

私の質問は、この問題に対処するための最良/最も一般的な方法は何ですか

SQLServerで一意性を強制するために開発者がどの手法を使用することを好むかを知りたいです。UNIQUECONSTRAINTまたはUNIQUEINDEXです。それぞれの物理的な実装にほとんど違いがないことを考えると、どちらが最適かをどのように判断しますか？

パフォーマンス以外に、最良のソリューションを評価する理由はありますか？

どちらか一方にデータベース管理の利点はありますか？

私はDBに4つのフィールドを持っています.iはそれらをカント重複エントリに設定します.それらは次のとおりです。

同じデータを入力した場合、記録できません。

しかし、次のように入力すると、このデータを入力に成功させる方法:

そして、私は次のような結果が欲しい:

テーブルに複合一意インデックスを作成しました。

データベース全体の照合は、SQL_Latin1_General_CP1_CI_AS に設定されます。次の T-SQL を実行すると、「等しくない」と出力されます。

次に、次の挿入ステートメントを試してみると:

次のエラー メッセージが表示されます。

どうしてこれなの？ドキュメントには見つかりませんでしたが、構成された照合を使用して、2 つのキーが重複している状態を調べていると思います。

ちなみに、テーブル、列、およびインデックスの照合を確認しましたが、それらはすべてデータベースの照合と同じです。

以下は使用例です。A、B、C の 3 つの列で定義された一意のインデックスがあります。それらの値が A1、B1、C1 であるとします。私のJavaコードはA1、B1、C1などの新しいレコードを追加していますが、このレコードが追加される前に、以前の値をC1からC2に更新します。(更新後に) 新しいレコードを追加しようとしているときに、休止状態が一意の制約違反の例外をスローしています。なぜそうするのかについて何か理由はありますか？上記のすべてのステートメントは、同じトランザクション内で実行されます。私の仮定は、挿入が更新の前に発生するため、例外の理由です。

考えや提案はありますか？

次の表があります。

および次の一意のインデックス：

CouponCodeと他の外部キーを使用してかなり一定のクエリを実行します（簡単にするために上記には示されていません）。CampaignCustomerテーブルには、ほぼ400万件のレコードがあり、増え続けています。また、クーポンコードを必要としないキャンペーンも行っているため、これらのレコードは挿入されません。次に、別の目的のために、これらのキャンペーンの追跡も開始する必要があります。したがって、2つのオプションがあります。

1. CouponCode列を変更してnullを許可し、nullを含まないように一意のファイラーインデックスを作成して、テーブルをさらに大きく高速に拡張できるようにします。
2. この特定の目的のためにすべてのキャンペーンを追跡するための個別のテーブルを作成します。

CampaignCustomerテーブルは、クーポンの引き換えや新しいクーポンの挿入に頻繁に使用されることに注意してください。結論として、お客様がクーポンを利用して、あきらめるまで、または他のプロセスが失敗するまで待たされたくないということです。では、効率の観点から、どのオプションが最適だと思いますか、またその理由は何ですか？

以下の2つのモデルがあります。それらは次のように説明できます。

レポートには report_detail (開始/終了月を決定する) があります。多くのレポートは同じレポート詳細を持つことができますが、2 つのレポート詳細が同じであることはできません。

[:duration, :starting_month, :offset] の ReportDetail のインデックスに一意の制約があります。

私が達成しようとしているのはこれです: 新しいレポートに、一意の組み合わせ属性 (:duration、:starting_month、:offset) を持つ ReportDetail がある場合、新しい ReportDetail を作成し、通常どおり保存します。レポートに ReportDetail があり、既存の ReportDetail が同じ属性を持つ場合、レポートの詳細をこの ReportDetail に関連付け、レポートを保存します。

report_detail=a を使用してセッターにエイリアスを設定することでこれを機能させましたReportDetail.find_or_create_by...が、醜いです (また、detail 属性を使用して新しいレポートをインスタンス化するだけで不要な ReportDetail エントリが作成され、何らかの理由で を使用して保存を適切に機能させることができませんでした.find_or_initialize_by...)。またbefore_save、ReportDetail で、何か他のものと一致する場合は、他のものに設定しようとしましたself。どうやらあなたはそのように自分自身を設定することはできません。

これについて最善の方法について何か考えはありますか？

私の現在のセッターがエイリアスで上書きするためのこの要点を参照してください

一意のインデックスと一意のキーの違いは何ですか？

INDEX作成ステートメントにUNIQUE引数があるのはなぜですか？

私が理解しているように、非クラスター化インデックスにはブックマーク、行へのポインターが含まれています。これは、非一意の行を区別するために一意である必要がある
ため、非クラスター化インデックスが一意であることを保証しますか？
正しい？

では、一意でないインデックスはクラスター化されたテーブルにのみ存在できることを理解していますか？以来

• 「ビューのクラスター化されたインデックスは一意である必要があります」[1]

「クラスター化インデックスの最下位またはリーフレベルには、テーブルの実際のデータ行が含まれている」[1]ので、クラスター化インデックスに対するUNIUEと同じ効果が、（おそらくすべてまたはの一部）テーブルの列[2]？

それでは、インデックスにUNIQUE引数をもたらすものは何ですか？
基本的な概念の定義との混同を除いて[3]

更新：
これも同じ落とし穴です-未定義の用語に基づいてすでに何度も説明されていることを説明し、すべての説明を終わりのない推測ゲームに変換します。
私のサブ質問[4]を参照してください。これは、この同じ質問を実際に言い換えたものです。

Update2：
問題はあいまいで、定義が不足しているか、不適切なコンテキストでの用語の不適切な使用にあります。インデックスが実際のデータを（検索して）識別/ポイントする構造として定義されている場合、一意でないインデックスまたはNULLインデックスは意味がありません。さよなら

引用：
[1]
CREATE INDEX（Transact-SQL）
http://msdn.microsoft.com/en-us/library/ms188783.aspx

[2]
CREATE TABLE（Transact-SQL） http://msdn.microsoft.com/en-us/library/ms174979.aspx

[3]
一意のインデックスまたは一意のキー？
一意のインデックスまたは一意のキー？

[4]
インデックスとは何ですか？非クラスター化インデックスは非一意である可能性がありますか？
インデックスとは何ですか？非クラスター化インデックスは非一意である可能性がありますか？

次のテーブルを持つ：

次のインデックスを追加したい

どのように私が持っているか（アプリケーションの検証が悪いため）、多くの繰り返し行があります（繰り返しとは、同じfield_1と同じfield_2を意味し、idだけが違います）

テーブルには約 60,000 行あるため、フィールドごとに削除するのは非常に困難です。

そのインデックスを適用して、重複したすべての行を削除するにはどうすればよいですか?