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

テーブルにID列を作成します。このプロパティは、CREATE TABLEおよびALTER TABLE Transact-SQLステートメントで使用されます。

1
列のIdentityプロパティの削除がサポートされていないのはなぜですか
SQL Server 2000以降、ID列を "非ID"にする機能が削除されたことを読んだことがあります。そして、これは「設計どおり」でした(欠けている機能だけでなく)。 これが私がブログで見つけた例です。システムテーブルの更新が含まれます。(そしてその機能はSQL Server 2000の後で削除されました。)私はシステムテーブルを介してこれを行うのは良い考えではないことを理解しています。なぜこれを別の方法で実行する機能がないのか疑問に思っています。 これを回避すると、かなりの量の作業が必要になります。(ダウンタイムに耐えられない環境で、数億行を新しいテーブルにコピーする。) だから、「なんで」と聞いてみました。 SQL Server 2005以降のバージョンで何が変更されて、これは悪いことでしたか?それとも、それは常に悪いことでしたか? ID列を再び通常の列にすることにより、どの「ベストプラクティス」(または同様の原則)に違反しますか? - 「 これを行う理由」の要求に答えるための更新:これは非常に高レベルの要約です:テーブルにパーティションを追加し始めます。(古いデータをアーカイブ/パージできるようにするためです。)それは簡単です。ただし、レコードが別のパーティションに移動して、削除されないようにする必要がある場合があります(パーティションがアーカイブ/削除のために表示される場合)。(行を別のパーティションに移動するためのスペースが常にあるように、パーティション列を2増やしています。) しかし、パーティション列がID列の場合、値を削除して再挿入する必要があります(ID列の値を更新する方法はありません)。これにより、レプリケーションで問題が発生します。 そのため、ID列の代わりにシーケンスを使用したいと考えています。しかし、その切り替えは、大規模なデータベースでは非常に困難です。

8
一意のIDを明示的に生成するID列またはUDF?
私は、一意のIDを明示的に生成するUDFからPRIMARY KEY、Identity Columnsを使用する方が良いかどうかについて議論しています。 Identity列について議論しています。 私のパートナーは、手動で値を生成することを主張しています、と彼は主張します UDFを作成できる別のテーブルにUDFを配置する リソースをロックする ID_Valueによって呼び出される1つのフィールドでIDテーブルをインクリメントする1 これをグローバル一意識別子として使用します またはid+1、挿入時にテーブルに 識別制約のないサーバーや環境間でデータを移動する方が簡単です。データがあるDBから、ステージングデータやダミーデータなどの別の類似のDBに移動する。非本番環境でのテストでは、すべてのレコードを昨日からテスト用のステージングまで引き下げたい場合があります。 どの実装がより意味がありますか?

1
IDENTITY_INSERTは並行性にどのように影響しますか?
投稿に不具合があり、サポートが終了したサードパーティのSAPアドオンを使用してお客様を支援しようとしています。 特定の状況下では、投稿キューテーブルから投稿アーカイブテーブルへの不完全な投稿をアーカイブします。これらのアーカイブされた結果をキューに戻す必要があります。 キューIDはID列であり、同じにしたいと思います。 問題は、identity_insertをオン/挿入/ identity_insertオフにすると、キューエントリを作成し、ID列が自動的に生成されることを期待するプロセスとの同時実行性に関して何が期待できるでしょうか。 そのような振る舞いを実証するための最良の方法へのポインタも同様に大歓迎です。

2
主キーの代わりにIDを使用することをお勧めしますか?
私たちは宣言できIdentityようにid_numそれはとてもid_numユニークな番号の増分を持つことになります。 CREATE TABLE new_employees ( id_num int IDENTITY(1,1), fname varchar (20), minit char(1), lname varchar(30) ) 各行に一意の番号が提供さIdentityれているPrimary keyため、の代わりに使用することをお勧めしますIdentityか?

1
COALESCEを使用して主キーをIDENTITYから永続化された計算列に変更する
モノリシックデータベースからアプリケーションを分離するために、さまざまなテーブルのINT IDENTITY列を、COALESCEを使用するPERSISTED計算列に変更しようとしました。基本的に、分離アプリケーションには、多くのアプリケーションで共有される共通データのデータベースを更新しながら、コードやプロシージャを変更することなく、既存のアプリケーションがこれらのテーブルにデータを作成できる機能が必要です。 したがって、基本的に、列の定義から移動しました。 PkId INT IDENTITY(1,1) PRIMARY KEY に; PkId AS AS COALESCE(old_id, external_id, new_id) PERSISTED NOT NULL, old_id INT NULL, -- Values here are from existing records of PkId before table change external_id INT NULL, new_id INT IDENTITY(2000000,1) NOT NULL すべての場合でPkIdは主キーでもあり、1つを除いてすべてクラスタ化されています。すべてのテーブルには、以前と同じ外部キーとインデックスがあります。本質的に、新しい形式では、PkIdを分離されたアプリケーションから(external_idとして)提供できますが、PkIdをIDENTITY列の値にすることもできるため、SCOPE_IDENTITYおよび@@ IDENTITYを使用してIDENTITY列に依存する既存のコードを許可できます。以前と同じように動作します。 私たちが抱えていた問題は、許容範囲内で実行されていたクエリが2つ出てきて、完全に機能しなくなったことです。これらのクエリで使用される生成されたクエリプランは、以前のクエリプランとは異なります。 新しい列がPRIMARY KEY、以前と同じデータ型、およびPERSISTEDであることを考えると、クエリとクエリプランは以前と同じように動作するはずです。COMPUTED PERSISTED INT PkIdは、SQL Serverが実行プランを生成する方法に関して、本質的に明示的なINT定義と同じように動作する必要がありますか?あなたが見ることができるこのアプローチの他の可能性のある問題はありますか? …

2
ID列をINTからBIGINTに変更する
主キーでもあるID列を持つテーブルがあります。現在、5000万行あり、identity列の最高値は148,921,803です。テーブルには多くのがあり、そのテーブルDELETEでINSERTS実行されるため、値が高くなります。 私たちは、からのデータ型を変更したいINTとBIGINT多くの行を追加するための準備します。PK列への参照がないことに注意してください。 最小限のダウンタイムでこれを行うための最良の方法は何ですか?2つのオプションがあります。 PKをドロップして列を変更します。または ここで説明するように、copy-drop-renameメソッド:


3
FK関係を維持しながら、ID列を含む新しいテーブルにデータを移行する方法
データベース間でデータを移行したい。テーブルスキーマはまったく同じです。 CREATE TABLE Customers( [Id] INT NOT NULL PRIMARY KEY IDENTITY, (some other columns ......) ); CREATE TABLE Orders( [Id] INT NOT NULL PRIMARY KEY IDENTITY, [CustomerId] INT NOT NULL, (some other columns ......), CONSTRAINT [FK_Customers_Orders] FOREIGN KEY ([CustomerId]) REFERENCES [Customers]([Id]) ) 2つのデータベースには異なるデータがあるため、同じテーブルの新しいIDキーは2つのデータベースで異なります。それは問題ではない; 私の目標は、既存のデータに新しいデータを追加することであり、テーブル全体のすべてのデータを完全に置き換えることではありません。ただし、挿入されたデータのすべての親子関係を維持したいと思います。 SSMSの「スクリプトの生成」機能を使用すると、スクリプトは同じIDを使用して挿入を試み、宛先データベースの既存のデータと競合します。データベーススクリプトのみを使用してデータをコピーするにはどうすればよいですか? 宛先のID列を最後の値から通常どおりに継続させたい。 Customers他のUNIQUE NOT NULL制約はありません。他の列に重複するデータがあっても問題ありません(ここでは例として使用CustomersしOrdersているので、全体を説明する必要はありません)。問題は、1対Nの関係についてです。

1
SQL Serverで$ IDENTITYは文書化され、信頼できますか?
SQL Serverが疑似列を使用してテーブルの(単一の)ID列の値を返すことができることを学びました$IDENTITY: SELECT $IDENTITY FROM Table この機能は文書化され、信頼できますか?それについての唯一の公式の言及はIDENTITYページにありますが、コードサンプルに埋め込まれています。これは、文書化されていないことを意図している可能性があることを示唆しています。この機能についても、Googleによる一致はほとんどありません。

2
主キーを持つ「INTO」テーブルを作成する
たぶんこのコミュニティにとって私の問題は簡単ですが、私(単純なJavaプログラマー)にとってはそれは大きな問題です。 ますます多くのデータを含むBig DBがあります。したがって、外部データベース管理者は、一時テーブルに必要なデータを表示するジョブを作成しました。しかし、彼は主キーなしでテーブルを作成していました。私のJavaプロジェクトでこのテーブルを読みに行くと、エラーが発生します。 主キーが存在しないため、このテーブルを読み取ることができません。 この複雑なプロシージャの構造を変更せずに、自動インクリメンタル主キーを作成する可能性をプロシージャに挿入できますか? これは、ストアドプロシージャコードの始まりです。 USE [MYDB] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER Procedure [dbo].[spSchedula_Scadenzario] as begin drop table MYDB.dbo.tmpTable select aa.* into MYDB.dbo.tmpTable from (...) 前もって感謝します
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.