1

私は自分のブラックリストとお気に入りをphpリストでデザインします。これはユーザーがブラックリストに登録して他の人をお気に入りにすることができます。

+-----+------+------------+
| uid(pk) | name | family |
+-----+------+------------+

複合主キーであるこのような別のテーブル

+-----+------+------------------------+
| uid(pk) | blacklisted_person_id(pk) |
+-----+------+------------------------+

または、主キーと外部キーを含む設計。この場合、ユーザーが自分自身をブラックリストに登録したり、誰かを2回ブラックリストに登録したりできないように設計する方法がわかりません。前もって感謝します

4

2 に答える 2

1

あなたの解決策は良いですが、ユーザーテーブルでPKを呼び出さないことをお勧めします。id次にuid、マッピングブラックリストテーブルでPKをuser_id（userがユーザーテーブルの名前である場合）およびとして参照しますblacklisted_user_id。そうすれば、これらの個々の列がどのテーブルへの外部キーであるかについて曖昧さがなくなります。

これが優れたソリューションである理由は、追加の一意の複合キーを作成しなくても、重複が入力されるのを防ぐためです。

于 2012-11-30T18:16:56.283 に答える
1

タイトルでの用語の使用は紛らわしく、質問の後半で説明しているものとは対応していないと思います。

  1. 常に人工キーを使用し、自然キーの使用を避けるようにしてください。自然キーに影響を与える可能性のあるデータの一部を後で変更する必要があるかどうかをほとんど知ることができないため、これは良い方法です。

| uid(pk) | name | family |

上記のデザインは良いスタートです。

  1. データの一貫性を犠牲にすることなく、データ モデルに対する制限をできるだけ少なくします。

その場合、の複合キーはUID, black_listed_ID少し制限が厳しすぎる可能性があります。その理由は、後で誰が誰をブラックリストに載せたかのログを保持することを決定する可能性があるためです。そうすると、複合キーの設計が壊れます。

ここでは単純な 1 対多の関係を使用して、複数のレコードで 1 人のユーザーの設定を記述します。

たとえば、ブラックリスト、ホワイトリストなどを含むユーザー アクションのデータ モデルは次のようになります。

UID, AFFECTED_USER_ID, ACTION_ID, ACTION_DT

ACTION_ID は、ブラックリスト、ホワイトリスト、グレーリストなどを記述する「ACTION ルックアップテーブル」への FK です。

現在の状況を説明する表を作成することもできますが、その現在の状況は上記のデータから計算または取得することもできます。

于 2012-11-30T18:33:40.900 に答える