2

私は、ユーザーがパートナーの好みを選択する必要がある出会い系サイトのデータベースを設計しています。これにより、マッチング プロセスが促進されます。基本的に、私が望むのは、ユーザーが各設定に対して単一または複数のオプションを設定できるようにすることです。たとえば、パートナーの所在地は、NY のみ、または NY、Boston、Miami、LA などになります。私が心に抱いているアイデアが物事を行うための好ましい方法であるかどうかを知りたかった.

これが私がやろうと思っていたことです。

Users Table |    User_Options Table    |    Options Table    | Preferences Table
            |                          |                     |           
ID | Name   | ID | User_id | Option_ID | ID | Name | Pref_id | ID | Name 
1. | John   | 1. |  1.     |   1.      | 1. |  NY  |   1     | 1. | Location
            |                          |                     |

このように、それぞれに多くのオプションがあり、各オプションには多くのユーザーがいます。オプション テーブルを設定にリンクして、希望するカテゴリに基づいてユーザーを呼び出すことができるようにしました。user.location私は、ユーザーが選択したすべての場所のオプションを提供してくれることを望んでいました。私の好みのテーブルには、宗教、場所、食事、飲酒習慣などが含まれます。これを行うより良い方法はありますか?

4

2 に答える 2

2

あなたの説明を見て、2つのエンティティ、つまり設定と場所を分割することをお勧めします。設定テーブルに場所を含める場合は、おそらく、この設定が場所であるかどうかを示すフラグ列が必要になります。私は、システムが同じ好み、つまり趣味、宗教を持ち、望ましい地域に住んでいる、同じ好みを持っていない、または特定の地域に住んでいる一致を見つける必要があると想定しています。したがって、スキーマを少し変更することをお勧めします。

ここに画像の説明を入力

次に、別のユーザーが好む特定の場所と、彼が選択した設定との一致について簡単にクエリできます (ユーザーのお気に入りの場所と設定に従って user_id 1 を持つユーザーの一致を探している場合)。

select r.user_id
from
(select uu.user_id from users u
right join user_location ul using (user_id)
right join users uu on uu.location_id = ul.location_id
where u.user_id = 1) r
inner join user_preference up on up.user_id = r.user_id
inner join user_preference up1 on up1.preference_id = up.preference_id and 
       up1.user_id = 1
group by r.user_id;

別の問題: エグザモールで User_Options のようなジャンクション テーブルを使用している場合、人工キーを作成する必要はありません。この場合、複合主キー (user_id と option_id) の方がより正当化されます。(私の例の 2 つのジャンクション テーブル - user_locations と user_preferences を見てください)。

于 2012-12-31T04:46:04.980 に答える
2

私は、まずドメイン駆動設計の観点からこれを見るのが大好きです。これはかなり深いテーマですが、全体として、重要な概念をモデル化し、作成するコードが適切であることを確認する必要があります。これは、オブジェクト指向の方法でこの問題に取り組むことを計画していることを前提としています。

状態と動作を持つオブジェクトの観点からプロジェクトを考えると、(うまくいけば) 変更をより適切に処理できる、より堅牢なコードになるでしょう。

エンティティに関しては、「ユーザー」とその個人属性 (「名前」、「宗教」、「場所」) を定義することから始めます。

次に、「一致」を生成するために使用する予定の各設定を詳しく調べます。おそらく、モデルに追加することを検討したい多くのものが欠けていることに気付くでしょう (つまり、「場所」とは、緯度/経度と半径のセット、または郵便番号のセットです)。

私の感覚では、最初はオプションと設定に関して一般的なものにすると逆効果になると思います。少なくともこれらのうちのいくつかを定義し、共通点を確認して、共通点を親クラスまたはインターフェースにプロモートする必要があります。

データの永続性のために、コード内で責任を分離してください。あなたのエンティティは、自分自身を救う責任を負うべきではありません。選択したデータベース (ドキュメントなど) 構造にエンティティをマップする他のオブジェクトを作成する必要があります。これにより、サイトの機能に直接影響を与えることなく、基盤となる永続レイヤーを変更できます。PHP の例としてはDoctrine ORMがあります。

最後に、単体テストに慣れましょう。実装言語について言及していないので、参考として使用する単体テスト フレームワークのリストを次に示します。

これはあなたの質問に直接答えないことを知っているので、トピックの答えについてもう少し詳しく説明します。

  • データベースを正規化したままにします (パフォーマンスのために非正規化する必要がある場合を除く)。
  • 外部キーを使用して参照整合性を維持する
  • 必要に応じてデータベース構造をリファクタリングする
于 2012-12-31T03:28:22.767 に答える