リレーショナルデータベース理論とキー

Question

ブラウザベースのゲーム内でプレーヤーデータを保持するためのスキーマを設計しています。

私は3つの関係を持っています。そのうちの2つには少なくとも2つの候補キーがありますが、3つ目の属性は{playerId、message、date}

です。この関係には1..1：0 ..関係があるため、一意の行は保持されませんつまり、各プレイヤーにはいくつものニュースタプルが存在する可能性があります。とにかくタプルを一意に識別できる必要はなく、属性のどれも実際に候補になることはできません。

私の質問は次のとおりです。リレーショナルモデルの状態が重複するタプルではなく、各リレーションにキーが必要であることを理解しています。上記の私のスキーマは、これらの制約の両方に矛盾しますが、私の目的のために働きます。ユニークなインデックス属性（IDなど）を追加するだけで済みますが、不要なようです。何か不足していますか？

お時間をいただきありがとうございます。

Answer 1

あなたが欠けているものは、複合主キーです。

複合主キーを使用したいdublicateエントリを取得しないように保存する場合は、

しかし、同じプレーヤーが同じ日に同じメッセージを送信すると思います.... この場合、複合主キーと競合します。 プライマリキーとしての仮想一意のIDは安全な方法です。

Answer 2

トリッキーな質問！私は明確な答えはありませんが、あなたは、タプル全体にユニティシティ制約がない場合、問題に遭遇するかもしれないと思います：いくつかのアプリケーションがアモックを実行し、同じタプルを1,000,000倍挿入しようとしているあなたのテーブル...