Q&A
こちら解決されてからの方が良いのでは。
https://teratail.com/questions/249168
##<前提>
掲示板にタグがついています。
そしてそのタグを元にして、掲示板へのコメントが検索できるようになっています。
######テーブル構成
mysql > posts
| post_id | parent_thread_id | post_type | text |
|---|---|---|---|
| 1 | 0 | thread | #海 と #山 についての掲示板 |
| 2 | 0 | thread | #空 についての掲示板 |
| 3 | 1 | comment | 槍ヶ岳について #優しく 教えてください |
mysql > tags
| tag_id | tag_name |
|---|---|
| 1 | 海 |
| 2 | 山 |
| 3 | 空 |
| 4 | 優しく |
mysql > tag_relations
| relation_id | post_id | tag_id |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| 3 | 2 | 3 |
| 4 | 3 | 4 |
######検索機能
検索機能は、上の３つのテーブル構成のとき、「#山」で検索すると以下２つが取得できるような機能です。
| post_id | parent_thread_id | post_type | text |
|---|---|---|---|
| 1 | 0 | thread | #海 と #山 についての掲示板 |
| 3 | 1 | comment | 槍ヶ岳について #優しく 教えてください |
「#山」は「post_id=1」が持っているのでまず取得します。
さらに「parent_thread_id」によって「post_id=1」へのコメントとして「post_id=3」も取得されます。
##<質問>
tag_relationsのテーブルに、以下のように「relation_id=5」と「relation_id=6」も追加すべきでしょうか？
mysql > tag_relations
| relation_id | post_id | tag_id |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| 3 | 2 | 3 |
| 4 | 3 | 4 |
| 5 | 3 | 1 |
| 6 | 3 | 2 |
「relation_id=5」は、「post_id=3」が「#海（tag_id=1）」を持っているという意味です。
実際には「post_id=3」は「#優しく（tag_id=4）」しか持っていないので、前提のテーブル設計はそうなっていました。
ですが、このコメントの投稿先掲示板は「#海（tag_id=1）」と「#山（tag_id=2）」を持っているので、tag_relationsのテーブルにそのことを追加すべきかどうかというのが質問になります。
それがなくても検索はできるので不要でしょうか？
それともきちんと追加した方がいいのでしょうか？
ベストアンサーを決めるということでしょうか？yambejpさまとやりとりの最中なので、ひとまずそのままにしている状態です。
流れとして同じものであればそちら解決してからでないと、
こちらの質問内容にあるコードやデータの状態も変わってくるのではないですか？
何度か目にすることがあります。
質問している中で新たな疑問がわいて、そのときのコードそのままで新規に質問してしまい、結局前の質問で解決した内容でコードが変わり、整合性が取れなくて混乱してしまうパターン。
なるほど、お気遣いありがとうございます。そちらの質問はpostsからの取得についてですが、こちらの質問でtag_relationsのレコードが増減しても、特に影響はなさそうです。
レコード・・・はともかく今回はテーブル構成のほうを気にしています。
うーん、一方の質問の如何でもう一方のテーブル構成が変わることはないですね。ご心労おかけしてすみません。
いえいえ、こちらもちょっと深く突っ込みすぎました。
「槍ヶ岳について #優しく 教えてください」が検索をかけるとなぜ
「山について #優しく 教えてください」に変化するのでしょうか
すみません、誤字です。いずれも「槍ヶ岳」に修正いたしました。
回答1件
0
ベストアンサー
post_id=3は紐付けが4=優しくにしかされていないので
山ではひっぱれません
そうしたいならtag_relationsにpost_id=3,tag_id=2を
追加してください
投稿2020/03/25 11:57
総合スコア116724
「槍ヶ岳について #優しく 教えてください #山」
のようなハッシュタグで連携するならrelation用の
テーブルはいらないですけどね
いつもありがとうございます。
>post_id=3は紐付けが4=優しくにしかされていないので
山ではひっぱれません
以下の流れで取得できませんでしょうか？
「#山」で検索
↓
「#山（tag_id=2）」を持つ「post_id=1」を取得
↓
「post_id=1」を「parent_thread_id」として持つ「post_id=3」を取得
こちらで「山」から「post_id=3」を取得できていると思うのですが、何か誤解ありますでしょうか？
SELECT *
FROM posts
WHERE parent_thread_id = ( SELECT post_id
FROM relations
WHERE tag_id = ( SELECT tag_id
FROM tags
WHERE tag_name='山'
)
)
なるほどparent_thread_idの使い方がそういうことですか
post_id=3は親属性1（海、山）と、独自の属性（優しく）を
持つということですね
データ管理が煩雑になりそうですが、親属性を引き継ぐのが
マストであればそういうやり方でもよいでしょう
単純な親子だけならそれなりですが、多段になった場合
そうとうめんどくさい仕様になりそうです（親＝孫、親＝ひ孫）
上記親子関係で処理するなら質問の5,6は不要です
ご返信ありがとうございます。
煩雑ですよね。5,6を追加すればその煩雑さがなくなるかと考えたのですが、やはり追加しない方がいいでしょうか？
完成形はこちら（http://sqlfiddle.com/#!9/5a682f/1）でして、もし5,6を追加すればこちらの➃がなくても➂だけで機能し、煩雑さがなくなります。
そのために5,6を追加した方がいいのかと悩んでいる次第です。
しかし5,6を追加するとtag_relationsのデータが多くなってしまいますし、どうしたらいいと思いますか…？
>単純な親子だけならそれなりですが、多段になった場合
そうとうめんどくさい仕様になりそうです（親＝孫、親＝ひ孫）
ですね。お気遣いありがとうございます。多段（reply）は今回のSQLでは取得しないつもりです。threadとcommentだけを考えております。
親子だけならそのままで大丈夫でしょう（5,6不要）
多段にする場合は木構造をつかった管理にするとすっきりします
なにかの機会があれば試してみてください
（プロシージャで更新処理を入れるので最初は
ハードルが高いかも・・・）
なるほど。ちなみにどうして5,6不要なのでしょうか？
先のリンクについて、➃がない方が処理が早いと考えているのですが（5,6を追加すれば➂だけで➃の情報が取得できるため）、それとも5,6を追加しtag_relationsのデータが多くなるとJOINの量が増えて逆に速度は遅くなるということですか？
> どうして5,6不要なのでしょうか？
親子関係があって、親の属性を引っ張る仕様のテーブル構成だからです
逆に5,6をつけると親の属性が変更になったとき、あわせて
追加削除が必要になり、親からもらうのか、自分属性だけ直接
参照するのか１本化した方がよいという意図です
なるほど。どうもありがとうございます。納得できました。
あなたの回答
tips
プレビュー
