問題タブ [identity-column]

この DataGridView が 1 つのテーブルのデータセットに対応し、このテーブルに自動インクリメントされた ID 列がある (また、この列が主キーに設定されている) ように、プログラムに DataGridView を配置しました。

この ID 列は DataGridView には表示されず、ユーザーが他のセルに入力して [保存] をクリックすると、NoNullAllowedExceptionが発生します。

ユーザーがデータを挿入することだけを許可したい(別の変更ではない)

どうすればよいですか?C# と SQL Server 2008 を使用しています

乾杯

データのサブセットを 1 つのテーブル セットから別のデータベース内の同一のテーブル セットにコピーするストアド プロシージャを作成しようとしています。「ソース」データベースは、ストアド プロシージャのパラメーターである必要があります。

私はこれに2日間苦労しましたが、良い解決策があると思いました：

1. スキーマが同じであることを検証します。
2. 動的 SQL を使用して、ソース テーブルの一時的な "rmt" シノニムを作成します。
3. INSERT INTO A SELECT * FROM rmtA WHERE <criteria> を使用してデータをコピーします。
4. シノニムを削除します。

これはほとんどのテーブルでうまく機能しますが、ID 列を含むテーブルでは、SET IDENTITY_INSERT ON & OFF を強いられるだけでなく、さらに悪いことに SELECT *; を使用することもできません。すべての列を明示的に指定する必要があります。後で列を追加または削除すると、これは悪夢になります。

私はドアから何かを手に入れなければならないので、今のところこの解決策で行きますが、どこかにもっと良い解決策があると思いたいです.

ヘルプ？

テーブルの列を ID としてマークしました

001,002,003などのように ID 列をインクリメントする必要があります。

1,2,3データベースは、などとして挿入していることを示しています。

これはどのように行うことができますか？

データベースにアイテムを追加するとき、フィールド DisplayOrder の値を自動決定する必要があります。Identity (自動インクリメント) は理想的なソリューションですが、DisplayOrder 列の値をプログラムで変更 (UPDATE) できるようにする必要があり、Identity はそれを許可していないようです。とりあえず、次のコードを使用します。

それを行うのは良い方法ですか、それともより良い/簡単な方法はありますか?

wpf のエンティティ フレームワークを使用して、ID 列と 3 つの「通常の」列を持つテーブルに行を挿入しようとしています。しかし、私はこのエラーメッセージを受け取りました: IDENTITY_INSERT が OFF に設定されている場合、テーブル 'MyTable' の ID 列に明示的な値を挿入できません桁：

誰でもこの問題を解決するのを手伝ってくれますか?

SQL Serverデータベース（2005および2008）であるレガシーデータベースがあります。

テーブル内のすべての主キーはUniqueIdentifiersです。

現在、テーブルにはクラスター化インデックスが作成されておらず、75万レコードしかないテーブルでパフォーマンスの問題が発生しています。これは私が唯一の主キーとして一意の識別子を使用して作業した最初のデータベースであり、SQLサーバーがデータを返すのにこれほど遅いのを見たことがありません。

一意の識別子にクラスター化されたインデックスを作成したくないのは、それらがシーケンシャルではないため、データの挿入に関してアプリの速度が低下するためです。

リモートサイトレコードのID管理の目的で使用されているため、uniqueidentifierを削除することはできません。

テーブルに大きな整数のID列を追加し、この列にクラスター化インデックスを作成し、一意のID列を含めることを考えていました。

すなわち

intidentity-挿入速度を維持する最初の列一意の識別子-アプリケーションが期待どおりに動作し続けることを保証します。

目標は、IDクエリと結合テーブルクエリのパフォーマンスを向上させることです。

Q1：これにより、データベースのクエリパフォーマンスが向上しますか、それとも遅くなりますか？

Q2：私がリストしていないこれに代わるものはありますか？

ありがとうピート

編集： パフォーマンスの問題は、特に「トランザクション/変更」テーブルのいくつかが一緒に結合されている場合、selectステートメントを介してデータをすばやく取得することです。

編集2：テーブル間の結合は、通常、すべて主キーと外部キーの間です。外部キーを持つテーブルの場合、よりカバーするインデックスを提供するために、非クラスター化インデックスに含まれます。

すべてのテーブルには、適切なクラスター化インデックスを提供する他の値はありません。

高負荷の各テーブルにID列を追加し、クラスター化インデックス内に現在のGuid PK列を含めて、最高のクエリパフォーマンスを提供することに傾倒しています。

編集3：クエリの80％は、データアクセスメカニズムを介して主キーと外部キーのみで実行されると推定します。通常、データモデルには、アクセス時にクエリを実行する遅延読み込みオブジェクトがあります。これらのクエリは、オブジェクトIDとPK列を使用します。タイプXの基準に基づくフィルターとして外部キー列を使用する、ユーザー主導のデータ除外/包含クエリが大量にあり、次のIDを除外します。残りの20％は、列挙型（int）列または日付範囲列のwhere句であり、システムで実行されるテキストベースのクエリはごくわずかです。

可能であれば、最も重いクエリをカバーするためにカバーインデックスをすでに追加しましたが、それでもパフォーマンスには失望しています。bluefootedが言うように、データはヒープとして保存されています。

テーブル内にデータがない場合に IDENTITY 列がインクリメントされたかどうかを確認する方法があるかどうかに興味がありました。(つまり、データ項目が挿入されてから削除された)

私の2つの質問は次のとおりです。

• クラスタ化インデックスを使用して、大きなテーブルへの一括挿入を高速化できますか？
• IDENTITY列がクラスター化インデックスではなくなった場合でも、外部キー関係を効率的に使用できますか？

詳細に説明すると、会社のデータを含む非常に大きな（100〜1000百万行の）テーブルがいくつかあるデータベースがあります。通常、このようなテーブルには20〜40の企業に関するデータがあり、それぞれが「CompanyIdentifier」（INT）でマークされた独自の「チャンク」です。また、すべての企業には約20の部門があり、それぞれに「DepartmentIdentifier」（INT）でマークされた独自の「サブチャンク」があります。

「チャンク」または「サブチャンク」全体がテーブルに追加またはテーブルから削除されることがよくあります。私が最初に考えたのは、これらのチャンクでテーブルパーティショニングを使用することでしたが、SQL Server 2008 Standard Editionを使用しているため、その資格がありません。それでも、私が持っているほとんどのクエリは、テーブル全体ではなく、「チャンク」または「サブチャンク」で実行されます。

私はこれらのテーブルを次の機能のために最適化するために取り組んできました：

1. サブチャンクで実行されるクエリ
2. テーブル全体で実行される「ベンチマーク」クエリ
3. データの大きなチャンクの挿入/削除。

1）と2）については、私は多くの問題に遭遇していません。キーフィールド（有用な場合はCompanyIdentifierとDepartmentIdentifierも含む）にいくつかのインデックスを作成しましたが、クエリは正常に実行されています。

しかし、3）私は良い解決策を見つけるのに苦労しました。私の最初の戦略は、常にインデックスを無効にし、大きなチャンクを一括挿入し、インデックスを再構築することでした。これは最初は非常に高速でしたが、データベースに多くの企業が存在するようになったため、毎回インデックスを再構築するのに非常に長い時間がかかります。

現時点では、これがより高速になっているように見えるため、私の戦略は挿入中にインデックスをオンのままにすることに変更されました。しかし、挿入速度をさらに最適化したいと思います。

CompanyIdentifier + DepartmentIdentifierで定義されたクラスター化インデックスを追加することにより、テーブルへの新しい「チャンク」のロードが高速になることに気付いたようです。IDENTITY列にクラスター化インデックスを追加するためにこの戦略を放棄する前は、クラスター化インデックスは他のすべてのインデックスに含まれているため、クラスター化インデックスはできるだけ小さくする必要があると指摘されていました。しかし今、私はこの古い戦略を復活させてインサートをスピードアップすることを考えています。私の質問ですが、これは賢明なことでしょうか、それとも他の分野でパフォーマンスの低下に見舞われるのでしょうか？そして、これは本当に私の挿入をスピードアップしますか、それともそれは私の想像力ですか？

また、私の場合、IDENTITY列が本当に必要かどうかもわかりません。他のテーブルとの外部キー関係を確立できるようにしたいのですが、CompanyIdentifier + DepartmentIdentifier + [uniquifier]スキームのようなものを使用することもできますか？または、テーブル全体の断片化されたIDENTITY番号である必要がありますか？

提案や説明をありがとうございました。

EFモデルで定義された単純な2オブジェクトの継承、Person<-Userがあります。

Personは基本エンティティ/クラスであり、抽象的ではなく、firstname、lastname、emailなどのフィールドが含まれています。

Userは派生エンティティ/クラスであり、username、lastlogin、islockedoutなどのフィールドが含まれています。

データベースはタイプごとのテーブルスキーマを使用するため、Person用に1つのテーブルがあり、User用に別のテーブルがあります。どちらも同じ主キーフィールドであるPersonIDを使用します。PersonIDはIDENTITY列ですが、EDMでは、PersonIDのStoreGeneratedPatternがNoneに設定されています。

これはタイプごとのテーブル継承スキーマであるため、対応するUser行/オブジェクトを持たないPerson行/オブジェクトが存在する可能性があります。これは、システムにユーザーではない人に関するデータを含めることができるようにするためです。しかし、人は最終的にユーザーになる可能性があり、これは私が問題を抱えているところです。

このシナリオのテストケースがあります。このシナリオでは、システムがユーザーになりたい人物を見つけます。新しいUserオブジェクトにPersonIDフィールドを設定し、それをObjectContextに追加して、変更を保存してみました。何が起こるかというと、データベースは、PersonIDに設定した値を無視して、新しいUser行とともに新しいPerson行を作成します。

どうすればこれを回避できますか？EDM Crud操作を処理するためにsprocを作成する必要がありますか？

「テーブルごとにIDENTITY列は1つしか存在できません」

なんでそうなの？車両のシナリオを考えてみると、一意であることが判明した登録番号だけでなく、一意であるシャーシ番号が存在します。SQL Serverでこのシナリオを表現するには、onの列のカスタム実装が必要です。逆に、Oracleでは、テーブルに必要な数のシーケンスを含めることができます。IDENTITY列に制限があるのはなぜですか、特定の理由がありますか？

車両スキーマを持つシナリオは、ID列に制限がある理由について自分自身に疑問を投げかけているものです。