人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

データベースに長けた方にお聞きします。

設問数、回答形式不特定のアンケートを作成しているのですが、データベースの仕様で悩んでいます。
アンケートは設問数が一定でなく (最大 50 程度)、回答形式もそれぞれ択一、複数選択、テキストと固定されていません。
これを賄うのにどういった DB 設計が望ましいのでしょうか。

案 1. 回答形式に応じたテーブル (radio,checkbox,text..) を作成する。1 回答 = 1 レコードで処理。
案 2. アンケートを アンケート種別 -> 個別アンケート といったヒエラルキーで縛り、アンケート種別をフォーマットフリーにしてそれに応じたテーブルを作成する。1 アンケート = 1 レコードで処理。

案 1 の場合、設問数 50 で複数選択が入った場合、最悪 70 近い INSERT 文を発行する事になりパフォーマンスが心配です。
案 2 の場合、カラム数が 100 近くに達する可能性があり、DB 設計的に妥当なのかどうか不安です。

といった状況なのですが、何かご助言いただける事があればお願いいたします。

●質問者: hebe
●カテゴリ:コンピュータ
✍キーワード:DB アンケート カラム テキスト データベース
○ 状態 :終了
└ 回答数 : 8/8件

▽最新の回答へ

1 ● teatime_miki
●0ポイント

http://www.hatena.ne.jp/1096907357#

データベースに長けた方にお聞きします。 設問数、回答形式不特定のアンケートを作成しているのですが、データベースの仕様で悩んでいます。 アンケートは設問数が一定でな.. - 人力検索はてな

私がDB設計するのであれば、

・1回答=1レコードで処理。

・1カラム=1設問で処理。

・すべてテキストで固定。

・択一、複数選択の場合は書式を決めてテキスト形式で保存する。

(例 択一:radio-a 選択:check-a,d,gのような。)

・・・という形にすると思います。

レコードに、radioとかcheckのように決まった言葉があれば、択一や複数選択の設問であるということがわかるようにすれば、択一でも複数選択でもテキスト形式でも保存できるのではないでしょうか?

そうすれば、複雑なテーブル設計をしなくても処理できそうな感じがしますがいかがでしょうか?

◎質問者からの返答

それをやるとデータベースを使う意味が無いと思うのですが、それなら XML に落として集計に musashi かスクリプト作ってやります


2 ● hempire
●60ポイント

http://it-ura.seesaa.net/

IT業界の裏話

アンケートの集計はリアルタイムで行う必要がありますか?DBへのデータ格納が非同期でよいのであれば、送信されたアンケート内容を、「Seq,送信内容」の仮テーブルに格納しておき、あとで個別のテーブルに振り分けてやるというのはどうですか?

サーバ上に時次で実行されるSPを用意しておけば、オンラインパフォーマンスへの影響はほぼありません。

回答頻度や1レコードの長さ、サーバ/クライアントの関係やそのスペックなどの詳しい状況が分からないので抽象的な回答になりましたが、正規化のしすぎによるパフォーマンス劣化が起きないようご注意下さい。

◎質問者からの返答

なるほど、良いヒントを頂きました。ありがとうございます。


3 ● upride
●30ポイント

http://google.co.jp/

Google

設問数や質問の形式が普遍ならば案2でも宜しいと思いますが

質問の改訂があった場合ちょっとひどいことになりそうですね

設問の種類が複数ある場合でもテーブルは統一のほうがメンテしやすいのではないかと思います

この2テーブル案はどうでしょうか

[アンケートテーブル]

アンケートID 、更新年月日、ユーザ名

1、’2004/10/01’、’guest’

[アンケート詳細テーブル]

アンケートID 、設問ID 、問題形式、回答1 、 回答2 、回答3・・・

1、1、’text’、’あああ’、null 、null

1、2、’radio’、’1’、null 、null

・・・・

1、50、’list’、’hoge1’ 、’hoge2’ 、’hoge3’

これだと2000人のアンケートで10万レコードですね

どのDBで構築するかも吟味の必要があるかも。

◎質問者からの返答

むぅ、利用者に対するレコード数を見落としてました。厳しいですね。


4 ● dekodeko
●30ポイント

http://www.hatena.ne.jp/

はてな

文だけで説明するのはかなりつらいので、わかりにくかったらすいません。

案2は絶対にお勧めできません。

案 1の最悪 70 近い INSERT 文ですが、70回程度なら心配されるほどの事はないと思うんですがどうでしょうか。

工夫すれば70回ではなくてテーブル数分のINSERT文ですむはずですし。

案3としてこんなのはどうでしょう。

設問1は択一式で回答が3

設問2は複数選択で回答がred,blue

設問3はテキストで回答が’自由意見’

だとすると回答テーブルを以下のようにします。

回答番号(INT) 設問番号(INT) 回答(VARCHAR)

1 1 3

1 2 red

1 2 blue

1 3 自由意見

.....

あと、何番の設問がどの回答形式で、選択できる値は何と何でって言う情報もデータベースに格納するようにすればかなり柔軟なシステムになると思います。

まあそこまでやる必要があるのかはわかりませんが。

◎質問者からの返答

案 2 をお勧めされない理由を知りたかったです。


5 ● rapanui
●0ポイント

http://www.google.co.jp/

Google

仕様をきちんと理解できていないので、ピンとはずれだったらポイントは極小で結構です。

案1、案2の折衷案が良いように思えます。ほぼ必須の選択肢ものもあるはずなので、それは1テーブルにまとめます(案2)。存在するか分からないものは個別のテーブルに分割します(案1)。

顧客がいろいろなサービスを利用しているが、顧客によって利用しているサービスはまちまち、といういうようなDBを設計する時はこの方法がとられています。


1-5件表示/8件
4.前の5件|次5件6.
関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ