タグ付けされた質問 「identity」

IdテーブルのID列に名前を使用しないように教えられましたが、最近は、データが実際に何であるかについて簡単で、短く、非常に説明的であるため、とにかくそれを使用しています。 Idテーブル名の接頭辞を付けることを提案する人がいますが、これは特にSQLクエリを作成する人（またはEntity FrameworkのようなORMを使用している場合はプログラマー）、特にCustomerProductIdまたはAgencyGroupAssignementId Ident使用を回避するために、実際にすべてのID列に名前を付けて何かを作成するために雇ったサードパーティベンダーId。最初Idはキーワードだったからだと思っていましたが、調べてみると、IdSQL Server 2005のキーワードではないことがわかりました。 それでは、なぜIdID列に名前を使用しないことを推奨するのでしょうか？ 編集：明確にするために、どの命名規則を使用するか、またはある命名規則を他の命名規則よりも使用するための引数を求めていません。IdID列名に使用しないことが推奨される理由を知りたいだけです。 私はDBAではなく、単一のプログラマーです。データベースは、データを保存する場所にすぎません。私は通常小さなアプリを作成し、通常はデータアクセスにORMを使用するため、IDフィールドの共通フィールド名を使用する方がはるかに簡単です。これを行うことで何が欠けているのか、そしてこれを行わない本当に良い理由があるかどうかを知りたいです。

68 identity  naming-convention 

私は次のようなID列を持つテーブルを持っています： create table with_id ( id int identity(1,1), val varchar(30) ); これはよく知られています select * into copy_from_with_id_1 from with_id; idにIDを持つcopy_from_with_id_1になります。 次のスタックオーバーフローの質問では、すべての列を明示的にリストすることに言及しています。 やってみよう select id, val into copy_from_with_id_2 from with_id; この場合でもidはID列です。 私が欲しいのはテーブルのようなものです create table without_id ( id int, val varchar(30) );

41 sql-server  sql-server-2005  identity 

挿入によって生成したばかりのID値を取得するのに最適なオプションはどれですか？パフォーマンスに関するこれらのステートメントの影響は何ですか？ SCOPE_IDENTITY() 集計関数 MAX() TOP 1TableNameからのIdentityColumnの選択ORDER BY IdentityColumn DESC

35 sql-server  sql-server-2008-r2  identity 

人口統計データに基づいて患者を照合する場合、患者が「同じ患者」になるためにどのフィールドを照合すべきかについての推奨事項はありますか？ 実装によってアルゴリズムが異なることはわかっていますが、このプロセスに関するベストプラクティスや推奨事項があるかどうかは知りたいです。 First Name Last Name Date of Birth SSN Address City State Zip 等？

30 identity 

TL; DR：次の質問に要約します：行を挿入するとき、新しい値の生成とクラスター化インデックス内の対応する行キーのロックの間に機会がありますか？外部オブザーバーはより新しいものを見ることができます並行トランザクションによって挿入された値？（SQL Serverで。）Identity Identity 詳細バージョン Identityという名前の列を持つSQL ServerテーブルがありますCheckpointSequence。これは、テーブルのクラスター化インデックスのキーです（これには、追加の非クラスター化インデックスもいくつかあります）。行は、いくつかの並行プロセスとスレッドによって（分離レベルで、なしで）テーブルに挿入されます。同時に、クラスター化インデックスから定期的に行を読み取るプロセスがあり、その列で並べ替えられます（分離レベルでも、オプションはオフになっています）。READ COMMITTEDIDENTITY_INSERTCheckpointSequenceREAD COMMITTEDREAD COMMITTED SNAPSHOT 私は現在、読み取りプロセスがチェックポイントを「スキップ」できないという事実に依存しています。私の質問は、このプロパティに依存できますか？そうでない場合、それを実現するために何ができますか？ 例：ID値が1、2、3、4、および5 の行を挿入する場合、値4の行を表示する前に、値5の行を参照してはなりません。テストは、ORDER BY CheckpointSequence句（そしてWHERE CheckpointSequence > -1確実句）、ブロック行4、行5が既にコミットされていても、読まれるべきであるが、まだコミットされていない時はいつでも。 少なくとも理論的には、この仮定を破る可能性のある競合状態がここにあると思います。残念ながら、上のドキュメントでIdentityはIdentity、複数の同時トランザクションのコンテキストでどのように機能するかについてはあまり言及されていません。「特定のトランザクションの新しい値はそれぞれ、テーブル上の他の同時トランザクションとは異なります。」（MSDN） 私の推論は、それはこのように何らかの形で動作する必要があります： トランザクションが（明示的または暗黙的に）開始されます。 ID値（X）が生成されます。 対応する行ロックは、ID値に基づいてクラスター化インデックスで取得されます（ロックエスカレーションが開始されない限り、この場合、テーブル全体がロックされます）。 行が挿入されます。 トランザクションがコミットされる（おそらくかなり長い時間後に）ので、ロックは再び削除されます。 ステップ2と3の間に、非常に小さなウィンドウがあると思います 同時セッションは次のID値（X + 1）を生成し、残りのすべてのステップを実行できます。 したがって、その時点で正確に来ている読者が値X + 1を読み取ることができ、Xの値は失われます。 もちろん、これの可能性は非常に低いようです。しかし、まだ-それは起こる可能性があります。それともできますか？ （コンテキストに興味がある場合：これは、NEventStoreのSQL Persistence Engineの実装です。NEventStoreは、すべてのイベントが新しい昇順チェックポイントシーケンス番号を取得する追加専用のイベントストアを実装します。クライアントは、チェックポイント順にイベントストアからイベントを読み取りますすべての種類の計算を実行するため。チェックポイントXのイベントが処理されると、クライアントは「新しい」イベント、つまりチェックポイントX + 1以上のイベントのみを考慮します。したがって、イベントをスキップしないことが重要です。現在、Identityベースのチェックポイント実装がこの要件を満たしているかどうかを判断しようとしています。これらは、使用されている正確なSQLステートメントです。Schema、Writerのquery、読者の質問。） 私が正しいと上記の状況が発生する可能性がある場合、それらに対処する2つのオプションのみが表示されますが、どちらも不十分です。 Xを確認する前にチェックポイントシーケンス値X + 1を確認した場合は、X + 1を終了し、後で再試行してください。ただし、Identityもちろんギャップが発生する可能性があるため（たとえば、トランザクションがロールバックされるとき）、Xが来ることはありません。 したがって、同じアプローチですが、nミリ秒後にギャップを受け入れます。ただし、nのどの値を想定する必要がありますか？ より良いアイデアはありますか？

24 sql-server  locking  concurrency  identity 

この表が与えられた場合： CREATE TABLE dbo.Target ( TargetId int identity(1, 1) NOT NULL, Color varchar(20) NOT NULL, Action varchar(10) NOT NULL, -- of course this should be normalized Code int NOT NULL, CONSTRAINT PK_Target PRIMARY KEY CLUSTERED (TargetId) ); わずかに異なる2つのシナリオで、行を挿入し、ID列から値を返します。 シナリオ1 INSERT dbo.Target (Color, Action, Code) OUTPUT inserted.TargetId SELECT t.Color, t.Action, t.Code …

19 sql-server  sql-server-2012  insert  identity  bulk-insert 

私が取り組んでいる1つのWebアプリケーション内で、すべてのデータベース操作は、Entity Framework ORMで定義されたいくつかの汎用リポジトリを使用して抽象化されています。 ただし、汎用リポジトリのシンプルなデザインを実現するには、関連するすべてのテーブルで一意の整数（Int32C＃、intSQL）を定義する必要があります。これまで、これは常にテーブルのPKであり、IDENTITY。 外部キーは頻繁に使用され、これらの整数列を参照します。これらは、一貫性とORMによるナビゲーションプロパティの生成の両方に必要です。 通常、アプリケーション層は次の操作を実行します。 テーブルからの初期データロード（*）-SELECT * FROM table 更新 -UPDATE table SET Col1 = Val1 WHERE Id = IdVal 削除 -DELETE FROM table WHERE Id = IdVal 挿入 -INSERT INTO table (cols) VALUES (...) 頻度の低い操作： 一括挿入 - BULK INSERT ... into tableその後に（*）すべてのデータロード（生成された識別子を取得するため） 一括削除 -これは通常の削除操作ですが、ORMの観点からは「一括」です。DELETE FROM table where OtherThanIdCol …

18 sql-server  database-design  sql-server-2014  identity 

1から始まり1ずつ増加する一意の注文番号を生成しようとしています。このスクリプトを使用してPONumberテーブルを作成しています。 CREATE TABLE [dbo].[PONumbers] ( [PONumberPK] [int] IDENTITY(1,1) NOT NULL, [NewPONo] [bit] NOT NULL, [DateInserted] [datetime] NOT NULL DEFAULT GETDATE(), CONSTRAINT [PONumbersPK] PRIMARY KEY CLUSTERED ([PONumberPK] ASC) ); このスクリプトを使用して作成されたストアドプロシージャ： CREATE PROCEDURE [dbo].[GetPONumber] AS BEGIN SET NOCOUNT ON; INSERT INTO [dbo].[PONumbers]([NewPONo]) VALUES(1); SELECT SCOPE_IDENTITY() AS PONumber; END 作成時に、これは正常に機能します。ストアドプロシージャが実行されると、目的の数から始まり、1ずつ増加します。 奇妙なことは、コンピューターをシャットダウンまたは休止状態にした場合、次にプロシージャを実行すると、シーケンスがほぼ1000ずつ進んだことです。 以下の結果を参照してください。 数字が8から1002にジャンプしたことがわかります。 …

16 sql-server  sql-server-2012  identity 

IDENTITY列のあるテーブルがあります。開発中に、時々行を削除し、再度追加します。しかし、IDENTITY値は常に増加し続け、それらを再度追加したときに1から始まっていませんでした。私のIDは68から> 92になり、これによりコードがクラッシュします。 IDENTITY値をリセットするにはどうすればよいですか？

16 sql-server  alter-table  ddl  auto-increment  identity 

SQL Server Management Studio 2008（データベースはSQL Server 2005）のテーブルに行を手動で挿入するたびに、新しい行はリストの一番下ではなく一番上に表示されます。ID列を使用しているため、次のような結果になります id row 42 first row 1 second row 2 third row 行がフェッチされ、明示的に順序付けされていない場合。これにより、Webアプリの行がフェッチされたときに外観が異なり、TOP 1クエリが返すものが変更されます。 私はorder by彼らができることを知っていますが、なぜこれが起こっているのですか？私のデータのほとんどはWebアプリケーションを介して挿入され、このアプリケーションからのすべての挿入は、先入れ先出しの順序になります。たとえば、最新の挿入は下にあるため、IDはすべて連続しています。サーバーまたはManagement Studioに、この不適切な順序付けを引き起こす設定がありますか？

14 sql-server  ssms  identity 

IDENTITY列のみを持つテーブルがある場合、新しい行をどのように挿入しますか？私は次を試しました： INSERT INTO TABLE (Syntax error) INSERT INTO TABLE VALUES() (Syntax error) INSERT INTO TABLE (Id) VALUES() (Syntax error) 私は何かをテストしていますが、IDENTITY列のみが必要です。本番用ではありません。それ以外の場合、このようなテーブルは、他の列が不要なシーケンスジェネレーターとして使用できます。

14 sql-server  identity 

別のDBに既に存在するDBにテーブルを作成しました。最初は古いDBデータが入力されていました。テーブルのPKは、それらのレコードに既に存在する値を受信する必要があったため、自動インクリメントすることはできませんでした。 ここで、PKを自動インクリメントとして使用する新しいテーブルが必要です。しかし、PKが既に存在し、データを取得した後、どうすればそれができますか？

13 sql-server  primary-key  auto-increment  identity 

誰かが私にこの方向を正しい方向に向けてくれることを望んでいます。これが私のこれまでの成果です。 SELECT * FROM sys.identity_columns"last_value"を与えるシステムビューですが、そのビューの定義は内部関数を使用しますIdentityProperty(colName, 'LastValue')-したがって、それは行き止まりです（そこでシステムテーブルからプルしません）。 インターネットのどこでも（私が見た）DBCC IDENT_...コマンドを使用して値を明らかにすることを提案していますが、それでも実際に保存されている場所については暗闇の中に残ります。 そこで、DBCC PAGE(TestDB,1,1325,3)テストハーネスデータベースに対して個々のページを検索し、RESEEDコマンドを使用して値10と12の間で再シードすることにしました。 これを行うには、私は上の進値に気づいたIAM: Header、IAM: Single Page AllocationsとIAM: Extent Alloc Status Slot 1すべてが変わりました。（また、bUse1の値は、それ自体で徐々に変化しますが、とにかく定期的に変化することに気付きました）。 だからもう一つの行き止まりと私はすべてのアイデアからです。他にどこで検索できますか？ 私はSQL Server 2014を実行しています。内部知識に対する飽くなき渇望がありますが、これほど理解しにくいものはまだありません。理論的には（絶対値）がどこかに保存され、（ほぼ間違いなく）位置を特定できるはずなので、私の注意を引きました。内部的に保存されたデータ/メタデータの場所を発見する私の探求において、この特定の値は私が特にとらえどころのないものとして私を打つ。私は誰かが一緒に来て私に言うことを推測/望んでいます、あなたはそれを手に入れることができますがDBCC PAGE、間違った場所を見ていました。

12 sql-server  sql-server-2014  identity  database-internals 

重複がテーブルに入力されないようにするために使用される複合主キー（4列で構成される）を持つテーブルがあります。このテーブルのキーを外部キーとして参照する必要がある新しいテーブルが必要になりました。 私の質問は、どのアプローチがルックアップ速度にとってより効率的かです： 1）4列すべてを含む新しいテーブルを作成し、それらをすべて外部キーで参照しますか。 または 2）主キーテーブルに新しいID列を作成し、これを新しいテーブルの外部キーとして使用しますか。 このデータベースは非常に大量のデータを保持することが期待されているため、各テーブルに保持されるデータ量を最小限に抑えることを目的として、これまで構築してきました。これを念頭に置いて、すべての行に2つのint列とdatetime列を保存するため、オプション2が最適なアプローチになりますが、不要な場合はルックアップ時間の増加を避けたいと思います。

12 sql-server-2008  database-design  primary-key  identity  composite-types 

大学（私は学生です）での最後のレッスンの1つで、講師から、データベース（必要に応じてMySQLサーバー）と、データベースをデータソースとして使用する小さなクライアントアプリを開発するように依頼されました。 要件の1つは、ID列（すべてのテーブルのPK）が連続している必要があることです。つまり、テーブル行が削除された場合、そのPKは後続の挿入で再利用する必要があります。RDBMS、PK、およびID列に関する平均的な知識があります。私が理解していることから、そのID列は、行を挿入するときにDBがPKを自動生成できるようにするための手段にすぎません。また、ID列の値は、（自然キーではない限り）行属性とは一切関係しません。 この要件（厳密に連続したID列）は私には不審でした。IDがシーケンシャルでない（削除によるギャップがある）場合、何が悪いのかを講師に尋ねてみましたが、「ユーザーにとっては便利であり、データベースを保守するDB管理者にとっては便利」という非常に抽象的な回答を得ました。具体的な例はありません。「ユーザーにとって便利」という議論は、ビジネスドメインでは何の意味もないため、ばかげているように思われます。 したがって、これらの理由が本当かどうか知りたいのですが。ID列を再シードする必要がある場合、つまりIDスペースが使い果たされた場合の1つだけを考えることができます。ただし、これは、ID列のタイプが誤って選択された場合int、bigintつまりuniqueidentifierテーブルに10億行が含まれている代わりに、または単純である場合に、より設計上の問題になります。ID列がクラスター化インデックスであるとします。ID列のギャップがインデックスのパフォーマンスに影響を与える可能性はありますか？多分私が知らない削除ごとに自動ID列が再シードされる実際の理由は他にもありますか？ 前もって感謝します！

11 mysql  identity  auto-increment