参照頻度の低いカラムは、テーブルを別にすべきか？

Question

「table_api」テーブルに、念のためといった感じで「responce」カラムを設けました。

APIから取得して「title」を入れ、他の「content」や「date」は現状使いませんが、もし今後必要となったとき「responce」があればAPIを投げずにその必要な項目を探せるためです。

「table_api」

ID	title	responce
1	家政婦は見た	{{"title":"家政婦は見た"},{content:"花子さんがすごいものを見ました","date":"06-06"}}
2	火曜サプライズ	{{"title":"火曜サプライズ"},{content:"火曜日はとても驚きました","date":"06-07"}}

しかしこの「responce」が数万文字のjsonであったりするので、質問がございます。

この「responce」のような参照頻度の低いカラムは、以下「table_api」と「table_responce」のように分けた方がいいでしょうか？

「table_api」

ID	title
1	家政婦は見た
2	火曜サプライズ

「table_responce」

api_ID	responce
1	{{"title":"家政婦は見た"},{content:"花子さんがすごいものを見ました","date":"06-06"}}
2	{{"title":"火曜サプライズ"},{content:"火曜日はとても驚きました","date":"06-07"}}

もしこのように分けた方がいいとしたら、その理由はなんでしょうか？（例えば数万文字のデータがあるカラムがレコードにあると、SELECTの際に遅くなったりするのでしょうか？）

Answer 1

画像をRDBに保存するかどうかと同等で、内容を検索しないなら
ファイルなどに落としておくと効率的です。
見た感じjsonデータにさえなっていないので検索性は最悪でしょうし・・・

Comments

[antonio]

ありがとうございます。ファイルに落とすのもいいですね。

Answer 2

DBの種類が書いていないので一般論としての回答になります。
あと、responce(responseじゃないの？）に数万文字入るとのことで、固定長char型ではなくclobなどの参照テキスト型という前提で回答します。

そのresponseを使用もしないのにselectするなら（主にトラフィックの問題で）パフォーマンスに影響が出ますが、そうでないなら現状のテーブルに残しても分割しても大した変化はないでしょう。テーブルファイル本体にはテキストの実体はおらず参照しかもっていないのでresponseそのものをselectしない限りシークに影響はないでしょう。

ただ、数十KBに及ぶテキストデータが毎回投入されるとDBストレージに多大な影響がでると考えられます
（1万件投入したらテキストだけでGB単位だ）。
使用頻度によりけりですが、少なくとも今は使わないし、履歴のようなデータに見えるので私ならDBに入れずにログファイルに書き込んでDBからは切り離します。ストレージの無駄遣い、ダメ、ゼッタイ。

Comments

[antonio]

ありがとうございます。参考にさせて頂きます。

responseでした…

Answer 3

以下参考
RDBのテーブル分割について

現状（問題が無い）であれば、分割する必要は無いでしょう。
リンク先で言う所の「集約」用のテーブルについても、SQLで参照しない前提であれば、必要な項目のみのインデックスを作成し、インデックスのみのスキャンを行うようにすることで、代替えになりますし。

Comments

[antonio]

ありがとうございます。勉強になりました。