質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

Q&A

解決済

4回答

23922閲覧

MySqlで1テーブルの列が多くなりすぎる場合の設計

nuages

総合スコア40

MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

0グッド

1クリップ

投稿2016/05/18 10:51

編集2016/05/18 11:56

MySqlデータベースで店舗情報を管理しようとしています。
店名や住所、電話番号やFAXなどをそれぞれ列として作ろうと思っていたのですが、
どんどん増えて現状50列以上になる見込みです。

(shop_id, key, value) から成るテーブルを作って列数を減らそうかとも思いましたが
Entity-Attribute-Value は駄目だという評判も多くどのようにすればいいのかわかりません。

店名などの重要な情報のみ shops テーブルに格納し、座席数や喫煙可などの余り重要でない列のみ shop_details に分けて join する位しか思いつきませんが、このようなケースではどのようにして設計すればいいのでしょうか?
また、列数の常識的な上限はどのくらいなのでしょうか?


追記

具体的な列を列挙します(49列)

ID
固有番号
グループID
ログインID
パスワード
店名
よみがな
運営会社
運営会社よみがな
担当者名
担当者よみがな
担当者連絡先
メイン画像
サムネイル
営業時間
定休日
予約制か
喫煙可か
席数
席の種類
電話番号
FAX
E-Mail
求人電話番号
求人メールアドレス
郵便番号
県名
住所
建物名
緯度
経度
エリア区分
アクセス方法
ウェブサイト
Twitter
Facebook
Instagram
LINE
紹介文
PR
一言メッセージ
カテゴリID
ジャンルID
会員グレード
備考
登録日
更新日
削除日
公開状態

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答4

0

ベストアンサー

アプリケーションで各情報がどの様に扱われるかによって適切な設計は変わりますが、
設計完了までに情報が固まり、あくまで店舗ごとに情報を扱うようなケースであれば、列数は100でも200でも問題にならないと思います。

また、店舗数がそんなに多くないのであれば、列の追加によるインデックスの貼り直しコストもそんなに大きな問題にはならないので、列数を気にしないという方向はありだと思います。

(shop_id, key, value) から成るテーブルを作って列数を減らそうかとも思いましたが

管理画面から動的に列の変更をしなければならないようなケース以外だとデメリットの方が大きくなると思います。
それならば、項目ごと、出来れば項目の分類ごとにテーブルを用意して、店舗IDをキーにしてjoinするような方法の方がまだいいかなと思いますね。

投稿2016/05/18 11:03

tanat

総合スコア18709

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

nuages

2016/05/19 01:18

今のところ動的に項目が増減する予定はないので key-value ペアを登録する形は避けたほうが良さそうですね。 店舗数は現状1万レコードほどで将来的に2〜3万程度になる可能性はあります。列を分割せずに設計した時、この数字はインデックス再作成に問題が出る規模なのでしょうか?
tanat

2016/05/19 01:42

サーバのスペック次第ではありますが、多分大丈夫なんじゃないかなあと思います。予定よりちょっと厳しいくらいの条件で実際に試してみるのが確実ですね。
guest

0

Entity-Attribute-Valueは確かにアンチパターンとして挙げられているように、テーブルのカラムが少なくなるだけで、データ抽出が難しくなります。
あと程度カラムは増えても仕方ない面もありますが、テーブルを分割すべきときは、1つの店舗に対して複数の値を持つカラムが登場したときには、テーブルを分けましょう。

例えば1つの店舗に対し、複数の電話番号やFAX番号を持つことはありますよね。そういう場合は電話番号テーブルを作成して、店舗を一意に決定するコード値で関連付けする…といった設計になるでしょう。

投稿2016/05/18 11:04

A-pZ

総合スコア12011

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

質問文を見る限り抵触してはいなさそうですが、例えば複数の電話番号を管理するのに「tel1,tel2,tel3」のようにカラムを増やしているなら、これはマルチカラムアトリビュートのアンチパターンになります。
そうでないならば、他の方もおっしゃっていますが50項目程度なら特に問題にならないと思います。

ただ大半の店舗には不要でNullが設定されるカラムばかりが多いなら
全ての店舗に共通して入力必須な項目と、一部の店舗のみに必要な項目はテーブルを分けるのも良いかも知れません。
その際も、その2つのテーブルの項目数が同じ50程度になるように分けるので良いと思います。

投稿2016/05/18 11:56

hirohiro

総合スコア2068

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

hirohiro

2016/05/18 12:01

項目追記と入れ違いの投稿になってしまいました。 ぱっと見た感じ、管理会社関連と担当者関連は、同じ会社や担当者が複数の店舗に登録されるなら、テーブルを分けたほうが良いかも?と思う程度ですね。
guest

0

必要なら作るしかないと思いますが…
項目一覧がわかれば、それを評価してくれる
詳しい方はいるかと。

投稿2016/05/18 10:56

takasima20

総合スコア7458

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

nuages

2016/05/18 11:56

具体的な列の一覧を追記いたしました。 よろしくお願い致します。
takasima20

2016/05/18 12:07

拝見しました。 特にこれといった問題はなさそうな気がします。 データを分けたことにより処理の煩雑さを増すより 1テーブルに収めた方がいい気がしますね~ 気になる点といえば、「ログインID」「パスワード」は いっしょに持つ必要はあるのかなあ、と。 ログイン時しか使わないと思うし、セキュリティの 観点からも別扱いしといた方がいいかも?
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問