RDBMSの実践的な使い方についての質問です。

例えば会員制のサービスで、ユーザの好物のリスト(任意の文字列のリスト。例['リンゴ','バナナ','ヨールグト'])を会員テーブルのあるカラムに保存するとしたら、どのようにするのが最も望ましいでしょうか。

* RDBMSの配列データ型を使う
* アプリ側で配列をシリアライズして、それをDBに保存
* 複数行テキストとして保存(改行コードで区切る)
* JSONとして保存( "['リンゴ','バナナ','ヨールグト']")
* 1カラムに押し込もうとすることが間違い
などなど。

【前提条件】
* このサービスの利用者数・アクセス数は多くなく、負荷やテーブルサイズを気にしなくてよい(会員レコード数千件程度)
* 好物リストはユーザによる自由記述

回答の条件
  • 1人5回まで
  • 13歳以上
  • 登録:2011/06/04 19:15:33
  • 終了:2011/06/11 02:59:31

ベストアンサー

id:hanako393 No.5

hanako393回答回数1142ベストアンサー獲得回数872011/06/05 22:30:49

ポイント80pt

通常は、1カラムに押し込もうとすることが間違いです。

この質問にはこう答えるしかありません。

ただし状況によって違います。

> RDBMSの配列データ型を使う

> アプリ側で配列をシリアライズして、それをDBに保存

> 複数行テキストとして保存(改行コードで区切る)

> JSONとして保存( "['リンゴ','バナナ','ヨールグト']")

・好物リストをほかどのように今後利用する可能性があるか?

・DB単体での保守性

・プログラムからのアクセスのしやすさ

・性能

このあたりを考慮して選べばよいと思います。

妥当な理由があれば、どれでも問題ないと思います。

質問に挙がっている内容は、どこかのシステムで使われている手法ですから

どれも悪いわけではないです。

個人的には1カラムに入れるのは気持ち悪いですが、今回の場合は何も問題にならないですし、1カラムに入れたほうがわかりやすい可能性もあります。

好物リストは確かにリスト形式ですが、単なる自己紹介と変わらない扱いだと思いますから。

id:DQNEO

・好物リスを今後どう利用するかによって選べばよい。

・1カラムに入れるのは気持ち悪いが、今回の場合は問題にない。1カラムの方がわかりやすい可能性もあります。

・好物リストは確かにリスト形式だが、自己紹介と変わらない

なるほど!

1カラム方式にしようと思っていたので、勇気がわいてきました。

ありがとうございます。

2011/06/06 00:51:26

その他の回答(4件)

id:a-kuma3 No.1

a-kuma3回答回数4462ベストアンサー獲得回数18412011/06/04 19:46:35

ポイント30pt

「1カラムに押し込もうとすることが間違い」のスタンスです。

前提は、往々にして変わるので、よっぽどのことがなければ、素性が良い設計をすべきです。

ということで、「好物DB」を作って、[利用者ID,好物] というテーブルを作る方を推します。

id:DQNEO

正論ですね。

教科書的に間違いな気はするのですが、別に困らないのでいいじゃないかという気もします。

2011/06/05 05:50:18
id:deflation No.2

deflation回答回数1036ベストアンサー獲得回数1262011/06/04 19:53:08

ポイント30pt

正規化の観点から考えると、会員テーブルに入れるのは間違いです。


会員番号でリンクを張って、たとえば以下のような「ユーザーの好物テーブル」を作成するのが定石です。


会員番号好物
001リンゴ
002ヨーグルト
002リンゴ
003バナナ

また、好物の“文字ゆらぎ”を抑制するために(たとえば、リンゴ,りんご,林檎のような文字ゆらぎが発生しないようにするために)、「好物マスター」を用意してコード化(シリアライズ)することも必要かもしれません。

id:DQNEO

正規化の観点からすると間違いはおっしゃるとおりですね。

別に正規化しなくてもいいじゃないかという気もしました。

2011/06/05 05:51:05
id:taknt No.3

きゃづみぃ回答回数13537ベストアンサー獲得回数11982011/06/04 19:59:21

ポイント30pt

私も

>* 1カラムに押し込もうとすることが間違い

だとは 思いますが、使い方によっては そのようなやり方もあります。


●二進数で考える


'リンゴ','バナナ','ヨールグト'を 好物だったら 1 そうでなかったら 0としてあらわします。

たとえば バナナが好物で ほかが 好物でない場合は

010

となります。


このようにしておけば

001 ヨーグルトが好物

010 バナナが好物

011 バナナとヨーグルトが好物

100 リンゴが好物

101 リンゴとヨーグルトが好物

110 リンゴとバナナが好物

111 リンゴとバナナとヨーグルトが好物

で それらを 10進数にすれば 0から7までの値となります。

つまり ひとつの項目に 0から7の値で 何が好物かセットできるのです。

このメリットは データベースの容量を減らせることです。

ま、今回は あまり関係ないと思いますが。

わかりにくい というデメリットもあります。

ただ こういうやり方もありますよ ということで 知っておくと 何かの役に立つ・・・かも?!

id:DQNEO

好物が最大3種類ならそのとおりですね。

2進数保存という発想はなかったので斬新です!

2011/06/05 05:52:48
id:SweetSmile1978 No.4

SweetSmile1978回答回数191ベストアンサー獲得回数292011/06/04 20:13:16

ポイント30pt

たとえば、好物で友達になれそうな登録者を探せるサービスとか

提供するのならほかの方が言うように別テーブルに一つずつ対応づけてのほうが

いいような気もしますが、そういうことをしないのであれば、

わざわざテーブル分ける必要もないかなという気もします。

まぁ、フルテキスト検索とかできるのなら

いずれにしてもテーブル分ける必要はないかもしれません。

そのデータをどう使うかという情報があったほうがいいように思います。

id:DQNEO

「まぁ、フルテキスト検索とかできるのなら

いずれにしてもテーブル分ける必要はないかもしれません。」

ありがとうございます。

用途によっては、テーブル分ける必要ないということですね。

2011/06/05 05:54:16
id:hanako393 No.5

hanako393回答回数1142ベストアンサー獲得回数872011/06/05 22:30:49ここでベストアンサー

ポイント80pt

通常は、1カラムに押し込もうとすることが間違いです。

この質問にはこう答えるしかありません。

ただし状況によって違います。

> RDBMSの配列データ型を使う

> アプリ側で配列をシリアライズして、それをDBに保存

> 複数行テキストとして保存(改行コードで区切る)

> JSONとして保存( "['リンゴ','バナナ','ヨールグト']")

・好物リストをほかどのように今後利用する可能性があるか?

・DB単体での保守性

・プログラムからのアクセスのしやすさ

・性能

このあたりを考慮して選べばよいと思います。

妥当な理由があれば、どれでも問題ないと思います。

質問に挙がっている内容は、どこかのシステムで使われている手法ですから

どれも悪いわけではないです。

個人的には1カラムに入れるのは気持ち悪いですが、今回の場合は何も問題にならないですし、1カラムに入れたほうがわかりやすい可能性もあります。

好物リストは確かにリスト形式ですが、単なる自己紹介と変わらない扱いだと思いますから。

id:DQNEO

・好物リスを今後どう利用するかによって選べばよい。

・1カラムに入れるのは気持ち悪いが、今回の場合は問題にない。1カラムの方がわかりやすい可能性もあります。

・好物リストは確かにリスト形式だが、自己紹介と変わらない

なるほど!

1カラム方式にしようと思っていたので、勇気がわいてきました。

ありがとうございます。

2011/06/06 00:51:26
  • id:a-kuma3
    > 教科書的に間違いな気はするのですが、別に困らない

    ふふっ、これを言っちゃあ、何でもアリになっちゃいますが :-)

    僕が身を置いている世界では、分野にもよりますが、納品してから 5~20年くらい使われるので、
    作った後のことまで考えちゃいます。

    「先のことまで分からない」というのが本当のところなので、
    他の縛りが無ければ、教科書的な方法を選択しておいたほうが、困ることが少ないです。

    ま、その教科書も、時代につれ、変わってくるんですが。
  • id:deflation
    >別に正規化しなくてもいいじゃないかという気もしました。

    正規化しなくていいという考え方を延長すると、そもそも問題のデータはExcelを使えば十分じゃないか、という話になってしまいます。

    RDBMSを使う限り、運用・管理・バージョンアップを見込んで、正規化する作業は避けて通れません。
  • id:taknt
    二進数ですが、intger 4バイトの項目だったら
    1バイト×8ビットで 4×8=32で 32種類区分けできます。
    ま、先頭の1ビットは プラスかマイナスを表すものですけどね。

  • id:taknt
    二進数ですが、intger 4バイトの項目だったら
    1バイト×8ビットで 4×8=32で 32種類区分けできます。
    ま、先頭の1ビットは プラスかマイナスを表すものですけどね。

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

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

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

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