Q&A
タイトルはなるべく詳細要件を記載願います。汎用的すぎたり起きている問題に対して大きすぎるカテゴリだと要件も伝わりにくくなります
前提・実現したいこと
仮定１） 毎年変更のある本の名前DBに保存させる。
仮定２） 毎年変更のある筆者の情報をDBに保存させる。
ご指摘いただきたい点
中間テーブル同士（author_bookテーブルとbook_yearテーブル）をさらに中間テーブル(author_book_yearテーブル)にすることは良いのか悪いのかをききたいです。
該当のイメージ図
該当のイメージ図2
発生している問題・エラーメッセージ
素人ながら中間テーブル同士の結合をして良いのかDB設計に悪戦苦闘しております。 DB設計をご教授いただけたら幸いです。
あと、 細かいんですが
>最後までお願いいただけますよう
どういう意味でしょうか
変更しました。
パフォーマンスまで追求されるのでしたらどれくらいのスパンでどれくらい増えるとか、指標が必要です。
それと、「毎年変更がある」って、本も作者も出版してしまえば変わることはないと思いますが…？
仮定になります。
もう１点。
何に悩んでいるのかわかりません。レビュー依頼(この時点で質問ではないです)にしては要件など不足している部分が多すぎます。
DB設計はあくまで基本設計フェーズです。どういう要件に基づいて作られたDB設計なのか、もっと詳細の要件定義を提示する必要があるのではないでしょうか。
パフォーマンスと言えど目指す指標があるはずです。
システム全体から考える必要もあるはずです。
内容によっては単なるQAにおさまるものではなくなり、きちんとお金を払ってコンサルに入ってもらう必要が出てきます(業務であれば尚更、無責任な赤の他人が手を出していいわけがありません)
回答に必要な情報があまりにも不足しているので必要な回答は得られにくそうかなと思います。
何に悪戦苦闘しているのかを具体的に質問に書くと、回答が得られやすいと思います。
「ふさわしい」とは、具体的に何を、どのような指標で評価するのかを示してください。
DBが備えるべき機能(どのような使い方ができるようにするか）と、実装上の優先順位（検索速度が速い、更新が容易、必要とするメモリやディスクの容量が少ない、等々）を明らかにすると回答が得られやすいと思います。
図では、どのテーブルにも"id"という同じ名前の項目(プライマリーキー?)があり、他のテーブル名+"id"という名前の項目で他のテーブルのidを参照しているように見えますが、項目には意味の分かる項目名をつけたほうが判りやすいです。
例えば、bookテーブルのプライマリーキーは"book_id"、authorテーブルのプライマリーキーは"author_id"などというように。
中間テーブル同士（author_bookテーブルとbook_yearテーブル）をさらに中間テーブル(author_book_yearテーブル)にすることは良いのか悪いのかをききたいです。に追記いたしました。
例えばですが、
2018年に「ほげほげ」さんが「ほげ本」というタイトルの本を出したとして、
2019年に「ほげほげ」さんが名前を「ふがふが」に変えたとき、
「2018年-ほげほげ-ほげ本」という3点セットを、
「2019年-ふがふが-ほげ本」という3点セットに変更していいのでしょうか？
多分ダメなのでしょう？
同様に本の名前も変わる前提だけど、同様に既存のデータは変わってしまってはいけないのでしょう？
では、同じタイミングで同じ著者が書いた別の本で、著者の名前が違うということはあるのでしょうか？
各テーブルに格納したい内容を日本語で説明した方が欲しい答えが返ってきやすいですよ
回答1件
0
本と発刊年を分ける必要性について、それが発刊する側であれば必要な事はあるかもしれません。
ですが、著作者との関係を考える際においては、本と発刊年はマッピングされるものではありません。
登場するもので固有であるものは、本と著作者ですので、発刊年は本に含まれ、発刊年とそれに関係するマッピングは不要だと思います。
発刊年が必要な場面は本を作る場面でのみで良いかと思われますが、必要だと思われる要件の説明が無いと断定はできませんが。
投稿2019/11/26 00:38
編集2019/11/26 00:42
総合スコア25327
意味合いとですが、初版、第1版第○刷のように同じ本でも名前が変わるものを示しております。
そのため
タイトル XXXXX 本 という book_id = 1
初版 2000年 year_id = 1
book_yearの
nameにはXXXXX初版
book_id = 1
year_id = 1
nameにはXXXXX第1版第１刷
book_id = 1
year_id = 2
にする想定でいます。
本のIDは実体と１：１であるべきです。言われている事をタイトルと発刊年と考えると別な見え方がすると思います。
タイトルと発刊年から本が生成され、それに著作者をマッピングという風に考えると、もっとすっきりすると思いますけど。
タイトルと発刊年 = １つのテーブルにした場合
book_id
book_name
year_id
親となるbookテーブルを作成
id
親となるyearテーブルを作成。
id
year_name
上記のようになるのかと思い質問のようなERになっておりますがもっと良い方法がありますでしょうか？
book(id, タイトルID,発刊年ID)としてそれとauthorをマッピング
タイトルと発刊年はマッピングされるものではなく、bookとは外部参照の関係とします。
親子関係を結ばせる必要がないということでしょうか？
その年に本を作るかどうかが可変な場合であれば、タイトルIDと発刊年のマッピングを考えますが、それを本が作られる前の工程と考えれば、タイトルIDと発刊年のマッピング情報と著作者の関係は不要です。
本を作る事が決定されなければ、著作者の選定など行われませんし、確定した本と著作者の関係である方が自然です。
質問者さんの定義に従うなら、book_yearが本の実態です。
book_yearとautorのマッピングを行えば良いので、author_bookは不要です。
その場合
bookテーブル
id, 1
タイトルID,：1
発刊年ID：1
id, 2
タイトルID,：2
発刊年ID：2
id, 3
タイトルID,：3
発刊年ID：3
id, 4
タイトルID,：4
発刊年ID：4
タイトルテーブル
１：タイトル初版
２：タイトル第２版
３：タイトル第３版
発刊年テーブル
ID1:name2020
ID2:name2021
ID3:name2021上半期
ID4:name2021下半期
上記のようになるのかと思いますが間違っておりますでしょうか？
この際本を取得する際にIDが変わるため同一の本として扱うことができないのかと懸念しております。
質問者は情報を小出しにするのは止めましょう。
テーブルの定義情報だけでなく、質問に実際にテーブルに入るデータもいっしょに提示できた方が適切なコメントが付き易いかと。
コメントが前後していますので、もう一度。以下でお考え下さい。
質問者さんの定義に従うなら、book_yearが本の実態です。
auther_book_yearはauthorとbook_yearrのマッピングとし、author_bookは不要です。
たびたびすみません。
小出しになっているようで申し訳ありませんが、author_bookについてですが、作者の変更、ペンネーム、結構、プロフィール情報をその年のをもちたいため作成しております。
その年のユーザー情報を持つテーブルになっております。
その年の本とその年のユーザー情報を紐づけたテーブルがauther_book_yearという認識でいます。
もっと最適化できるのでしょうか？
author_bookにその年の情報はもてないでしょう？
ユーザ情報って何ですか？
名前と内容が一致していないなら、判断しかねます。
そもそも中間テーブルは、n:nになるものを一意にするためにあるのですけど、そうでないなら敢えて作成する必要は無いものですが。
質問内容ではidが一意キーになっていますが、idではなくリレーションされている項目の組み合わせで一意とした時に成立するのが本来の中間テーブルです。
あなたの回答
tips
プレビュー
