0

DB 設計者への質問:

パーティーのゲスト リストには、ホスト (パーティーを企画して参加する人) とゲスト (パーティーに参加するだけの人) があります。

ゲストには次の 2 種類があります。

  1. 招待状をお持ちのお客様：自宅で招待状を物理的に受け取った方、および

  2. 招待状をお持ちでない方：招待状をお持ちのお客様の同伴が必要な方。

招待状をドロップする場所を知る必要があるため、最初のタイプのゲストのアドレスを登録する必要があることは理解されています。また、ゲストごとに、招待者のホストまたはゲスト ID を知る必要があります。

問題は
、いくつのテーブルを作成する必要があるかということです。
聴衆全員が参加する単一の 1 つですか？
2 つのテーブル: 1 つはホスト用、もう 1 つはゲスト用ですか?
3 つのテーブル: 1 つはホスト用、もう 1 つは招待状を持ったゲスト用、もう 1 つは招待状を持っていないゲスト用?

3 番目のソリューション (3 つのテーブル) に見られる利点は、招待状のないゲストの「住所」フィールドを空白のままにしておくことを避け、ゲストの ID を招待状で登録できることです。彼ら。

皆様からのご意見・ご感想をお読みいただければ幸いです。

4

3 に答える 3

0

問題には常に複数の解決策があります (ほとんどの場合、解決策はあります)。したがって、1 つ、2 つ、または 3 つのテーブルを使用して、さまざまな方法でこれを行うことができます。それらすべてを 1 つのテーブルに配置して、ホスト、招待されたゲスト、招待されたゲストのフラグを設定し、招待された人の ID (ホストまたは招待されたゲスト) を指す「招待者」フィールドを設定できます。の）。ホスト用とゲスト用の 2 つのテーブルを使用できます。このようにして、「招待された」ゲストを招待されたゲストに紹介し、すべてのゲストを対応するホストに紹介できます。また、連れてきたゲストの住所を取得することもできますが、これは決して悪い考えではありません。hosts、guests、guests2hosts の 3 つのテーブルを使用できます。上記と同じですが、ホストとゲスト間の多対多の関係 (guests2hosts テーブル内)、これにより、複数のパーティーに招待されたゲストを持つことができます。さらに考えてみると、さらに多くの DB レイアウトが考えられると思います。DB の作成は、現在のニーズと将来のニーズの可能性について、非常に慎重に検討する必要があります。現在、多くのシステムはうまく機能していますが、データベース設計が粗悪なため、拡張することはできません。

于 2013-04-29T06:21:34.537 に答える
0

少なくとも5つのテーブル。

Host
----
Host ID
Host Name
...

Invited Guest
-------------
Invited Guest ID
Invited Guest Name
Invited Guest Address
...

Guest
-----
Guest ID
Guest Name
...

Party
-----
Party ID
Host ID
Party Time stamp
Party Address
...

Party Guest
-----------
Party Guest ID
Party ID
Invited Guest ID
Guest ID
...

テーブルのプライマリ (クラスタリング) キーは常に自動インクリメント整数または long として定義します。

外部キーは名前から明らかなはずです。Party Guest テーブルのゲスト ID 外部キーは、null 許容の外部キーです。招待されたゲストはゲストを招待できますが、必須ではありません。

上記の 5 つのテーブルの重複を最小限に抑えるには、さらに 2 つのテーブルを使用します。

Name
----
Name ID
Name

Address
-------
Address ID
Address

あるパーティのゲストは別のパーティのホストになる可能性が高いため、これらのテーブルはデータの重複を最小限に抑えます。

すべての名前列を名前 ID に置き換え、すべての住所列を住所 ID に置き換えるだけです。

于 2013-04-29T09:53:50.290 に答える