2

従業員テーブルの主キーは何ですか?

Table Stores
(PK) StoreID
{other store columns}

Table Employee
StoreID
EmployeeID
{other employee columns...}

[編集] 従業員は常に 1 つの店舗にのみ所属するように設定されています。すべての従業員は一意の ID を持つ必要があります (つまり、従業員が異なる店舗に所属していても、同じ ID を持つことはありません)。

PK は常に一意である必要があるため、EmployeeID のみにする必要があると思います。私の同僚は、PK は StoreID+EmployeeID と組み合わせるべきだと考えていますが、(理論的には) 従業員 ID が重複する可能性があります。私は彼の推論に完全に従うわけではありませんが、彼が引用したことの 1 つはパフォーマンスです。私たちのデータベースでは Employee テーブルが 5000 レコードを超えたことがないので、クエリのパフォーマンスについてはあまり心配していません。StoreID を参照する他の大きな子テーブルがありますが、これはそのようなキーを作成する正当な理由ですか?

[編集] EmployeeID のみに一意性を強制する内部キーも作成した場合、複合 PK は問題ありませんか? これを行うには複数の方法があるかもしれませんが、最も受け入れられている方法を選びたいと思います。

4

2 に答える 2

1

PKは常に一意である必要があるため、PKはEmployeeIDのみである必要があると思います。私の同僚は、PKをStoreID + EmployeeIDと組み合わせる必要があると考えていますが、そうすると、（理論的には）重複する従業員IDを持つ可能性があります。

あなたは2つのわずかに異なることについて話している。

従業員のみを識別したい場合は、主キーはおそらくemployee_idである必要があり、ストアのID番号はそのテーブルにまったく含まれていてはなりません。ただし、さらに、従業員が通常どの店舗で働いているかを知りたい場合は、store_idをemployeesテーブルに含める（そして作成するNOT NULL）か、別のテーブルを作成することができます。

私がこのようなことをしてきた25年以上の間、従業員は1つの店舗でしか働けないと言われることがよくあります。それはほとんどの場合真実ではなく、マネージャーがそれが真実であると誓っている瞬間でさえもしばしばです。ある時、私たちは、全員が複数の店舗で働いていた6人の従業員がいる部屋でこれについて「話し合っていました」。そのうちの1人は毎週5つの異なる店で働いていました。そして、すべてのマネージャーはこれを知っていました。複数の店舗で働いているすべての人を指摘したところ、マネージャーは、全員が1つの店舗でしか働いていないと主張していました。（肩をすくめる）

別のテーブルを使用して、従業員の現在の有給の勤務地を保存することを好みます。主な理由は、経営陣は、その裸の事実だけでなく、その関係についてのより多くの情報を常に望んでいるということです。いつも。出席、計時、常に何か他のもの。

そのテーブルでは、少なくとも{store_id、employee_id}の複合主キーが必要です。その場所の関係について保存する他の情報によっては、それよりも多くの列（場合によってはより多くのテーブル）が必要になる場合があります。また、すべての従業員が少なくとも1つの現在の有料の勤務地を持っていることを確認するために、何らかの管理手順（自動化できる場合とできない場合があります）が必要になります。（dbmsがアサーションをサポートしている場合は、管理手順を取り除くことができます。）

于 2012-06-14T17:41:03.127 に答える
1

EmployeeID がすべての店舗で一意である場合、それがそのテーブルの主キーである必要があります。あなたが言ったように、そうしないと、従業員IDが重複します。StoreID + EmployeeID を持つ唯一の理由は、各店舗に独自の従業員番号がある場合です。ある人が 2 つの異なる店舗で働いている場合、店舗ごとに 1 つずつ、合計 2 つの EmployeeID が必要になります。ご質問のとおりですが、そうではないと思います。

ただし、StoreID は、従業員に常に StoreID が割り当てられることを前提として、外部キー関係を使用して設定する必要があります。

また、同僚が主にパフォーマンスに関心がある場合は、テーブルに EmployeeID、StoreID インデックスを追加できます。これにより、遅いクエリが発生した場合に解消されます。テーブルが小さいとおっしゃっていたので、インデックスを追加する前にパフォーマンスの問題が発生するまで待ちます。主キーは常に論理的な組織の決定であると思います。パフォーマンスはその決定の一部とは見なしません。

于 2012-06-14T17:54:26.520 に答える