問題タブ [primary-key-design]

次のエンティティを持つ投票システムをモデル化しています。

• カテゴリー
• 候補者
• 段階

名前が示すように、カテゴリと候補者をそれぞれのテーブルに格納します。投票には 2 つのフェーズがあります。第 1 段階では、各カテゴリに 8 名がノミネートされます。最も投票数の多かった 4 人の候補者が第 2 段階 (および最終段階) に進みます。

これまでのところ、私はこの構造を持っています（簡略化）

私の問題は、投票部分をモデル化する方法です。2つのオプションがあると思いますが、どちらが優れているか、それぞれの長所と短所はわかりません。

オプション 1:複合 3 列の主キーを持つ category_nominee テーブルを持つ (ここでの「正規の」PK はこれら 3 つのフィールドによって形成されていると確信しています。パフォーマンスへの影響についてはわかりません。mysql を使用しています)

これについて私が気に入らないのは、category_nominee に単一の識別子がないため、votes テーブルから category_nominee を参照するには、これらの 3 つの列を再度使用する必要があることです。したがって、投票テーブルでは、3 つの列を繰り返す必要があります。

さらに、category_id が category.id または category_nominee.category_id を指す必要があるかどうかはわかりません (私は後者に傾いています)。

オプション 2: category_nominee に自動インクリメントされた id 列を作成し、category_id、nominee_id、および phase_id を複合一意キーにします。

これにより、category_nominee レコードの参照が簡単になり、繰り返しが回避されます。投票には、category_nominee よりもはるかに多くの記録があると予想しています。それでも、どちらのオプションがより便利かはわかりません。

オプション 1 の SQL Fiddle

オプション 2 の SQL Fiddle

mongo db で複合主キーを処理する最善の方法を決定しようとしています。このシステムでデータを操作するための主なキーは、2 つの uuid で構成されています。uuid の組み合わせは一意であることが保証されていますが、個々の uuid はいずれも一意ではありません。

これを管理するには、いくつかの方法があります。

1. 2 つの値で構成される主キーのオブジェクトを使用します (ここで提案されているように) 。

2. 標準の自動生成された mongo オブジェクト ID を主キーとして使用し、キーを 2 つの個別のフィールドに保存してから、それら 2 つのフィールドに複合インデックスを作成します

3. 主キーを 2 つの uuid のハッシュにする

4. 私が現在気付いていない他の素晴らしい解決策

これらのアプローチのパフォーマンスへの影響は何ですか?

オプション 1 については、キーが連続していないため、挿入のパフォーマンスが心配です。これが従来の RDBMS システムを破壊する可能性があることはわかっており、MongoDB でも同様である可能性があることを示しています。

オプション 2 の場合、システムで使用されることのない主キーを使用するのは少し奇妙に思えます。また、クエリのパフォーマンスがオプション 1 ほど良くないようです。従来の RDBMS では、クラスター化されたインデックスが最良のクエリ結果を提供します。これは MongoDB にどの程度関連していますか?

オプション 3 の場合、これは 1 つの単一の id フィールドを作成しますが、挿入時に連続しません。このアプローチに他の長所/短所はありますか?

選択肢 4 についてですが、選択肢 4 とは何ですか?

また、将来的には MongoDB の代わりに CouchDB を使用する可能性についても議論されています。CouchDB を使用すると、別のソリューションが提案されますか?

詳細情報:この問題の背景については、こちらを参照してください。

私は持っていますstudent table、私は登録時admission idにそれにプレフィックスを追加したいですadmission id

標準テーブル:

14ADは、私がこのように欲しいasdmission idに追加されます

前もって感謝します

主キー (PK) 値がテーブル内で一意である場合:

• タブ文字などの主要な制御文字を防止する (または思いとどまらせる) ことは不可欠 (または推奨)ですか?

バックグラウンド

Selecting the Right Primary Key in Microsoft Access (Blue Moose Technologies、2008)などの記事では、ユーザーが入力する可能性がある主キーの値について警告しています。

とりわけ、Access では、テーブルに null 値を持つ主キーを許可しないことを読みました。

Null 値はさておき: Access 2010 では、主キー内で先頭のタブ文字を使用できるように見えます。

関連している

テーブルの主キーのベスト プラクティスは何ですか?

以前のバージョンの Access の参照ポイント

値ではなく名前付け用:

テーブルの手動作成 – Microsoft Access 2000 のプログラミング (Microsoft プログラミング シリーズ)には、次のように記載されています。

… フィールド名をスペースまたは制御文字 (ASCII 値 0 ～ 31) で始めることはできません。…</p>

Microsoft の Access 2003の用語集には、標準の命名規則に関して次のように記載されています。

… 先頭のスペースや制御文字 (ASCII 値 0 ～ 31) も使用できません。…</p>

現在、テーブルの自然主キーを一意の自動インクリメント ID 列で補足しています。

これにより、コードからのレコードの比較、更新、および削除が容易になります (より単純な WHERE 句)。

これは、ID を主キーとして使用し、Category/DisplayName で一意のキーを使用する場合と比べてどうですか?

あるアプローチを使用する利点はありますか?

割り当てられたドメイン (文字列) ユーザー名ではなく、AI 整数を使用してユーザーを示す方がおそらく良いとここで読みました。ただし、「users」テーブルに自動生成されたユーザー ID と一意のドメイン ユーザー名を含める場合、他のテーブルでそれを FK としてどのように示す必要がありますか? 例えば。「ユーザー ID」と「ドメイン名」またはユーザー ID のみの部門テーブル。所有者として「userid」と「domainname」または単に「userid」を持つハードウェアテーブル?

私のテーブルの 1 つは、order他one to manyの 2 つのテーブルPaymentMethod1およびPaymentMethod2. null を回避できるように、属性がまったく異なるため、個別の「支払い方法」テーブルを作成しました。ただし、order特定の行は、任意の 1 つのテーブルの特定の行にリンクします - PaymentMethod1OR PaymentMethod2。これには、主キーの値がこれらのテーブルの両方で一意である必要があります。つまり、2 つの行が同じ主キーを持つことはできPaymentMethod1ません。PaymentMethod2

PaymentMethod1このように主キーを選択するのは正しいPaymentMethod2ですか？はいの場合、どのように実装しますか?

TCG カードのデータベースがあり、主キーを決定しようとしています。最初は代理キーで解決しましたが、プロモーション カードなど、追加し忘れているカードがあることに気付きました。代理キーは最新の自動インクリメントでデータベースに追加され、挿入された順序に ID を依存させたくなかったため、これは問題です。カードの機能の一部をハッシュして、代わりにそれを主キーとして使用できるのではないかと考えていました。

たとえば、次の擬似コードを見てください。

カードの可能な量は、現在約 25k で推移しており、6 か月ごとに約 100 ～ 300 増加しています。

1. このままじゃ衝突しないよね？
2. これは良い習慣ですか？他に良い代替手段はありますか？

に変換することでハッシュを短くできることはわかっていますが、これらをユーザーのインベントリ テーブルに結合するので、これらを維持することが最善の選択肢になるbase 62と思います。int