0

私は4つのテーブルを持っています.1つは資格情報(ID、電子メール、パスワードを保持します)で、他の2つはビジネスユーザーとアプリの通常のユーザー用です。ビジネス ユーザー テーブルには、crID (外部キー) の名前、姓、住所などがあります。通常のユーザー テーブルには、crID (外部キー)、名前、姓などがあります。

4 番目は予約テーブルで、bookingID、bookedfrom、bookedfor を保持します (最後の 2 つは資格情報テーブルを指す外部キーです)。

通常のユーザーがサイトに登録すると、予約スロットが閉じられ、予約テーブルに保存されます。名前と姓は通常のユーザー テーブルに保存され、資格情報テーブルには資格情報が保存されます。

ビジネス ユーザー テーブルは、通常のユーザーによって予約が行われたビジネス ユーザーを保持するだけです。

ここにグラフがあります: db image

問題は、通常のユーザーが予約を行うために Web を選択せず​​に電話をかけた場合にどうするかです。ビジネス ユーザーには、「手動で」予約するオプションも与えられます。それをデータベースに統合する方法に問題があります。

私が見ているように、次のことを行う必要があります。

  1. 予約テーブルに予約枠を作成する
  2. 通常のユーザー テーブルに新しい通常のユーザー エントリを作成し、同時にユーザーが登録されているかどうかを示す別の列を作成します。
  3. 資格情報テーブルにエントリを作成しますが、パスワード/電子メールはありません。これは、彼が登録ユーザーではないためです...電話を使用して予約したばかりです。

あなたの意見は何ですか.もしあなたが望むなら、私はいくつかのshow createステートメントを投稿します. 私は自分の主張をしたと思います。

4

1 に答える 1

2

私は個人的に をマージしbusiness users、必要にnormal users応じcredentialsて 1 つのusersテーブルにマージします。

ユーザーのために 2 つの別個のテーブルが必要になるとは思わないので、データ モデルが大幅に簡素化されます。ユーザーがビジネス ユーザーか通常ユーザーかを判断するためのフラグが必要なだけです。

残りの部分については、ユーザーがまだ登録されていないかどうかを判断するには、null パスワードを使用するだけで十分だと思います。

于 2013-08-29T16:22:24.867 に答える