ハッシュタグのDBテーブル構造

Question

前提・実現したいこと

インスタグラムのようなSNSをPHP+MySQLで作成しています。
投稿する際に、記事にハッシュタグを複数つける機能を実装したいのですが、データベースのテーブル構造でどちら（もしくはそれ以外）が最適かを教えて頂けますでしょうか？インスタグラム同様にハッシュタグはユーザが任意で作成する事が出来ます。
また、DBに格納するハッシュタグに"#"は必要でしょうか？

■Scuttle法
・投稿テーブル
投稿ID , 投稿内容

・タグテーブル
投稿ID , ハッシュタグ

例）
・投稿テーブル
1 , 1/1の天気
2 , 1/2の天気

・タグテーブル
1 , #昨日は雨
1 , #そろそろ梅雨明け
2 , #洗濯日和
2 , #そろそろ梅雨明け

■Toxi法
・投稿テーブル
投稿ID , 投稿内容

・中間テーブル
投稿ID , タグID

・タグマスタテーブル
タグID , ハッシュタグ

例）
・投稿テーブル
1 , 1/1の天気
2 , 1/2の天気

・中間テーブル
1 , 1
1 , 2
2 , 2
2 , 3

・タグマスタテーブル
1 , #昨日は雨
2 , #そろそろ梅雨明け
3 , #洗濯日和

Answer 1

SNSであれば、時間が経過すると共に状況が変化するので、設計を変更する場面も少なからずあると思われます。

正規化の観点からすると、Scuttle法よりToxi法の方が正規化は進んでいるので、稼働後にデータを正規化するのと正規化を緩めるのでは、緩める方が楽ですが、データを扱うプログラムは逆です。

どちらという断定はできないのですが、こちら（DBの正規化は重要！タグ機能に関連するテーブルを作り替えた話）なども参考に。

Answer 2

それこそTeratailのように、「タグは運営の決めたものだけ」というようにするのであれば、中間テーブルを挟む方法一択となります。

一方、Twitterのようにタグも自由に増える環境では、タグテーブルで管理するにはタグが増えすぎるということもあって、タグの正規化をしないのも選択肢となるのかな…という印象です。

Comments

[sazi]

タグの選択肢が固定であっても、Scuttle法の構造にする事もできるのと思うのですが。

[maisumakun]

> saziさん

その状況でもScuttle法をとることは、もちろん技術的には可能ですが、（タグ一覧をRDBMS外に持つなど特殊な構造を取るのでなければ）基本的にはデメリットしかないので、意味のある選択肢にはならない、と判断します。

[sazi]

いえ、タグの一覧はDBとして保持しておいて、タグの選択肢はそこから取得するという想定です。
ん、仰っているのは違うことですね。
デメリットとは何でしょう？

[maisumakun]

その状況でScuttle法を取るメリットは何があると考えていますか？

[sazi]

Scuttle法を採用する場合の、タグのマスターをDBに持つ持たない事に関するメリット/デメリットという観点では考えていません。

「タグの選択肢が固定だった場合」に、「Toxi法一択」になる訳ではないということでは一致しているので、逆に私は気づけなかったデメリットをご教示下さると、嬉しいです。

[maisumakun]

「データベースにマスターがあるにも関わらず、それを参照せずに別個にデータを入れる」ということ自体、自分の感覚では「わざわざやること」です。

マスターを参照すれば外部キー制約もかかりますし、それ以外の構造にするという選択肢に（DB構造やエンジンなどで制約がある場合を除けば）有利性はないと考えました。

[sazi]

了解しました。ありがとうございました。