お気に入りをテーブルに格納する方法について

質問

不特定多数の料理から、ユーザー毎にお気に入りの料理をマークし、お気に入りのカラムを後で検索させる用途がある場合、MySQLではどのようにテーブルに格納すれば良いでしょうか？

■お気に入りテーブルの格納例

案１）favaliteにSET型を使い１レコードで済ます
PK ユーザーID
favalite (天丼,牛丼,カレーライス)

案２）favaliteにTEXT型を使いカンマ区切りで代入。１レコードで済ます
PK ユーザーID
favalite (天丼,牛丼,カレーライス)

案３）favaliteにTEXT型を使い、お気に入り分レコードを追加（３レコード）流石に重いでしょうか？
PK ユーザーID
favalite 天丼

PK ユーザーID
favalite 牛丼

PK ユーザーID
favalite カレーライス

回答No.2

chukenkenkou · ベストアンサー

情報数が不定＆増える可能性がある場合に、set型は不向きです。
長さが不定の場合を除き、text型を利用するメリットはありません。
案１にしても案２にしても、重複データを多量に持つことになる可能性がある上、情報の二次利用ができません。

案３は、データ量が数千万件～数億件にならないなら、処理の重さをそれ程心配する必要はないと思います。データ型もtextにする必要はなく、varcharでいいのではないでしょうか？

重複データを持たせないと考えるなら、#1回答者さんも言っているように、食事データを別表で管理し、食事コードで対応付ける方法も有効だと思います。

そうすれば、この食事が好物の顧客数、性別、年齢層、などなど、分析が可能になります。

お礼

MySQLならではのご回答までありがとうございます。
varcharの方が効率が良いんですね。
情報の二次利用という所、大変説得力があります。
コードを付けるかどうかは大量にデータを入れてテストしてみようと思います(^^)

回答No.3

yambejp

検索や集計を前提としているのであれば正規化するべき
です。処理が重いという意味ではレコードの数よりも
有効なindexがもてない１レコードでの管理の方が重くなる
可能性が高いです

お礼

MySQLでは、ENUMやSETは全てインデックスを持つ見たいです。ただ、カラムに対して１つの値を持つという方がわかりやすい気がしましたので、SET型を使うのはやめようと思います。

回答No.1

salf

テーブル設計の話と思わさせていただきます。

私の考えは基本的にＤＢは一意にデータ量のみが増えていく設計にするのがよいと思います。

なので、もし私が作るとすれば、

ユーザテーブルでユーザ情報を管理
食べ物テーブルで食べ物情報を管理
好物テーブルでユーザ情報と食べ物情報をくっつける。

という設計を取ります。

案的に私の考えに一番近いのは案３ですね。

お礼

基本的に一意にデータ量のみ増えていく設計。参考になりました。しかし未だSETを使われている方を見た事がないですし、＃２の方も今回は向かないということで、SETを使うのはやめようと思います。
ありがとうございます。