4

私はデータベース設計に非常に慣れていませんが、データに非常に複雑な関係があるクライアントからかなりの注文を受けました。私がやろうとしているのは、顧客の状態に基づいて製品を推奨するためのロジックを書くことです。ただし、データの他のさまざまなビットの値に応じて適用する必要がある興味深いフィルターがいくつかあります。たとえば、一部の製品は {men|women} のみを対象としているため、say の値によってはcustomers.customer_genderその製品が推奨されない場合があります。

もちろん、これをすべて PHP で行うこともできますが、それをデータベースで表現し、それらをデータベースへのフォーム インターフェイスにするだけでよいでしょう。そうすれば、コードをカスタマイズするために私を再雇用することなく、新しい製品を追加するときにこれらの関係をカスタマイズおよび変更できます。私の問題は、経験不足です。この情報を表でどのように表す必要があるのか​​ はっきりわかりません。

EDIT 1 -- 例を試す

次のテーブルがあるとします。

お客様

id   name      gender
--   ----      ------
 1   Bob       male
 2   Mary      female
 3   Steve     male

調子

id    name
--    ----
 1    Headaches
 2    Allergies
 3    Low Energy

製品

id    name              description
--    ----              -----------
 1    Product A         anti-allergy
 2    Product B         energy booster
 3    Product C         pain reliever

また、外部キーを使用して、これらの間の関係を定義するいくつかの追加のテーブルがあります。たとえば、どの製品がどの条件に対して推奨されるか (製品 ID と条件 ID を接続する 2 列のテーブル)、どの顧客がどの条件を持っているかなどです。

今は例えば男性にしかオススメできない商品もあります。または、カフェインに敏感でない人にのみ。または、特定の重大度の特定の状態にある人 (重大度は、1 ～ 3 の int 値を含む顧客と状態をリンクする表の追加の列です)。純粋なデータベース テーブルでこれらの種類の関係 (「式 Z を除く条件 Y に対して製品 X を推奨する」) を表現するにはどうすればよいですか?

4

3 に答える 3

1

この問題は、次のようなモデルで解決できます。

ERD

デザインの問題を解決するのに役立つ2つの重要な要素があります。

  1. 製品が適用される場合と適用されない場合のルールを示す表を用意します。

  2. CONDITIONプロまたはコンルールのいずれかに関与する可能性のある状況を表に含めます。

例：バイアグラは、「子宮がある」状態の患者には禁忌です。

CONDITION_SEVERITY患者がその状態にあることと、それがどれほど悪いかを言うために使用する必要のあるあらゆる種類のスケールでスコアを記録することもできることを意味します。INDICATIONSおよびの表で同様の重大度スコアを使用して、条件が少なくともこれCONTRAINDICATIONSほど悪い場合にのみ製品が適用されるか、条件がこれほど悪いか悪い場合は使用すべきではないと言うことができます。

于 2012-06-24T12:43:18.073 に答える
0

あなたのタイトルへの答えは明確なイエスです。これは決して必要ではありません。条件の拡張可能なリストを作成する場合は、これを静的テーブル構造で定義できます。このようなことを考えてみてください。

  1. Customers テーブル: ID、名前など

  2. Products テーブル: id、product_name など

  3. 属性テーブル: ID、年齢、性別など

  4. 属性値テーブル: id、attribute_id (属性への外部キー リンク)、値

  5. 顧客属性テーブル: id、customer_id (顧客への外部キー)、attribute_id (属性への外部キー)

  6. 推奨テーブル: id、attribute_id (属性への外部キー)、attribute_value_id (属性値への外部キー)、product_id (製品への外部キー)

ここで #6 はレコメンデーション エンジンのコアであり、特定の属性を特定の製品にリンクします。

これは単なる例ですが、私のポイントは、完全に拡張可能なクリーンで静的なデータベース構造を作成できるということです。動的なテーブル名や列名のような狂気に頼る必要はありません。

于 2012-06-23T05:25:44.747 に答える
0

次の設計を検討してください。

テーブル

  • ユーザー (UserID PK)
  • 薬（MedicationID PK）
  • 症状 (SymptomID PK)
  • 重大度 (SeverityID PK)
  • 治療 (TreatmentID PK)

サンプルデータ

ユーザー

UserID    Username          
1         john.smith   
2         jane.doe
3         bob.jones

投薬

MedicationID    Name
1               Tylenol
2               Excedrin
3               Morphine
4               Midol
5               Tums
6               Pepto
7               Anzemet

症状

SymptomID   Name          
1           Headache        
2           Cramps   
3           Vomiting       
4           Dizziness

重大度

SeverityID   Name 
1            Feels bad
2            Feels really bad
3            I want to die

トリートメント

TreatmentID  SymptomID    SeverityID   MedicationID
1            1            1            1
2            1            2            2
3            1            3            3
4            2            1            1
5            2            2            4
6            2            3            2
7            3            1            5
8            3            2            6
9            3            3            7

上記のデータを使用すると、深刻度Userが の頭痛 ( ) があると言うことができます。それは薬を示唆するでしょう。SymptomID of 12Excedrin

治療テーブルは、症状と重症度に基づいて投薬を提案できます。

SELECT m.Name AS MedicationName
      ,sy.Name AS SymptomName
      ,sev.Description AS SeverityDescription
FROM Treatments AS t
INNER JOIN Medication AS m
  ON t.MedicationID = m.MedicationID
INNER JOIN Symptoms AS sy
  ON t.SymptomID = sy.SymptomID
INNER JOIN Severity AS sev 
 ON t.SeverityID AS sev.SeverityID
于 2012-06-23T05:26:04.943 に答える