激凹みから立ち直る方法

こんにちは、SELECT文での絞り込みでうまく行かないので質問させてください。

現在、以下の2つのテーブルがあります。
これらのテーブルからメールアドレスを取得したいと考えています。

1.MST_USER
<KEY-->
USER_ID MAILADDRESS
-------+-----------------
1|hoge1@example.com
2|hoge2@example.com
3|hoge3@example.com

2.MST_USER_SETTING
<KEY------------>
USER_ID SELECT_ID OPTION_ID
-------+---------+---------
1|BUNRUI |KYOUSHI // 教師
1|GAKUNEN |2 // 2年生
2|BUNRUI |HOGOSYA // 保護者
2|GAKUNEN |2 // 2年生
3|BUNRUI |GAKUSEI // 学生
3|GAKUNEN |2 // 2年生

やりたい事は、
MST_USER_SETTINNGから2年生の教師のUSER_IDを取得して
MST_USERのMAILADDRESSを取得したいという事です。

一応、以下のようにやってみたのですが、
SELECT "MST_USER"."MAILADDRESS"
FROM "MST_USER"
LEFT JOIN "MST_USER_SETTING" ON "MST_USER_SETTING"."USER_ID" = "MST_USER"."USER_ID"
WHERE
("MST_USER_SETTING"."SELECT_ID" = "BUNRUI" AND "MST_USER_SETTING"."OPTION_ID" = "KYOUSHI") AND
("MST_USER_SETTING"."SELECT_ID" = "GAKUNEN" AND "MST_USER_SETTING"."OPTION_ID" = "2")
)
WHERE句の指定が悪いせいか、正しく取得できませんでした。

以上、よろしくお願い致します。

A 回答 (4件)

再度登場です^^;



それでしたら「SELECT_ID」フィールドに教師、保護者、学生などを、「OPTION_ID」に学年を定義すれば良いのでは?

この回答への補足

ww-_-wwさま。
ご回答ありがとうございます。

>それでしたら「SELECT_ID」フィールドに教師、保護者、学生などを、「OPTION_ID」に学年を定義すれば良いのでは?

申し訳ございません、私の読解力がないせいかもしれませんが、そのようにすると、汎用性が無くなるのではないか?と思います。
(多分、SELECT_ID=教師、OPTION_ID=2 と言うふうに・・・と言うアドバイスだと思いながら、書いています。)

仲間に相談したところ、今回のSQL文では
SELECT
A.USER_ID,
A.MAILADDRESS
FROM
MST_USER A,
(SELECT
*
FROM
MST_USER_SETTING
WHERE
SELECT_ID = 'BUNRUI' AND OPTION_ID = 'KYOUSHI'
) B,
(SELECT
*
FROM
MST_USER_SETTING
WHERE
SELECT_ID = 'GAKUNEN' AND OPTION_ID = '2'
) C
WHERE
A.USER_ID = B.USER_ID AND
B.USER_ID = C.USER_ID

と言うように記述し、JOINする部分はSELECT_ID単位にコードで吐かせるようにすれば?
とアドバイスを受けました。

確かにSELECT_IDに設定される内容が可変なので、これならうまく行く、と考えています。

そもそも、やりたい事は単純だけど無理がある、もしかしてテーブル設計ミス?とも考えていますが、やはり、これ以外に思いつかないのが現状です。

補足日時:2008/03/25 13:52
    • good
    • 0

再三すいません。



「汎用性」というのがどこまでのものなのか把握でききれずに回答していました。
「汎用性」という意味はかなり抽象的ですから。

先ほど記載されたSQL文であれば確かにご希望の値が取得できるかと思います。
こちらこそ、まともなアドバイスが出来ていないようで申し訳ありませんでした。
    • good
    • 0
この回答へのお礼

ww-_-wwさま

ご回答ありがとうございます。

>「汎用性」という意味はかなり抽象的ですから。

ご指摘の件、申し訳ないと思います。
また、おっしゃる通りだとも思います。

まともなアドバイスが出来なかったとの事ですが、そのような事はありません。
テーブル設計について再考できましたし、貴重なアドバイスだったと感謝しています。

今後ともよろしくお願い致します。

お礼日時:2008/03/25 14:26

こんにちわ。



テーブル2としては以下のように持てばいいのでは?

USER_ID  GAKUNEN   MEMBER
--------+------------+-------
1     │1        │KYOUSHI
2     │1        │HOGOSHA
3     │1        │GAKUSEI
4     │2        │KYOUSHI
5     │2        │HOGOSHA
6     │2        │GAKUSEI

仕様をすべて把握していないので、この程度でしかいえなくて申し訳ない。

この回答への補足

ww-_-wwさま。
ご回答ありがとうございます。

申し訳けございません、テーブル2なのですがフィールドを固定にする事は出来ないのです。

テーブルは自由に定義できますが、飽くまでも汎用性を持たせなければならないのです。

ちなみに何をやっているかというと・・・

1.管理者が管理する項目を決める(SELECT_ID)
2.利用者が自分に当てはまる内容を設定する(OPTION_ID)
3.管理者は条件(SELECT_ID/OPTION_ID)を指定して該当する利用者を抽出する

上のような事です。

管理する項目としては
1.学校を想定した場合
 学年、分類(学生/保護者/教師)、etc...
2.飲食店を想定した場合
 性別、誕生月、etc...
と言うように、可変なのです。

補足日時:2008/03/25 12:47
    • good
    • 0

こんにちわ。



個人的には2のテーブル設計を見直したほうが良いかと思います。
あまりにも設計が悪く見えます。

この回答への補足

ww-_-wwさま。
ご回答ありがとうございます。

>個人的には2のテーブル設計を見直したほうが良いかと思います。
>あまりにも設計が悪く見えます。

確かにおっしゃる通りだと思います。

でも、これ以上のことが他に思いつかなかったのです。

2のテーブル設計、どうすれば良いのか・・・?
正直、悩んでいます。

要件は、「ユーザの付帯情報を可変に出来る事」だったので、
このようにしたのですが、、、

この件を含め、良い案があれば、何卒よろしくお願い致します。

補足日時:2008/03/25 11:13
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

関連するカテゴリからQ&Aを探す