データモデリング再考

[tokku5552]

概要

• 本の情報の持ち方、状態の管理の仕方やユーザー情報に何をもたせるか？どのタイミングでなんのデータを作るか？を議論する土台ができてきたので、このタイミングで一度再考したい
• 関連issue

  • 48

  • 13

背景

1. 今回、初期の設計でBookとRegisteredBookを分けて保持するように設計した。理由は、本棚に登録するときに保持しておきたい情報(読んだ回数、読んだ履歴、追加した日など)と、楽天APIから取得できる純粋に商品としての本の情報を分けて管理するため。ただ、この方式だと作品詳細画面では別のデータモデルを参照することになり、どこから画面遷移してきたのかを判断する必要が出てしまう。

2. もう一つ分けた理由としては、楽天APIからの情報取得とその保持をなるべく少ない回数で行いたかったため。レート制限の問題や、同じ本の情報がfirestore上のあらゆる箇所に保存される事になり非効率と考えた。

論点

上記が初期の徳田の考え方だが、開発を進めていく上で関連issueで議論されている通り、以下の問題点が浮かび上がった。

1. 本棚or検索画面で選択された本の情報をどうやって詳細画面に渡すか

• ほんの情報をそもそもfirestoreに保持しない作りを想定しているため、Bookの情報はどこかのタイミングで楽天APIを叩いて取得する必要がある。
• そのBookの情報を直接渡さない限りは詳細画面で再度APIを呼び出すことになり、非効率
• これを共通で使えるStateとして定義する案が浮上

2. ユーザーと本棚の関係

• 登録したユーザー(親を想定)と本棚は1対多の関係になっており、本棚はほぼ子供とイコール(誰の本棚か、その子は何歳かの情報を持つ)
• これはusersコレクションの下でさらに重複したデータを保持することになる
• 登録したユーザー(picbook上でのアカウント)とそれを使う子供がそれぞれ持つ情報や登録タイミングを詳細化し、必要であればfirestoreのコレクションの構造はがらっと見直す必要がありそう。

進め方(案)

• 一旦私持ちでそれぞれの実現方法のたたき台を考えて見るので、それをもとにみんなで議論できればと思います。

[tokku5552]

1. については技術的な問題で、実現したい要件は明確ですが、2. については要件が少し曖昧なので、 #13 でそこを詰めれればと思います。

[tokku5552]

• Userからnameとbookshelfはずす
• bookにregisteredbookで保持していた履歴系の情報をもたせる
• bookshelfにownerとowner_birthday的な情報もたせる

というスキーマの変更をコードに落としておく