SQLについて質問です。

以下の3つのテーブルがあるとします。

users
-------------
id(pk) | name
-------------
1 | bob
2 | mary

user_defined_columns
------------------------
id(pk) | name | enabled
------------------------
1 | Mail | 1
2 | Tel | 1
3 | | 0

column_values
----------------------------------------------------------
id(pk) | user_id(fk) | user_defined_column_id(fk) | value
----------------------------------------------------------
1 | 1 | 1 | bob@example.com
2 | 1 | 2 | 000-111-222
3 | 2 | 1 | mary@example.com


このときにユーザのリストを作成しようと思っています。
しかし、以下のようにuser_defined_columnsに定義された値を
ユーザリストのカラムとして表示したいです。

results
-----------------------------------------------
id(pk) | name | Mail | Tel
-----------------------------------------------
1 | bob | bob@example.com | 000-111-222
2 | mary | mary@example.com |

この場合はどのようなSQLを書くとよいのでしょうか?
このような場合はやはりアプリケーション側で対処すべきでしょうか?

回答の条件
  • 1人2回まで
  • 登録:2007/10/10 09:33:55
  • 終了:2007/10/17 09:35:03

回答(2件)

id:yantsu No.1

やん2回答回数23ベストアンサー獲得回数02007/10/10 10:14:15

ポイント35pt

SQLを工夫してお望みの結果は得られると思いますが、おそらく電話番号を複数持ったりFAX番号を管理したりということも考えているようなDB設計であると見受けられます。

このような項目拡張があった場合でもDBの変更が必要ないような工夫をされたのだと思います。

このようなテーブル構成の場合は、無理してSQL一本で望み通りの結果を得るよりも、column_valuesテーブルとusersとuser_defined_columnsを素直にjoinして得られた結果をアプリケーション側で整形した方が良いと思います。

id:bobchin

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

user_defined_columnsについては、1ユーザは各項目に対して1つしかデータを持たないつもりです。

ただし、user_defined_columnsの項目については後に増えることを想定しています。

また、結果として1つの表にしたいのは、ユーザリストを表示した際にソートをかけたいと考えていますので、1つの表にできればorder by1発なので楽かなとかんがえているためです。

2007/10/10 10:51:49
id:KUROX No.2

KUROX回答回数3542ベストアンサー獲得回数1402007/10/10 10:39:42

ポイント35pt

results

-----------------------------------------------

id(pk) | name | Tyoe |TypeName| value

-----------------------------------------------

1 | bob | 1 |MAIL |bob@example.com

1 | bob | 2 |TEL |000-111-222

2 | mary| 1 |MAIL | mary@example.com

までSQLで、後はプログラム対応。

user_defined_columns

は将来増えることを想定してるのなら、SQLで一気にというのは

なんとなく危険そうな(単に直感)。

実際問題、1はMAIL、2はTELというようにDBの中身の値を

意識してプログラムしなければいけない局面がでてくると思う

ので、ここで、頑張ってもあまり意味がなさそうにも思う。

(これも、単に直感)。

下手にLEFT JOINするより、プログラムループしたほうが

マシそう。(これも、単に直感)

性能とか要求するのなら、

本当は、テーブル見直してほしいような気もします。

ここまで汎用性を持たせる必要はあるのかなとは思います。

id:bobchin

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

もしテーブル設計に問題があれば、設計の見直しもしたいと思っています。

上記にも書きましたが、結果として1つの表にしたいのは、

ユーザリストを表示した際のソート処理が楽になるのではないかと考えているためです。

2007/10/10 10:53:42
  • id:bobchin
    SELECT
    u.*,
    (SELECT
    value
    FROM
    column_values v LEFT JOIN user_defined_columns c
    ON v.user_defined_column_id = c.id
    WHERE
    c.id = 1
    and u.id = v.user_id
    ) as Mail,
    (SELECT
    value
    FROM
    column_values v LEFT JOIN user_defined_columns c
    ON v.user_defined_column_id = c.id
    WHERE
    c.id = 2
    and u.id = v.user_id
    ) as Tel
    FROM
    users u

    このようなものは考えてみましたが、しっくりきていません。
  • id:yantsu
    ソート処理に関して気にされていますが、表形式の表示をするコントロール自体にソート機能(列見出しをクリックするとその列でソートするなど)があることが多いので、特に気にしなくても良いのではないでしょうか

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません