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

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

7
GUID対INT-主キーとしてどちらが良いですか？
私は使用する理由としない理由について読んGuidでいintます。 int小さく、速く、覚えやすく、時系列を保持します。そして、Guid私が見つけた唯一の利点は、それがユニークであることです。どちらの場合、a Guidはa よりも優れており、intその理由は？ 私が見たものからint、多くの場合、無関係である数の制限を除いて、欠陥はありません。 なぜ正確にGuid作成されたのですか？実際には、単純なテーブルの主キーとして機能する以外の目的があると思います。（Guid何かに使用する実際のアプリケーションの例は？） （Guid = UniqueIdentifier）SQL Serverのタイプ
5
PostgreSQLでのインデックスの機能
PostgreSQLでのインデックスの動作に関していくつか質問があります。Friends次のインデックスを持つテーブルがあります。 Friends ( user_id1 ,user_id2) user_id1そしてテーブルuser_id2への外部キーですuser これらは同等ですか？そうでない場合、なぜですか？ Index(user_id1,user_id2) and Index(user_id2,user_id1) 主キー（user_id1、user_id2）を作成すると、自動的にインデックスが作成され、 最初の質問のインデックスが同等でない場合、上記のプライマリキーコマンドでどのインデックスが作成されますか？
3
UUIDまたはGUIDを主キーとして使用する場合の欠点は何ですか？
分散システムを構築したいと思います。データベースにデータを保存する必要がありますが、一部のテーブルの主キーとしてUUIDまたはGUIDを使用すると便利です。UUID / GUIDは非常に大きく、ほとんどランダムであるため、この設計の欠点だと思います。別の方法は、自動インクリメントのINTまたはLONG​​を使用することです。 テーブルの主キーとしてUUIDまたはGUIDを使用することの欠点は何ですか？ おそらく、DBMSとしてDerby / JavaDB（クライアント上）とPostgreSQL（サーバー上）を使用します。
3
すべてのテーブルに単一フィールドのサロゲート/人工主キーが必要ですか？
代理キー/人工キーの一般的な利点の1つを理解しています。変更されないため、非常に便利です。これは、「人工」である限り、単一フィールドでも複数フィールドでも同じです。 ただし、各テーブルの主キーとして自動インクリメント整数フィールドを持つことはポリシーの問題のように思われる場合があります。これは常にそのような単一フィールドのキーを持っているのが最良のアイデアですか？なぜですか？ 明確にするために、この質問は人工対自然に関するものではなく、すべての人工キーを単一フィールドにする必要があるかどうかに関するものです
2
PKインデックスの列の順序は重要ですか？
同じ基本構造を持ついくつかの非常に大きなテーブルがあります。それぞれにRowNumber (bigint)とDataDate (date)列があります。データは毎晩SQLBulkImportを使用してロードされ、「新しい」データはロードされません-その履歴レコード（エンタープライズではなくSQL標準なので、パーティショニングはありません）。 データの各ビットは他のシステムに結び付ける必要があり、各RowNumber/DataDate組み合わせは一意であるため、それが私の主キーです。 SSMS Table DesignerでPKを定義した方法により、RowNumber最初とDataDate2番目にリストされていることに気付きました。 また、私の断片化は常に非常に高い〜99％であることに気付きます。 今、それぞれDataDateが一度しか表示されないため、インデクサーが毎日ページに追加することを期待していますが、実際にはRowNumber最初に基づいてインデックス付けされているので、他のすべてを移動する必要がありますか？ RownumberID列ではなく、外部システムによって（悲しいことに）生成されたintです。それぞれの開始時にリセットされますDataDate。 サンプルデータ RowNumber | DataDate | a | b | c..... 1 |2013-08-01| x | y | z 2 |2013-08-01| x | y | z ... 1 |2013-08-02| x | y | z 2 |2013-08-02| x | y | z ... …
1
外部キーのインデックスが必要
私はインデックス、プライマリキー、外部キーに苦労しています...そしてそれらすべてを持つ必要があります。 2つのテーブルがある場合、両方ともプライマリキーとして整数を持ちます。 最初のテーブルは、FKを介して2番目のテーブルの主キーを参照します。 両方のテーブルで、ID列に主キーインデックスがあります table1.ref_field2番目のテーブルのPKを参照するFK制約を作成しました（table2.id） にインデックスを追加しました table1.ref_field これは、これらのインデックス、プライマリキー、外部キーを整理する最良の方法ですか？
5
ルックアップテーブルの主キーとしてintを使用する理由
ルックアップ値を主キー（ほとんどの場合は文字列）として使用するのではなく、なぜルックアップテーブルの主キーとしてintを使用する必要があるのか​​を知りたい。 intではなくnvarchar（50）を使用すると、多くのレコードを持つテーブルにリンクされている場合、より多くのスペースが使用されることを理解しています。 一方、ルックアップ値を直接使用すると、基本的に結合を行う必要がなくなります。参加が常に必要な場合、これは大きな節約になると想像できます（Webアプリで作業しているので、これはかなり重要です）。 int主キー（特にルックアップテーブル用）を使用することの利点は、「行うべき標準的なこと」以外に何ですか？
3
文字対整数の主キー
メインエンティティの可能な属性を含む複数のルックアップテーブルを持つデータベースを設計しています。これらの属性IDをメインテーブルに格納するときに、単なる乱数ではなく意味のある値が表示されるように、自動インクリメント整数ではなく、4または5文字のキーを使用してこれらのルックアップ値を識別することを考えています。 文字フィールドを整数ではなく主キーとして使用すると、パフォーマンスにどのような影響がありますか？ それが重要な場合は、MySQLを使用しています。 [編集] これらのルックアップテーブルには、まれに新しいレコードが追加されます。それらは手動で保守され、文字ベースのキーも手動で作成されます。以下に例を示します。 CUISINES ID Description ----- -------------- CHNSE Chinese ITALN Italian MXICN Mexican
1
SQL Azureの既存の主キーを変更するにはどうすればよいですか？
SQL Azureテーブルの既存のプライマリキーを変更したい。 現在、1つの列があり、別の列を追加したいと思います。 さて、SQL Server 2008では、これは簡単なことでした。SSMSでやっただけです。できた これは、SQL Serverからスクリプトを作成した場合のPKの外観です。 ALTER TABLE [dbo].[Friend] ADD CONSTRAINT [PK_Friend] PRIMARY KEY CLUSTERED ( [UserId] ASC, [Id] ASC ) ただし、SQL Azureでは、上記を実行しようとすると、もちろん失敗します。 Table 'Friend' already has a primary key defined on it. 結構です、私はキーを落とそうとします： Tables without a clustered index are not supported in this version of SQL Server. …
1
MySQLで主キーとして複数のフィールドを設定する方法は？
フィールドを持つテーブルがあります 従業員ID ブラブラ blahblah2 ..... RecordMonth RecodrdYear そのため、各従業員には、月、年、Emp＃のエントリのみが一致する必要があります。テーブルを設定するにはどうすればよいですか。 それでは、月に1回EmployeeIDを更新できるが、一致する月と年に2つのエントリを持たないようにテーブルを設定するにはどうすればよいですか？
3
テーブルが主キーをそれ自体の外部キーとして使用する理由
データベースを調べてみると、主キーをそれ自体の外部キーとして使用するテーブルに出会いました。 テーブルは、階層構造を構築するためにそれ自体への外部キーを持つことができますが、主キーを参照するために別の列を使用します。 主キーは一意であるため、この状況では行は自分自身を指すことしかできませんか？これはトートロジーのリンクのようです。なぜなら、もし私が列をすでに持っているなら、列をすでに持っているからです。 これが行われる理由はありますか？ 定義の両方の半分に同じテーブルと列が使用されているため、制約はそのように書かれています（ダイアグラムを見るだけではありません）。
4
DBMSの主キーとスーパーキーの違いは何ですか
私はDBMSに不慣れで、まだ理論を学んでいます。 私はこの重要なビジネスに本当に混乱しており、グーグルで検索した後、取得できない2つのキー（プライマリキーとスーパーキー）に絞り込みました。 DBMSに関していくつか質問があります。あなたが私のためにそれらに答えることができれば私は感謝するでしょう。 1）DBMSのプライマリキーとスーパーキーの違いは何ですか？ 包括的な例を使用して適切に説明できる場合は、高く評価してください 2）プライマリキーとスーパーキーの両方に複数の列を組み合わせて、プライマリキーとスーパーキーを形成できますか？ 3）主キーはスーパーキーのサブセットですか、またはその逆ですか？
5
主キーに独自の名前があるのはなぜですか？
数学的な観点から、テーブルには多くても1つの主キーがあると認められるため、単純なテーブルプロパティではなく、任意の名前で主キーを参照するという近視眼的な設計決定のようです。 主キーを非クラスター化からクラスター化、またはその逆に変更する結果として、まずその名前を検索し、削除してから最後に読み取ります。 表示されない任意の名前を使用することには利点がありますか、またはプライマリキーに任意の名前を使用しないDBMSがありますか？ 2011年 2月22 日の編集（2011年 2月22日、日付を並べ替えたくない人向け）： テーブル名から主キーの名前を導出できる関数を示しましょう（初期のsql-sever別名sybaseシステムテーブルを使用）： create function dbo.get_pk (@tablename sysname) returns sysname as begin return (select k.name from sysobjects o join sysobjects k on k.parent_obj = o.id where o.name = @tablename and o.type = 'U' and k.type = 'k') end go gbnは、明示的な名前を指定しない場合、生成された名前を本当に好きな人はいないと述べています。 create table example_table ( id …
4
Postgresがすでに使用されているPK値を生成するのはなぜですか？
私はDjangoを使用していますが、時々このエラーが発生します： IntegrityError：重複キー値が一意の制約 "myapp_mymodel_pkey"に違反しています 詳細：キー（id）=（1）は既に存在します。 実際、私のPostgresデータベースには、主キーが1のmyapp_mymodelオブジェクトがあります。 Postgresが再びその主キーを使用しようとするのはなぜですか？または、これはおそらくアプリケーション（またはDjangoのORM）がこれを引き起こしているのでしょうか？ この問題は、ちょうど3回続けて発生しました。私が見つけたのは、それが発生した場合、特定のテーブルの行で1回以上発生し、その後は発生しないことです。これは、数日間完全に停止する前にすべてのテーブルで発生し、発生したテーブルごとに少なくとも1分程度発生し、断続的にのみ発生するようです（すぐにすべてのテーブルが発生するわけではありません）。 このエラーが非常に断続的である（2週間で3回程度しか発生しなかった-DBに他の負荷がなく、アプリケーションをテストしているだけである）ため、低レベルの問題に非常に警戒しています。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.