Q&A
テーマ、知りたいこと
PHP/Laravelで自作アプリを制作中です。
サーフボードのレンタル及び販売ができるようなアプリを計画しています。
今回実装する機能に対してのテーブル設計及びER図が正しいか確認したいです。
また、今回実装する機能としては主に以下の通りです。
・会員登録機能
・ログイン、ログアウト機能
・出品機能
・検索機能
・チャット機能
以下については追加実装予定の機能です。
・決済機能
・お気に入り追加機能
・閲覧履歴機能
テーブル定義書やER図についても自分なりに作成し、
下記Githubレポジトリにまとめましたのでご確認いただけると幸いです。
https://github.com/tomo4322/my_own_application.git
背景、状況
PHPを1ヶ月ほど学習し、今回の自作アプリはLaravelでの開発予定です。
開発環境はDockerを予定しています。
Docker内のコンテナは以下の通りです。
PHP
MySQL5.7
nginx
どうかよろしくお願いいたします。
回答2件
#1
総合スコア36974
投稿2023/02/04 06:52
編集2023/02/04 06:59そもそも意見を求める場合「このシステムは誰が何をするものか？」ということが分かる情報＝ユースケースが必要です。
この質問本文がそれを説明するものだとしても、ざっと読んで
- システム運営者＝サーフボードをレンタル・販売する店舗
- 会員＝サーフボードをレンタル・購入する人
と解釈したのですが、そうではなく
- メルカリみたいな会員同士でレンタル・交換しあう場で、システム運営者はその場の管理者
といったサービスのように感じましたが正しいでしょうか？
それを明確にする必要があるのでは？ということです。
また各機能についても「検索機能」とは「何の目的で誰が何を検索するものなのか？」ということを示すべきです。それらが明確になって、はじめてER図やテーブル定義の妥当性が判断できます。
たとえば今時点の情報だけだと、出品登録画面に「浮力」という入力項目があるがテーブルにはない
という点について、画面が間違っているのかテーブルが間違っているのかが判断できないです。
以上はとりあえず無視（勝手に想像）して出品周りをみて思ったこととしては
- レンタルはいいとしても販売という出品の日時を日付(date)で管理するのはどうなんだろう？（売れるならいつでもいいと思うけど）
- レンタルでも出品でも成約したかどうかの状態は持たなくていいんだろうか？
といったところでしょうか。
#2
can110様
ご回答及びご指摘ありがとうございます。
ご質問する際にはシステムの使用用途をより明確にし、誰が見ても分かるようにするべきだと再認識させていただきました。
浮力という点につきましても、データベーステーブルに長さ、浮力、としっかり入力フォームごとのカラムを作成いたします。
出品の日時についても訂正いたします。
成約したかどうかの状態については、
取引実績テーブルを新しく作って管理してみようと思います。
ありがとうございした！
とても勉強になりました。
今後ともよろしくお願いいたします。
下記のような回答は推奨されていません。
このような回答には修正を依頼しましょう。