タグ付けされた質問 「primary-key」

リレーショナルデータベースの設計では、主キーはテーブルの各行を一意に識別できます。主キーは、単一の列または列のセットで構成されます。

8
主キーの値が変わるのはなぜですか？
私は最近ROWGUIDの概念を研究しており、この質問に出くわしました。 この答えは洞察を与えましたが、主キーの値を変更するという言及で、私を別のウサギの穴に導きました。 私の理解では、主キーは不変である必要があり、この回答を読んだ結果、ベストプラクティスと同じものを反映した回答しか得られなかったため、検索を続けてきました。 レコードが作成された後に主キー値を変更する必要があるのはどのような状況ですか？
4
GUIDを主キーとして使用してデータベース設計を修正する最適なソリューション
私は、このアイデアをある程度確認した後、パフォーマンスの悪いデータベースを修正するか、データベースがある場合はより良い提案をします。常により良い提案を受け入れます。 GUIDをPKとして使用している非常に大規模なデータベース（1日あたり約20万件増加する2000万件以上のレコード）があります。 私の側の見落としですが、PKはSQLサーバーにクラスター化されており、パフォーマンスの問題を引き起こしています。 GUIDの理由-このデータベースは他の150個のデータベースと部分的に同期されているため、PKは一意である必要がありました。同期はSQL Serverによって管理されるのではなく、システムの要件に合わせてデータの同期を維持するカスタムプロセスが構築され、すべてがそのGUIDに基づいています。 150のリモートデータベースのそれぞれは、中央のSQLデータベースに格納されているような完全なデータを格納しません。実際に必要なデータのサブセットのみを保存し、必要なデータはそれらに固有ではありません（150のデータベースのうち10が他のサイトデータベースからの同じレコードの一部を持っている場合があります-それらは共有しています）。また、データは実際には中央サイトではなくリモートサイトで生成されるため、GUIDが必要です。 中央データベースは、すべての同期を維持するためだけでなく、3000以上のユーザーからのクエリがその非常に大きな断片化されたデータベースに対して実行されます。すでにこれは初期テストの大きな問題です。 幸いなことに、私たちはまだ生きていません。必要に応じて変更を加えてオフラインにすることができます。これは少なくとも何かです。 リモートデータベースのパフォーマンスは問題ではありません。データサブセットは非常に小さく、通常、データベースの合計サイズが1GBを超えることはありません。レコードはメインシステムに非常に定期的にフィードバックされ、不要になったときに小さいBDから削除されます。 すべてのレコードのキーパーである中央DBのパフォーマンスは、その多くのレコードの主キーとしてのクラスター化されたGUIDのために悲惨です。インデックスの断片化はチャートから外れています。 だから-パフォーマンスの問題を修正するための私の考えは、新しい列を作成することです-符号なしBIGINT IDENTITY（1,1）し、テーブルBIGINT列のクラスターPKを変更します。 主キーであるGUIDフィールドに一意の非クラスター化インデックスを作成します。 小規模なリモート150データベースは、Central SQL Serverデータベースの新しいPKについて知る必要はありません。これは、データベース内のデータを整理し、パフォーマンスの低下と断片化を防ぐために純粋に使用されます。 これは機能し、中央のSQLデータベースのパフォーマンスを向上させ、将来のインデックスの断片化を防ぎます（もちろん）。または、ここで非常に重要な何かを見逃したことがあります。
2
複合キーの最初の部分としてDATETIMEを持つ主キーインデックスは使用されません
PRIMARY KEYの最初の部分として、DATETIME（または日付）のインデックス付けに問題があります。 MySQL 5.5を使用します これが私の2つのテーブルです。 -- This is my standard table with dateDim as a dateTime CREATE TABLE `stats` ( `dateDim` datetime NOT NULL, `accountDim` mediumint(8) unsigned NOT NULL, `execCodeDim` smallint(5) unsigned NOT NULL, `operationTypeDim` tinyint(3) unsigned NOT NULL, `junkDim` tinyint(3) unsigned NOT NULL, `ipCountryDim` smallint(5) unsigned NOT NULL, `count` …
4
テーブルのすべての列を含む主キーの利点はありますか？
4つの列がすべてNULL不可のテーブルがあり、一意のレコードを区別するには4つすべてが必要なデータです。これは、主キーを作成する場合、すべての列を構成する必要があることを意味します。テーブルに対するクエリは、ほとんどの場合、単一のレコードをプルバックします。つまり、クエリですべての列がフィルタリングされます。 すべての列を検索する必要があるため、主キーを持つことは（レコードの一意性を強制することに加えて）まったく私に利益をもたらしますか？
2
単純な結合で使用されない主キーのインデックス
次の表とインデックスの定義があります。 CREATE TABLE munkalap ( munkalap_id serial PRIMARY KEY, ... ); CREATE TABLE munkalap_lepes ( munkalap_lepes_id serial PRIMARY KEY, munkalap_id integer REFERENCES munkalap (munkalap_id), ... ); CREATE INDEX idx_munkalap_lepes_munkalap_id ON munkalap_lepes (munkalap_id); munkalap_idのインデックスが次のクエリで使用されないのはなぜですか？ EXPLAIN ANALYZE SELECT ml.* FROM munkalap m JOIN munkalap_lepes ml USING (munkalap_id); QUERY PLAN Hash Join (cost=119.17..2050.88 …
4
キーを明示的にする必要があるのはなぜですか？
私はデータベースの主題について非常に新しいので、これは無知に聞こえるかもしれませんが、テーブル内でキーを明示的にする必要がある理由を知りたいです。これは主に、指定された列の値が（できれば）各行内で一意であることが保証されていることをユーザーに伝えるためですか？言及されていない場合でも、一意性は存在する必要があります。
4
SQL Serverデッドロックレポートのキーを値に変換するにはどうすればよいですか？
waitresource = "KEY：9：72057632651542528（543066506c7c）"に関連する競合があったことを示すデッドロックレポートがあり、これを見ることができます。 <keylock hobtid="72057632651542528" dbid="9" objectname="MyDatabase.MySchema.MyTable" indexname="MyPrimaryKeyIndex" id="locka8c6f4100" mode="X" associatedObjectId="72057632651542528"> <resource-list>内。キーの実際の値（id = 12345など）を検索できるようにしたい。その情報を取得するには、どのSQLステートメントを使用する必要がありますか？
4
主キーでソート順が指定されているが、SELECTでソートが実行されている
センサーデータをSensorValuesテーブルに格納しています。テーブルと主キーは次のとおりです。 CREATE TABLE [dbo].[SensorValues]( [DeviceId] [int] NOT NULL, [SensorId] [int] NOT NULL, [SensorValue] [int] NOT NULL, [Date] [int] NOT NULL, CONSTRAINT [PK_SensorValues] PRIMARY KEY CLUSTERED ( [DeviceId] ASC, [SensorId] ASC, [Date] DESC ) WITH ( FILLFACTOR=75, DATA_COMPRESSION = PAGE, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = …
2
リレーショナルデータベースのルックアップテーブルに関するベストプラクティスは何ですか？
ルックアップテーブル（またはコードテーブルと呼ばれることもあります）は、通常、特定の列に指定できる値のコレクションです。 たとえば、次のparty2つの列を持つ（政党に関する情報を保存するための）というルックアップテーブルがあるとします。 party_code_idn、システム生成の数値を保持し、（ビジネスドメインの意味を欠いて）実際のキーの代理として機能します。 party_codeは、ビジネスドメインの意味を持つ値を保持するため、テーブルの実際のキーまたは「自然な」キーです。 そして、そのようなテーブルは以下のデータを保持しているとしましょう： +----------------+------------+ | party_code_idn | party_code | +----------------+------------+ | 1 | Republican | | 2 | Democratic | +----------------+------------+ party_code値は「共和党」と「民主党」を続けるの列は、テーブルの実際のキーであること、UNIQUE制約に設定されているが、私は必要に応じて添加party_code_idnし、論理的に言えば、ものの（表のPKとしてそれを定義しました、party_codeプライマリキー[PK]として機能する場合があります）。 質問 トランザクションテーブルからルックアップ値を指すためのベストプラクティスは何ですか？FOREIGN KEY（FK）参照を確立する必要があります（a）自然で意味のある値を直接参照するか、（b）値を代理しますか？ オプション（a）、たとえば +---------------+------------+---------+ | candidate_idn | party_code | city | +---------------+------------+---------+ | 1 | Democratic | Alaska | | 2 | Republican | Memphis …
5
「巨大な」データベーステーブルPKのシーケンシャルGUIDまたはbigint
この種の質問がたくさん出てくることは知っていますが、この決定を下すのに役立つ説得力のある議論をまだ読んでいません。我慢してください！ 私には巨大なデータベースがあります-それは1日あたり約10,000,000レコード増加します。データはリレーショナルであり、パフォーマンス上の理由から、BULK COPYでテーブルをロードします。このため、行のキーを生成する必要があり、IDENTITY列に依存することはできません。 64ビット整数（bigint）は使用するのに十分な幅がありますが、一意性を保証するには、IDを作成するための集中ジェネレーターが必要です。私は現在、サービスがXシーケンス番号を予約し、衝突がないことを保証するようなジェネレーターサービスを持っています。ただし、この結果は、私が持っているすべてのサービスがこの1つの集中ジェネレーターに依存しているため、システムの配布方法が制限され、他の依存関係（ネットワークアクセスの要求など）に満足できませんこの設計によって。これはときどき問題になりました。 プライマリGUID（SQLの外部で生成される）としてシーケンシャルGUIDを使用することを検討しています。私自身のテストで確認できた限り、これらの唯一の欠点は、より広いデータ型のディスク領域のオーバーヘッドです（インデックスでの使用により悪化します）。bigintの選択肢と比較して、クエリのパフォーマンスが目に見えるほど遅くなることはありません。BULK COPYを使用したテーブルのロードはわずかに遅くなりますが、それほどではありません。GUIDベースのインデックスは、シーケンシャルGUID実装のおかげで断片化されていません。 基本的に、私が知りたいことは、私が見落としているかもしれない他の考慮事項があるかどうかです。現時点では、私は飛躍してGUIDを使い始めたいと思っています。私は決してデータベースの専門家ではないので、どんなガイダンスでも大歓迎です。
5
データベース全体で単一のプライマリキーシーケンスを共有していますか？
すべてのテーブルで単一のシーケンスを主キーとして使用することは受け入れられる慣行ですか？その場合、テーブル全体で単一の主キーシーケンスを使用するよりも客観的に優れていますか。 私はDBAではなく、ジュニアソフトウェア開発者なので、優れたデータベース設計の基本の多くをまだ学んでいます。 編集：誰かが疑問に思っている場合、私は最近、私たちのデータベース管理者の1人によるデータベース設計の批判を読みました。私はこれまでに学びました。 編集2：コメントの質問に答えるために、これはOracle 11g用ですが、データベース固有ではないレベルで疑問に思っていました。この質問がデータベースに依存する場合、その理由を知りたいと思いますが、そのような場合、Oracleに固有の回答を探しています。
4
既存のPKに自動インクリメントを追加する
別のDBに既に存在するDBにテーブルを作成しました。最初は古いDBデータが入力されていました。テーブルのPKは、それらのレコードに既に存在する値を受信する必要があったため、自動インクリメントすることはできませんでした。 ここで、PKを自動インクリメントとして使用する新しいテーブルが必要です。しかし、PKが既に存在し、データを取得した後、どうすればそれができますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.