Closed furukoshi12 closed 1 year ago
各テーブルとカラムの説明をこちらに記載お願いします 🙏🏻
Usersテーブル:ユーザー情報 email:メールアドレス name:ユーザーネーム icon_id:使用するアイコンのID role:管理者か一般ユーザーか(enum) guest:ゲストログインかどうか(ゲストの場合true) crypted_password:ハッシュ化されたパスワード salt:パスワード末尾に追記される文字列 reset_password_token: パスワードリセット用 reset_password_expires_at: パスワードリセット用 reset_password_email_sent_at: パスワードリセット用 access_count_to_reset_password_page: パスワードリセット用
Iconsテーブル:アイコン情報 icon_name:アイコンの名前 icon_image:アイコンの画像(こちらで用意) unloacked:そのアイコンが使用可能か(図鑑情報から登録されている種名を取得して同じ種名のアイコンがあればtrueにする)
Likesテーブル:お気に入り情報 user_id:お気に入りしたユーザーのID illustrated_book_id:お気に入りされた図鑑のID
Illustrated_booksテーブル:図鑑情報 user_id:その図鑑を作成したユーザーのID title:図鑑のタイトル content:図鑑内の説明文など image:図鑑に表示する画像(ユーザーが登録) template_id:使用する図鑑テンプレートのID map:google mapを表示するかどうか
Templateテーブル:図鑑テンプレート情報 template_name:テンプレートの名前
Fieldsテーブル:入力フォームの種類情報 field_type:入力フォームの種類名
Illustrated_book_fieldsテーブル:図鑑と入力フォームの中間テーブル illustrated_book_id:図鑑のID field_id:使用する入力フォームのID
Template_fieldsテーブル:テンプレートと入力フォームの中間テーブル template_id:テンプレートのID field_id:入力フォームのID
以上になります。 ご確認ください。
ご提出ありがとうございます。 私から気になったところをコメントさせていただきますね。
テーブル名がキャメルケースとスネークケースが混在してしまっているので、スネークケースでの統一をお願いします。
こちら画面遷移図を拝見させていただいた時に、いくつかの種類のテンプレート、フィールドがあるように思いました。
上記ですと、enumを使って管理するイメージがあるのですが、enumで管理するご予定はないでしょうか?
enumであればstring
ではなくinteger
になるかと思いました。
(enumで管理しないのであればstring
でも大丈夫です。)
unloacked:そのアイコンが使用可能か(図鑑情報から登録されている種名を取得して同じ種名のアイコンがあればtrueにする)
とあるのですが、こちらはユーザーごとにunloacked
の値が変わるイメージでしょうか?
テーブル名がキャメルケースとスネークケースが混在してしまっているので、スネークケースでの統一をお願いします。
Illustrated_book_tagsテーブルのillustrated_book_idカラムの箇所でしょうか? 修正いたしましたが他の箇所もキャメルケースになっていましたら再度ご教示ください。
Templateテーブル・Fieldsテーブルの件ですが、ご指摘の通りenumでの管理に変更しようと思います。 データ型をintに変更しました。
Iconsテーブルの件
こちらはユーザーごとにunloackedの値が変わるイメージでしょうか?
こちら、おっしゃる通りです。
ご指摘を受け、Userごとにunloacked
の値が変わる場合はIconテーブルでこのカラムの管理はできないのではないかと考えたのですがこちらの認識は正しいでしょうか?
中間テーブルを作成しuser_id
icon_id
unloacked
のような設計が正しいのではないかと考えています。
ただしこの場合中間テーブルにFK以外のカラムが入ってしまうのでアンチパターンになりますでしょうか?
また上記のコメントには記載はなかったのですが、Illustrated_booksテーブルでcontentカラムで入力内容を保存しようと思っていたのですが入力フォームが複数ある場合、contentカラム一つで管理できないような気がしてきました。Illustrated_book_fieldsテーブルにcontentカラムを入れれば解決するのではと考えたのですがこちらも中間テーブルにFK以外を入れることになるのが気になります。
ご確認のほど、よろしくお願いいたします。
私からも気になった点をコメントします。
■likesテーブル ・usersテーブルとllustrated_booksテーブルの中間テーブルのようですが、それぞれに多対多の関係になっていますが間違いないでしょうか?リレーショナルデータベースで多対多の場合はどうしたら良いか復習しましょう。
■llustrated_book_tags ・llustrated_booksテーブルと多対多の関係になっていますが、問題ないか確認しましょう。
修正いたしました。 FieldsテーブルはAttachmentsテーブルに変えました。
ご対応ありがとうございます。 以下、追加のコメントになります。
■tagsテーブル ・tag_name:カラム名はnameで良いかと思いました。
■like_illustrated_booksテーブル ・テーブル名はlikesテーブルでも良いように思いました。
■illustrated_booksテーブル ・map:Google Mapを表示するか否かのカラムなら、それがカラム名から分かるような命名にしましょう。左記はChatGPTが出した候補になります。(show_google_map・display_google_map・google_map_enabled)
■templatesテーブル ・template_name:nameカラムで良いように思いました。
■usersテーブル ・guest:bookean型の値でゲストか否かを判定しようとしているかと思いますが、ゲストログインはどのように実装する想定でしょうか。コメントに詳しく説明をお願いしたいです。
ゲストログインはどのように実装する想定でしょうか。 guestカラムがtrueの場合マイページなどの表示を条件分岐で非表示にして操作を制限しようと考えています。
再提出ありがとうございます!
tagsテーブル ・tag_name:カラム名はnameで良いかと思いました。
こちらの件、iconsテーブルにも同じことが言えるかと思います。
ご確認よろしくお願いします。
修正しました。
ER図を作成しました。 ご確認の程よろしくお願いいたします。