PHPの二次開発に対する疑問-PHPチュートリアル-php.cn

PHP二次開発についての質問
今度は、1)フロントエンドの販売者がサービス情報を公開する、2)バックエンド管理者がレビューして通過した後、販売者のサービス情報を公開するという関数を作ろうとしています。ウェブサイトで公開できます。。 3) 購入者は検索を通じて適切なサービスを検索します。 4) 購入者は (Alipay を通じて) 支払います。 5) 管理者はレビューします。レビューに合格すると、販売者に通知が届きます。 6) 販売者の確認を待ち、承認後にサービスが完了します。その後、販売者がサービスを提供します。サービスプロセス中に、売り手は情報を公開し、買い手はサービスの進行状況をリアルタイムで確認できます。サービス終了後は双方がお互いを評価し合うことができます。これでプロセスは終了です。バックエンド管理者は、トランザクションプロセス全体を監視できる必要があります。そして、私の現在のタスクは、ステップ 2 とステップ 5 の機能を実装することです。これは、Web サイトの背景がプロセス全体で行う必要があることを意味します。しかし今、私はプロセスの他の部分を行っていません。上司は私にこれらの 2 つのステップをバックエンドで実行するように要求しています。私の頭ではまったくわかりません。働き始めてから初めて二次開発をしたのですが、1 か月ほど断続的に PHP を勉強したところ、上司に急かされて棚に上げました。、それでは今、ご指導をお願いしております。
-----解決策---------
1) 販売者がサービス情報を公開する場合、データベース内のステータスなどのフィールドを 0 に設定できます
2) ステータス 0 のサービス情報をレビュー用に取り出し、
4) を通過した後にステータス 0 のサービス情報を取り出します。購入者の支払いを記録するステータスフィールドを 0 に設定します
5)レビューのためにステータス 0 の取引記録を取り出し、合格後に 1 に設定し、その後、販売者の受け取りなどの他の操作を実行します通知

アイデアです。ステータスフィールドの値は自分で定義できます。必ずしも 0 または 1 である必要はありません。実際の状況に応じて決定されます。
---- --解決策----------- ---------
サービス情報テーブルのフィールド: tb_ser sid (サービス情報 ID)、mc、status (監査フラグフィールド) ... (その他の情報フィールド);
receipt Record テーブル: tb_pay id (レシートレコード ID)、sid (サービス情報 ID)、status (請求レビューフラグフィールド)... (受取人および支払者の一部の情報フィールド) 、冗長性を恐れず、他のテーブルと混在させないでください。他のテーブルが関連付けられており、他のテーブルレコードの変更によって課金レコード情報が変更されることはありません）

フロントデスクでサービス情報を表示および検索する場合、 get tb_ser.status='1' ;
------ 解決策---------
の場合二次開発ではないのですが、完全に開発していただけますか？
そうではないと思いますね?
つまり、これは二次開発とは何の関係もありません。
ビジネスロジックが明確になったら、それをコードに実装するだけです。
それは単なる CRUD です
-----解決策---------
2) 実行します管理者の審査後、審査を通過した場合、販売者のサービス情報をWebサイトに掲載することができます。
5) 管理者のレビュー。レビューに合格すると、販売者に通知が届きます。
これはモジュール化ではないでしょうか?
プロセスは次のとおりです:
未監査のエントリを取得
監査済みのマークを記入
メッセージを送信

未監査データのソースとメッセージの送信先が決定されます設定ファイルで指定すると、開発中に
を仮想化できます-----解決策----------------------

Quote:

Quote: Quote:

サービス情報テーブルのフィールド: tb_ser sid (サービス情報 ID)、mc、status (監査フラグフィールド) ...(その他の情報フィールド);
領収書レコードテーブル: tb_pay id (領収書レコード ID)、sid (サービス情報 ID)、ステータス (請求レビューフラグフィールド) ...(受取人および支払い)反対側の一部の情報フィールドは、冗長性を恐れず、他のテーブルのレコードの変更によって課金レコード情報が変更されることはありません)

前面にサービス情報を表示および検索する場合。デスク、get tb_ser.status=' 1' ;

サービステーブルと支払いテーブルの SID を関連付ける必要がありますか?そして「MC」とはどういう意味ですか？。。サービス情報には、文字による紹介や画像による紹介などのサービス紹介が含まれる場合。覚える必要はなく、スケジュールか何かを見てこの内容をスケジュールに入れていけば大丈夫です。

sid を関連付ける必要があります。mc は名前です (mc は変更されても関連付けられない場合があります)。サービス情報テーブルは非常に頻繁にクエリされるため、その情報を取得するのが最善です。 1 つのテーブルに表示されると、スケジュールを作成するときに複数のテーブルをまとめて確認する必要があり、効率に影響します。
------解決策---------
はい

引用:

引用: 引用:

引用: 引用:

Quote: Quote:

サービス情報テーブルのフィールド: tb_ser sid (サービス情報 ID)、mc、status (監査フラグフィールド) ... (その他の情報フィールド);
受領記録テーブル: tb_pay id (受領記録 ID)、sid (サービス情報 ID)、ステータス (請求レビューフラグフィールド)... (受取人と支払者の一部の情報フィールド、冗長性を恐れないでください)他のテーブルと関連付けないでください。他のテーブルレコードの変更によって課金レコード情報が変更されることはありません)

フロントデスクでサービス情報を表示および検索する場合、 tb_ser.status='1' ;

そのサービステーブルと支払いテーブルの SID は関連付ける必要がありますか?そして「MC」とはどういう意味ですか？。。サービス情報には、文字による紹介や画像による紹介などのサービス紹介が含まれる場合。覚える必要はなく、スケジュールか何かを見てこの内容をスケジュールに入れていけば大丈夫です。

sid を関連付ける必要があります。mc は名前です (mc は変更されても関連付けられない場合があります)。サービス情報テーブルは非常に頻繁にクエリされるため、その情報を取得するのが最善です。 1 つのテーブルに表示されると、スケジュールを作成するときに複数のテーブルをまとめて確認する必要があり、効率に影響します。

ああ、最後の質問ですが、その関連付けは外部キーですか?

はい
----- -解決策---- ----------------

引用:

引用 : 引用:

引用: 引用:

引用: 引用:

サービス情報テーブルのフィールド: tb_ser sid (サービス情報 ID)、mc、status (監査フラグフィールド) ... (その他の情報フィールド);
回収記録テーブル: tb_pay id (入金記録 ID)、sid (サービス情報 ID)、status (料金審査フラグ)フィールド)... (受取人および支払人の一部の情報フィールドは冗長性を恐れず、他のテーブルに関連付けないでください。請求レコード情報は、他のテーブルレコードの変更によって変更されることはありません。)

フロントでサービス情報を表示・検索する場合、 get tb_ser.status='1' ;

サービステーブルと支払いテーブルのSIDを関連付ける必要がありますか?そして「MC」とはどういう意味ですか？。。サービス情報には、文字による紹介や画像による紹介などのサービス紹介が含まれる場合。覚える必要はなく、スケジュールか何かを見てこの内容をスケジュールに入れていけば大丈夫です。

sid を関連付ける必要があります。mc は名前です (mc は変更されても関連付けられない場合があります)。サービス情報テーブルは非常に頻繁にクエリされるため、その情報を取得するのが最善です。 1 つのテーブルに表示されると、スケジュールを作成するときに複数のテーブルをまとめて確認する必要があり、効率に影響します。

最後の質問は、関連付けは外部キーを設定しますか?