Q&A
ご回答ありがとうございます。
1画面に複数選択のチェックボックスを作成する際の
DB設計について質問です。
例えば、10個のチェックボックスがある場合、
設計の仕方は色々あると思いますが、ﾁｪｯｸﾎﾞｯｸｽの項目数を増えることを想定して集計作業をする際、一番良いものを教えてください。
１．テーブルの項目(数値ﾀｲﾌﾟ)を10個持たせる。←よくやっている人がいますが、ﾁｪｯｸﾎﾞｯｸｽが追加されるたび、項目追加しないといけない。
２．テーブルの項目を1つにして文字列10文字にして、'0000000010'みたいな感じで保存する。文字列10文字→文字列11にすれば良いだけ。
３．主テーブルと副テーブルを作って1対10にして副ﾃｰﾌﾞﾙ側にﾁｪｯｸﾎﾞｯｸｽの値を持たせる。→テーブルを連結しなければならないので、SQLが長くなりがち。
４．その他
自分の考えですが、自作関数さえ作ってしまえば、２の方がSQLも複雑にならず、メンテナンスしやすいと思っています。
また、DB設計する際に読んでおいた方が良いサイトとかありましたら、
教えてください。
回答7件
0
自分なら、（システム面などからの制約条件がない状況では）迷わず3を選択します。
1つの列に多数の属性を詰め込むと、何かとハンドリングが面倒になります。例えば、「3番目だけ1のレコード」を選択するとなると、LIKEを使って書くしかないため、インデックスも効かせられません。SQLアンチパターンでも、Jaywalkingとして1番目に挙げられています。
実際、カンマ区切りで1列に入れてしまったものがあるのですが、あとあとのハンドリングに手を焼いています。
投稿2015/05/19 00:37
総合スコア146564
0
ベストアンサー
maisumakun さんと、同様に３です。
１：１０が、副テーブルに、１０行でという事ならば、場合によりけりでは？
縦持ちデータを、横持変換するのが面倒という方もいらっしゃいますが、これも、場合によりけり。
プログラム側でやった方が楽な場合、クエリ側でやった方が楽な場合、諸事情もあるでしょうし。
’
まともなＤＢであれば、View や ストアド で、
＞テーブルを連結しなければならないので、SQLが長くなりがち。
は、解決可能だし。
’
＞あと、主テーブルが10万レコードある場合、単純に副ﾃｰﾌﾞﾙは100万レコードになるわけですよね。
＞それでもこちらの方が良いですか？
正規化が、正しく行われていて、
適切なインデックスが、付与されていて、
適切なクエリが、発行されるのでれば、
１０万件だろうと、１００万件だろうと、違いはありませんし、
その為に、クエリのチューニング含めて、全体のチューニングを行います。
（私の分野では、あえて、正規化しない場合も、あります。
生のデータを、取得したまま保存の必要があったり。
これらは、パフォーマンスが出ない等、無駄を承知で、行います。）
投稿2015/05/19 01:15
総合スコア2030
bit演算の考え方を応用して大量のチェックボックスを管理する
http://blog.asial.co.jp/683
の様な記事もありますし、
仕様、実装で可能であれば、
bit (n)
bit varying (n)
を、検討したり、
適切に、正規化されたテーブルであれば、
複数の構造を用意して、テストしてみる事も、可能な筈です。
（データ構造が違う物を、既存に影響を与えずに用意して、使用出来るのも、
正規化をする意義の一つです。）
’
まずは、Postgres のデータ型と、他移行時の互換性、仕様との兼ね合いでしょうねぇ。
ご回答ありがとうございます。
bit演算、すごいですね。
これはかなり使えそうです。
ありがとうございます。
あと、そういう知識はどういう書籍、WEBなどを読んで得るのですか？
私の場合は、アセンブラから入ってるのでビット演算得意派ｗ
たとえば、
・Ａという製品を作るのには１０点の部品がいる
・在庫に部品があるか？
などビット演算で事足りたので使ってました。
ネット検索は、コツがあります。
各人のコツを公開しても、役に立たないので、自分で見つけてください。
敢て書くなら、検索の仕方、検索とは 辺りから。
サイトの渉猟は、無駄にならない、自分の引出を増やすと、
考えられるかどうか。
サイト閲覧時に気になったサイトを、ローカルに保存して、
ローカル、ＷＥＢ併用で検索したり。このフォルダは、あえて分類していない。
分類する場合は、関連フォルダを別途作ります。
’
どの言語、処理系でも、まずは、一次資料を見つける事。
見付らなければ、出来るだけ一次資料に近いところを探す。
一次資料の誤りを、そのまま転載しているだけのサイトもあったりします。
’
出来れば、ソフトウェアだけでなく、ざっとで良いのでハードウェアロジックと、
その手法も学んでおくと、ソフトウェアに活かせます。
ビット演算、同期回路、非同期回路などは、ロジックの基礎です。
⇒真理値表、状態遷移図、タイムチャート
ご回答ありがとうございます。
参考にします。
0
「ﾁｪｯｸﾎﾞｯｸｽの項目数を増えることを想定して」とのことですが、その頻度によると思います。もしかしたらいつか変更があるかもしれないしないかもしれないという程度だったら、1でいいと思います。
増やす予定が初めからあるのだったら2か3、できれば3。頻度が高ければ必ず3にすべき、低ければ2でもいいという感じだと思います。
1の場合、チェックボックスを増やすたびに、テーブルの定義とプログラムの変更が必要です。
2の場合、チェックボックスを増やすたびに、プログラムの変更が必要です。
3の場合、チェックボックスを増やすたびに、マスタデータの追加が必要です。
また変更頻度が高いと分かっているのなら、ユーザー操作だけで変更できるように、管理画面でチェックボックスの追加や削除を出来るようにしておくことが望ましいでしょうね。
投稿2015/05/21 02:52
総合スコア902
0
私は、完全に3です。
※ 2の'0000000010'と文字型で持つのはやめた方が良いですが……。
ビット派が出てきたので、その違いについて。
ビット派は、抽出時に総スキャンにならざるを得ませんが、データ量も小さく効率的です。
しかし、ある項目で、それまでは、「はい」「いいえ」のチェックボックスだったものが、「はい」「いいえ」「どちらでもない」の3値に変わることはしばしば起こります。
そのときに対応できなくなる。というのがマイナスポイントです。
文字型なら対応でき「データを入れて表示するだけ」を考えればそれでも良いのですが、3項目目がTrueの且つ、4項目目がFalseのデータ件数、傾向が見たい。
などの分析に使うときに苦労します。
トータル的に考えれば3になるわけです。
投稿2015/05/21 02:37
総合スコア295
0
自分も3ですね
チェック項目をマスタ化して
mst_checkテーブル
カラム：checkno、checkmame、hissuflg
チェックNo、チェック項目名、チェックが必須か
user_checkテーブル
カラム名：userid、checkno、check
ユーザid、チェックNo、チェック状態(true、false)
みたいにつくります。
必須フラグは規約に同意とか用です。
投稿2015/05/20 16:02
編集2015/05/20 16:10
退会済みユーザー
総合スコア0
0
項目数が64個以内ですむなら、
普通にint/bigint型カラム1個でbitとして管理しますね。(2番)
MySQLだったらSET型っていうチェックボックスの為にあるんじゃないかっていうくらいの型があるんですが。。。
項目が100とかになるなら3番を選択しますね。
投稿2015/05/20 15:12
編集2015/05/20 15:14
総合スコア843
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2015/05/19 00:55
2015/05/19 01:15
2015/05/19 01:44