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

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

4
MySQL:auto_incrementが主キーだけに制限されているのはなぜですか?
MySQLがauto_incrementカラムを主キーに制限していることを知っています。どうしてこれなの?私の最初の考えは、この値を取得するためにロックする必要があるカウンターテーブルがどこかにある可能性があるため、これはパフォーマンスの制限だということです。 同じテーブルに複数のauto_increment列を含めることができないのはなぜですか? ありがとう。


3
インデックスと制約の一覧表示
継承したアプリケーションのSQL Serverデータベースを見ています。約10年間SQL Serverを調べていませんので、ご容赦ください。 私が調べているデータベーステーブルにはというbigint NOT NULL列がありますがid、制約を確認しても何も表示されず、すべてのデータベーステーブルに同じことが当てはまります。 これらのテーブルに主キーとインデックス(クラスター化または非クラスター化)がないと仮定しても正しいですか? 私は次のクエリを実行しましたが、結果は私の疑いを裏付けるように見えます。 //**returns 0** select count(*) from INFORMATION_SCHEMA.TABLE_CONSTRAINTS; //**returns no rows** select * from sys.indexes where object_id = (select object_id from sys.objects where name = 'NAME-OF-TABLE'); //**returns all tables in database** SELECT name FROM sys.tables WHERE OBJECTPROPERTY(object_id,'IsIndexed') = 0;

3
PKの目的でのみ、自動インクリメント/ IDENTITYフィールドを相互参照テーブルに追加する必要がありますか?
次の相互参照テーブルをSQL ServerがホストするDBに追加します。 company_id bigint not null (FK) org_path nvarchar (2048) not null company_idフィールドはid、別のテーブルのフィールドを参照します(そのフィールドが主キーです)。 同じを持つ複数のレコードも存在する可能性があることを考えるとcompany_id、主キーは両方のフィールドを使用する必要があります。ただし、org_pathSQL Serverには長すぎるため、両方のフィールドを使用してキーを作成できません。 に関してはorg_path、これが存在する唯一のテーブルです。このテーブルへのクエリがすべてのエントリまたはすべてのorg_pathエントリのいずれかを要求する可能性はほとんどありませんcompany_id。別の言い方をすると、このテーブルがによってクエリされることは疑わしいようorg_pathです。さらに、org_path更新される可能性は低く、おそらく挿入され、おそらく削除されることはほとんどありません。 行の総数は数千になると思います。 また、その理由nvarchar (2048)は、値がサードパーティのDBの値を模倣する必要があるためです。典型的な例は次のようになります \Translation Providers\[customer name]\[order name]\ 分音符号を含めることができます。 だから私の質問はこれです:自動インクリメントidフィールドを追加しcompany_idてそれを主キーとして使用する方が効率的ですか、それとも不必要なオーバーヘッドが追加されますか-そしてcompany_id、別のテーブルの主キーであるという事実にはここで効果?

2
Oracle USING INDEX句に相当するSQL Server
OracleのUSING INDEX句に相当するSQL Server 2008はありますか?具体的には、構成: CREATE TABLE c(c1 INT, c2 INT); CREATE INDEX ci ON c (c1, c2); ALTER TABLE c ADD CONSTRAINT cpk PRIMARY KEY (c1) USING INDEX ci; Sql Server Documentation on Unique Indexsには、次のように記載されています(強調を追加)。 一意のインデックスは、次の方法で実装されます。 PRIMARY KEYまたはUNIQUE制約 PRIMARY KEY制約を作成すると、テーブルにクラスター化インデックスがまだ存在せず、一意の非クラスター化インデックスを指定しない場合、列に一意のクラスター化インデックスが自動的に作成されます。主キー列はNULL値を許可できません。 これは、主キーに使用するインデックスを指定する方法があることを意味しているようです。

3
1つを除くすべての列を主キーとしてマークすることは妥当ですか?
映画を表すテーブルがあります。フィールドは次のとおり id (PK), title, genre, runtime, released_in, tags, origin, downloadsです。 重複する行によってデータベースを汚染することはできないため、一意性を強制したいと思います。問題は、異なる映画が同じタイトルを持つ可能性があることです、または同じフィールドを除くtagsとdownloads。一意性を強制する方法は? 私は2つの方法を考えました: downloads主キーを除くすべてのフィールドを作成します。downloadsそれはJSONであり、おそらくパフォーマンスに影響を与えるため、私は締め出します。 id主キーとしてのみ保持しますが、他のすべての列(再度、を除くdownloads)で一意制約を追加します。 よく似たこの質問を読みましたが、どうすればいいのかよくわかりませんでした。現在、このテーブルは他のテーブルとは関係ありませんが、将来的には関係する可能性があります。 現時点では20,000件弱のレコードですが、その数は増えると思います。これが問題にある程度関連しているかどうかはわかりません。 編集:私はスキーマを変更しました、そしてここに私がテーブルを作成する方法があります: CREATE TABLE movies ( id serial PRIMARY KEY, title text NOT NULL, runtime smallint NOT NULL CHECK (runtime >= 0), released_in smallint NOT NULL CHECK (released_in > 0), genres text[] NOT NULL default …

2
SQL Serverは外部キー参照のインデックスキーをどのように選択しますか?
MS Accessからインポートされたレガシーデータベースを使用しています。MS Access> SQL Serverのアップグレード中に作成された、クラスター化されていない一意の主キーを持つ約20のテーブルがあります。 これらのテーブルの多くには、主キーの複製である一意の非クラスター化インデックスもあります。 私はこれを片付けようとしています。 しかし、主キーをクラスター化インデックスとして再作成した後、外部キーを再構築しようとすると、外部キーが(重複していた)古い重複インデックスを参照しています。 重複したインデックスを削除できないため、これを知っています。 SQL Serverでは、主キーが存在する場合は常にそれを選択すると思います。SQL Serverには、一意のインデックスと主キーの間で選択する方法がありますか? 問題を再現するには(SQL Server 2008 R2の場合): IF EXISTS (SELECT * FROM sys.tables WHERE name = 'Child') DROP TABLE Child GO IF EXISTS (SELECT * FROM sys.tables WHERE name = 'Parent') DROP TABLE Parent GO -- Create the parent table CREATE …

3
SQL Server 2005デッドロックシナリオのトラブルシューティング
デッドロックのシナリオに遭遇しています。デッドロックの唯一の関係者は、単一のテーブルと、そのテーブルから削除する単一のストアドプロシージャであるように見えます。エラーログのトレースを解読するガイドラインとして以下のMSDNの記事を使用して、これらのデッドロックのいくつかの時点でのSQLエラーログの私の分析に基づいて、その結論を導き出しました。 テーブルDEXTableとストアドプロシージャClearDEXTableRowsを以下に定義します。DEXTableに行を挿入する別のストアドプロシージャInsertDEXTableRowがありますが、そのプロシージャはSQLエラーログのエントリに基づくデッドロックに関与していないようです。 DEXTableには約830万行があり、着実に成長する傾向があります。回答者のテーブルも大きく、着実に成長する傾向があります。 ClearDEXTableRowsとInsertDEXTableRowをすばやく連続して頻繁に呼び出すページがある、トラフィック量の多いWebサイトからアクセスされます。 デッドロックは、過去10日間、1日あたり0〜9回発生しました。 1222のSQLトレースを有効にし(DBCC TRACEON 1222を使用)、最近フラグ1204を有効にしました。デッドロックの検出と終了に関するこれらのフラグの出力については、適切な説明があります 私の質問は: この1つのストアドプロシージャClearDEXTableRowsだけがデッドロックの原因であることは理にかなっていますか? もしそうなら、誰もがこれがどのように起こり得るかの良い説明を提供し、それを修正する方法を勧めることができますか? 私の疑いは、DELETEステートメントが頻繁に再構築する必要があるDEXTableのPKで競合を引き起こしていることです。 そうでない場合、デッドロックの原因をさらに掘り下げるには、どのような追加のトレースを有効にする必要がありますか?(私はここで学びたいです) -- Table definition CREATE TABLE [dbo].[DEXTable]( [ExportID] [int] NOT NULL, [RespondentID] [int] NOT NULL, [Exported] [datetime] NOT NULL, CONSTRAINT [PK_DEXTable] PRIMARY KEY CLUSTERED ( [ExportID] ASC, [RespondentID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = …


2
DynamoDB-複数の範囲キー
範囲キーとして複数のフィールドを持つことは可能ですか? 各行が一意に識別されるテーブルがあるとしましょう <A,B,C> ------------------------------- A | B | C | D | E | ------------------------------- A主hashキーはどこですか そして私が欲しいBとCプライマリにrangeキー。 DynamoDBの主キーとして3つ以上のフィールドを持つにはどうすればよいですか?

1
PostgreSQLでのシーケンスの圧縮
私が持っているid serial PRIMARY KEYPostgreSQLのテーブルの列を。id対応する行を削除したため、多くのが欠落しています。 ここで、シーケンスを再起動idし、元のid順序が維持されるようにs を再割り当てすることで、テーブルを「圧縮」したいと思います。出来ますか? 例: 今: id | data ----+------- 1 | hello 2 | world 4 | foo 5 | bar 後: id | data ----+------- 1 | hello 2 | world 3 | foo 4 | bar StackOverflowの回答で提案されたものを試しましたが、うまくいきませんでした: # alter sequence t_id_seq restart; ALTER SEQUENCE # …

3
InnoDBテーブルの複合セカンダリインデックスの最後の列として主キーを持つことは何をしますか?
たとえば、1対Nの関係があるとし(person_id, pet_id)ます。pet_idが主キーであるテーブルがあります。 InnoDBセカンダリインデックスは基本的にBツリーであり、値は行の対応するプライマリキー値であると理解しています。 さて、一人の人が何千ものペットを持つことができ、私はしばしば人のペットをの順にしたいとしpet_idます。次に、セカンダリインデックスのレコードが並べ替えられている(person_id, pet_id)か、並べ替えられていないためのだけperson_idであるかが重要になります。後で推測。pet_idperson_id では、person_idが一意でない場合、レコードは、(person_id, pet_id)またはJUST によって物理的にソートされていpet_idますか? ありがとう

1
条件付きの一意の識別子フィールド
私は稼働していないデータベースを持っているので、メインテーブルはCustodyDetailsで、このテーブルにはID int IDENTITY(1,1) PRIMARY KEY列があり、他のテーブルで参照されていない別の一意の識別子を追加する方法を探しています。アカウントの内容は、正確にはIDキーではありません。 ただし、この新しいID列にはいくつかの具体的な詳細があり、ここから問題が始まります。フォーマットは次のとおりです。XX/YYどこXXはリセットが/すべての新しい年に再起動することを自動incrementable値であり、YYは現在の年の最後の2桁ですSELECT RIGHT(YEAR(GETDATE()), 2)。 したがって、たとえば、レコードから開始日追加されたふりをすることができます1 28/12/2015終了2016年3月1日には、カラムは次のようになります。 ID ID2 DATE_ADDED 1 1/15 2015-12-28 2 2/15 2015-12-29 3 3/15 2015-12-30 4 4/15 2015-12-31 5 1/16 2016-01-01 6 2/16 2016-01-02 7 3/16 2016-01-03 フロントエンドを使用してコンポジットID(例ではID2)を解析し、最後の2桁を取得して現在の年の最後の2桁と比較し、新しい相関を開始するかどうかを決定することを考えました。もちろん、データベース側でそれをすべて実行できることは素晴らしいことです。 編集1:ところで、私は人々が並列のIDキーを格納するためだけに別々のテーブルを使用しているのを見たので、1つのテーブルのIDキーは2番目のテーブルのセカンダリキーになります、これは少しおかしな話に聞こえますが、おそらくこれはそのような実装が行われるケースですか? 編集2:この追加の IDは、すべてのファイル/レコードにラベルを付けるレガシードキュメント参照です。私はそれをメインIDの特別なエイリアスと考えることができると思います。 このデータベースが毎年処理するレコードの数は、過去20年間で100を超えていません。もちろん、99を超えるとフィールドでできることはほとんどありません(実際には、非常に非常に)。追加の桁で続行すると、フロントエンド/手順は99を超えることができるため、状況が変わることはありません。 もちろん、最初に言及しなかったこれらの詳細の一部は、特定のニーズに合わせてソリューションの可能性を絞り込むだけなので、問題の範囲をより広く保つことを試みました。

1
IDに行を挿入できませんが、行が存在しません
これが私が直面している奇妙な問題です。次のクエリを使用してデータを入力しようとしています insert into product_product (id, product_tmpl_id, make_equip, model_equip, name_template, serial_num_equip, location_equip, issue_date_equip, issue_to_equip, remarks_equip, pr, ch, categ_id,valuation) values (700,700,'Nikon','Action 10x50 Lookout','Nikon Action 10x50 Lookout','671386','40 Wall St.','5/13/2004 12:00:00 AM','','OM''s OFFICE',62,72,502,'manual periodic'); エラーが発生します: ERROR: duplicate key value violates unique constraint "product_product_pkey" DETAIL: Key (id)=(700) already exists. ********** Error ********** ERROR: duplicate key …

2
MySQL-最後の行が削除された場合、自動インクリメントは連続してインクリメントしません
自動インクリメントされた主キーIDを含むテーブルがあります。最後の行(たとえば、最高のID、たとえばid = 6)を削除して新しい行を挿入すると、新しいIDは7から始まります。主キーが6から始まることを変更する必要があるパラメーターはどれですか。 CREATE TABLE animals ( id MEDIUMINT NOT NULL AUTO_INCREMENT, name CHAR(30) NOT NULL, PRIMARY KEY (id) ) ENGINE=MyISAM; INSERT INTO animals (name) VALUES ('dog'),('cat'),('penguin'), ('lax'),('whale'),('ostrich'); 結果: ID名 1犬 2猫 3ペンギン 4亜麻 5クジラ 6ダチョウ DELETE FROM animals WHERE id = 6; INSERT INTO animals (name) VALUES ('x'); 結果: …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.