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

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

4
主キーとしてのMySQL intとvarchar（InnoDB Storage Engine？
私はWebアプリケーション（プロジェクト管理システム）を構築していますが、パフォーマンスに関してはこれについて疑問に思っていました。 課題テーブルがあり、その中には他のさまざまなテーブルにリンクする12の外部キーがあります。そのうち8つは、他のテーブルからタイトルフィールドを取得するために参加する必要があります。これは、Webアプリケーションでレコードが意味をなすようにするためです。これらの結合ごとに1つのフィールド。 今、永続的な理由で自動増分主キーを使用するように言われました（シャーディングがGUIDを使用する必要がある場合を除きます）が、varchar（最大長32）のパフォーマンスを使用するのはどれほど悪いですか？つまり、これらのテーブルのほとんどは、おそらく多くのレコードに含まれないでしょう（それらのほとんどは20未満でなければなりません）。また、タイトルを主キーとして使用すると、95％の時間を結合する必要がないため、SQLの95％でパフォーマンスヒットさえ発生します（私は思う）。私が考えることができる唯一の欠点は、私はより高いディスクスペース使用量を持っているということです（しかし、1日は本当に大したことです）。 列挙の代わりにこのようなものの多くにルックアップテーブルを使用している理由は、これらの値のすべてがアプリケーション自体を介してエンドユーザーによって構成可能である必要があるためです。 多くのレコードを持つことを除いて、テーブルの主キーとしてvarcharを使用することの欠点は何ですか？ 更新-いくつかのテスト それで、私はこのものでいくつかの基本的なテストをすることにしました。私は100000レコードを所有しており、これらは基本クエリです。 ベースVARCHAR FKクエリ SELECT i.id, i.key, i.title, i.reporterUserUsername, i.assignedUserUsername, i.projectTitle, i.ProjectComponentTitle, i.affectedProjectVersionTitle, i.originalFixedProjectVersionTitle, i.fixedProjectVersionTitle, i.durationEstimate, i.storyPoints, i.dueDate, i.issueSecurityLevelId, i.creatorUserUsername, i.createdTimestamp, i.updatedTimestamp, i.issueTypeId, i.issueStatusId FROM ProjectManagement.Issues i ベースINT FKクエリ SELECT i.id, i.key, i.title, ru.username as reporterUserUsername, au.username as assignedUserUsername, p.title as projectTitle, pc.title as ProjectComponentTitle, …
2
PostgreSQLで既存のインデックスを主キーに昇格させる方法
テーブル内で主キーを作成する方法は知っていますが、既存のインデックスを主キーにするにはどうすればよいですか？あるデータベースから別のデータベースに既存のテーブルをコピーしようとしています。テーブルを表示すると、下部のインデックスは次の形式になっています。 "my_index" PRIMARY KEY, btree (column1, column2) 私はインデックスを作成しました： CREATE INDEX my_index ON my_table (column1, column2) しかし、私はそれを主キーにする方法を知りません... 更新：サーバーのバージョンは8.3.3です
1
PostgreSQLの複数の主キー
次の表があります。 CREATE TABLE word( word CHARACTER VARYING NOT NULL, id BIGINT NOT NULL, repeat INTEGER NOT NULL ); ALTER TABLE public.word OWNER TO postgres; ALTER TABLE ONLY word ADD CONSTRAINT "ID_PKEY" PRIMARY KEY (word,id); 次のコマンドを使用して復元しようとすると： psql -U postgres -h localhost -d word -f word.sql それは私にこのエラーを与えます： テーブル「単語」の複数の主キーは許可されていません postgresで複数の主キーを使用するにはどうすればよいですか？
4
5つ以上の列の主キーは、大きなテーブル（1億以上）に適していますか？
私は実際のDBの問題について読んでいましたが、1つのプロジェクトには1億行とテーブルがあり、5列がプライマリでした。私はこれが悪いと思っていますが、誰もが正確にその理由を教えてもらえますか？ テーブルは一種のマイクロロールアップ/集計テーブルであったため、5つの列は（day、market_id、product_id ...）のようでした。最初は、5列の主キーは理想的ではないと考えていましたが、考えれば考えるほど、それが悪い理由を考え出すことはできませんでした。 これは深夜の議論で、半数の会社エンジニアが参加しました。誰かがこれは悪い設計だと言った、あるシニアエンジニアは同意したが、誰もその理由について実際に飛び込んだことはなかった。したがって、自分で問題を調査しようとしています！
2
外部キーとしての複合主キーの効率
重複がテーブルに入力されないようにするために使用される複合主キー（4列で構成される）を持つテーブルがあります。このテーブルのキーを外部キーとして参照する必要がある新しいテーブルが必要になりました。 私の質問は、どのアプローチがルックアップ速度にとってより効率的かです： 1）4列すべてを含む新しいテーブルを作成し、それらをすべて外部キーで参照しますか。 または 2）主キーテーブルに新しいID列を作成し、これを新しいテーブルの外部キーとして使用しますか。 このデータベースは非常に大量のデータを保持することが期待されているため、各テーブルに保持されるデータ量を最小限に抑えることを目的として、これまで構築してきました。これを念頭に置いて、すべての行に2つのint列とdatetime列を保存するため、オプション2が最適なアプローチになりますが、不要な場合はルックアップ時間の増加を避けたいと思います。
1
CREATE TABLE…AS SELECTの主キーの自動インクリメント
を介して複雑な選択クエリを使用してテーブルを作成しましたCREATE TABLE ... AS SELECT...。このクエリに自動インクリメントの主キーを追加するにはどうすればよいですか？ 例えば： create table `user_mv` select `user`.`firstname` as `firstname`, `user`.`lastname` as `lastname`, `user`.`lang` as `lang`, `user`.`name` as `user_name`, `group`.`name` as `group_name` from `user` inner join `user_groups` on (`user`.`user_id`=`user_groups`.`user_id`) left join `group` on (`group`.`group_id`=`user_groups`.`group_id`) where `user`.`lang`=`group`.`lang` このクエリは、含まれているテーブルを作成しfirstname、lastname、lang、username、group_nameコラム。id自動インクリメントの主キーである列も必要です。 このクエリを変更してこれを行う方法はありますか？このクエリを実行した後にテーブルを変更することでそれができることはわかっていますが、create tableステートメントで直接これを行う方法がある場合は、その方法を知りたいです。
2
auto_incrementキーはINSERTでどのように処理されますか（SELECT * FROM…）
私が持っているtable1とtable2MySQLのインチ どちらにも主auto_incrementキーがありますid。 テーブルスキーマが一致していINSERT INTO table1 (SELECT * FROM table2)て、に挿入された新しい行に関してどうなりtable1ますか？id行の値table1が同じである場合、古い値を保持して競合を生成しidますか？auto_incrementによって新しい値が生成されますか？ストレージエンジンまたはロックに依存しますか？
3
ログテーブルはidフィールドまたは主キーを取得する必要がありますか？
特定のファイルが別のシステムにエクスポートされた日時スタンプを記録するログテーブルがあります。 現在、exportedLogテーブルには3つのフィールドがあります。 id (primary key) messageId (int) exportedDateTime (datetime) これを確認すると、idこのテーブルへの結合がないため、フィールドは何の役にも立たないことがわかりました。このテーブルで機能するのは、メッセージを処理してこのログテーブルに挿入するバッチジョブの挿入だけです。 idフィールドを削除する必要がありますか？ どちらかmessageId、exportedDateTimeまたは両方に主キーが必要ですか？
1
MySQLの複合主キーのINDEXはどうですか？
2つ以上の列の複合主キーを作成する場合PRIMARY KEY(col1, col2, col3)。システムはINDEX各列を個別に使用しますか？ 私はこの質問をしていた理由は、私たちが使用している場合ということですUNIQUE INDEX (col1, col2, col3)、それはとして機能するINDEXだけで、最初の列のために、私たちは、追加作成する必要がありINDEX、他の列に対して複数可。それが複合主キーにも当てはまるかどうかを知りたいです。
3
メールアドレスは一意ですか、それとも主キーですか？
私はデータベースの初心者です。文字列の比較が遅く、複雑な結合のパフォーマンスに影響するため、メールアドレスを主キーとして使用することはおそらく良いアイデアではないことがわかりました。メールを変更すると、すべての外部キーを変更する必要があり、多くのことを必要とします。努力の。 しかし、私のユーザーテーブルですべてのユーザーがメールアドレスを持っている必要があり、それらのメールアドレスはそれぞれ一意である必要がある場合、メール列に一意のインデックスを追加するだけで十分ですか？Afaikの一意のフィールドではnull値が許可されているため、私はすべてのユーザーがnull値を許可せずに電子メールアドレスを持っている必要があります。ここで見逃しているものはありますか？または、電子メール列を一意にし、サーバーでのデータ検証中に、ユーザーが電子メールアドレスを入力してすべてのユーザーが1つ持つことを確認するとしますか？
4
PRIMARY KEYまたはUNIQUE列としてのNVARCHAR列
SQL Server 2012データベースを開発していますが、主キーとしてのnvarchar列に疑問があります。 私はこのテーブルを持っています： CREATE TABLE [dbo].[CODES] ( [ID_CODE] [bigint] IDENTITY(1,1) NOT NULL, [CODE_LEVEL] [tinyint] NOT NULL, [CODE] [nvarchar](20) NOT NULL, [FLAG] [tinyint] NOT NULL, [IS_TRANSMITTED] [bit] NOT NULL DEFAULT 0, CONSTRAINT [PK_CODES] PRIMARY KEY CLUSTERED ( [CODE_LEVEL] ASC, [CODE] ASC ) ) しかし、今私は[CODE]列を主キーとして使用し、列を削除したいと思い[ID_CODE]ます。 NVARCHARとして列がある場合、問題やペナルティはありますPRIMARY KEYか？ [CODE]列の値は一意でなければならないので、UNIQUEその列に制約を設定できると思っていました。 [CODE]主キーとして使用する必要がありますか、それとも列にUNIQUE制約を設定した方が良い[CODE]ですか？
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か？
3
明示的な主キーがないDB内のすべてのテーブルを見つけるにはどうすればよいですか？
Googleの検索により、クラスター化インデックスなしでテーブルを検索する方法に関する数百万のヒットが発生しました。PKは通常、テーブルのクラスター化インデックスです。ただし、テーブルには、クラスター化インデックスとしての自然キー、およびID列のような非クラスター化代理インデックスを簡単に含めることができます。 主キーが定義されていないDB内のすべてのテーブルを見つけるにはどうすればよいですか？このDBには245のテーブルがあります。手動での検査は非常に非効率的です。
4
広範なPKを使用する場合と、個別の合成キーおよびUQを使用する場合のパフォーマンスに関する考慮事項は何ですか？
レコードがいくつかの広範なビジネス分野で一意に識別できるいくつかのテーブルがあります。過去に、これらのフィールドをPKとして使用しましたが、これらの利点を考慮しています。 シンプルさ。無関係なフィールドはなく、インデックスは1つだけです クラスタリングにより、高速マージ結合と範囲ベースのフィルターが可能になります ただし、合成IDENTITY INTPK を作成し、代わりに別のUNIQUE制約を使用してビジネスキーを強制するケースについて聞いたことがあります。利点は、PKが狭いため、セカンダリインデックスがはるかに小さくなることです。 テーブルにPK以外のインデックスがない場合、2番目のアプローチを採用する理由はありませんが、大きなテーブルでは、インデックスが将来必要になる可能性があると想定して、狭い合成PKを採用することをお勧めします。 。考慮事項が不足していますか？ ちなみに、私はデータウェアハウスで合成キーを使用することに反対しているのではなく、単一の広いPKを使用する場合と、狭いPKと広いUKを使用する場合にのみ関心があります。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.