PHPの二次開発に関する質問

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

ディスカッションへの返信（解決策）

1) 販売者がサービス情報を公開するときに、データベース内のステータスなどのフィールドを 0 に設定できます
2) ステータス 0 のサービス情報を取り出すレビューし、合格後 1 に設定します
4) 購入者の支払記録のステータスフィールドを 0 に設定します
5) ステータス 0 の取引記録をレビューのために取り出し、通過後 1 に設定し、その他の処理を実行します販売者が通知を受け取るなどの操作

これはアイデアです。ステータス フィールドの値は自分で定義できます。必ずしも 0 または 1 である必要はなく、実際の状況に応じて決定されます

1)販売者がサービス情報を公開する際に、データベース内のステータスなどのフィールドを 0 に設定できます
2) ステータス 0 のサービス情報をレビュー用に取り出し、合格後に 1 に設定します
4) ステータスフィールドを設定します購入者の支払い記録を 0 にします
5) レビューのためにステータス 0 の取引記録を取り出し、通過後に 1 に設定して続行します 販売者が通知を受け取るなどのその他の操作

アイデアは次のようになります。 status フィールドの値は、実際の状況に応じて、必ずしも 0 または 1 である必要はなく、自分で定義できます

関連する類似のソース コードはありますか? 初めての二次開発のため、関連プロジェクトを参照したいのですが? 。

ソース コード プロジェクトについてはわかりません

ソース コード プロジェクトについてはわかりません

ああ、わかりました、ありがとう

サービス情報テーブルのフィールド: tb_ser sid (サービス情報 ID)、mc、status (audit)マーク) フィールド) ...(その他の情報フィールド);
収納記録テーブル: tb_pay id (収納記録 ID)、sid (サービス情報 ID)、status (請求先と支払者の一部)情報フィールドは冗長性を恐れず、他のテーブルと関連付けないでください)

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

二次開発じゃなかったら完全に開発できますか？
そうじゃないですよね？
なので、二次開発とは関係ありません。
ビジネス ロジックが明確になったら、それをコードに実装するだけです。
単なるCRUDです

二次開発じゃなかったら完全に開発できますか？
そうじゃないですよね？
なので、二次開発とは関係ありません。
ビジネス ロジックが明確になったら、それをコードに実装するだけです。
CRUD に過ぎません

何か指導をお願いします....

2) バックエンド管理者による審査と承認後、販売者のサービス情報を Web サイトに掲載できます。
5) 管理者のレビュー。レビューに合格すると、販売者に通知が届きます。
これがモジュール性ではないでしょうか?
プロセスは次のとおりです:
未監査のエントリを取得する
監査済みのマークを記入する
メッセージを送信する

未監査のデータのソースとメッセージの送信先については、構成ファイルによって指定され、開発中に仮想化できます

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

フロント サービス情報の表示・検索時は tb_ser.status='1' を取得します。サービステーブルとコレクションテーブルのSIDを関連付ける必要がありますか?そして「MC」とはどういう意味ですか？ 。 。サービス情報には、文字による紹介や画像による紹介などのサービス紹介が含まれる場合。覚える必要はなく、スケジュールか何かを見てこの内容をスケジュールに入れていけば大丈夫です。

サービス情報テーブルのフィールド: 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 (料金レビュー フラグ フィールド)... (受取人および支払者の一部の情報フィールドは重複を恐れず、他のテーブルに関連付けないでください。課金記録情報は使用できません)テーブルレコードの変更により変更)

フロントデスクでサービス情報を表示および検索する場合、 tb_ser.status='1' を取得します
サービステーブルと支払いテーブルの SID を関連付ける必要がありますか?そして「MC」とはどういう意味ですか？ 。 。サービス情報には、テキストによる紹介や画像による紹介などのサービス紹介が含まれる必要がある場合。覚える必要はなく、スケジュールか何かを見てこの内容をスケジュールに入れていけば大丈夫です。

sid は関連する必要があります。mc は名前です (mc は関連しないように変更される場合があります)。サービス情報テーブルは非常に頻繁にクエリされるため、表示される情報が 1 つのテーブルに含まれることが最適です。テーブル結合クエリを作成するために数回行うと、効率に影響します。
ああ、最後の質問ですが、関連付けは外部キーとして設定されていますか? はい

サービス情報テーブルのフィールド: tb_ser sid (サービス情報 ID)、mc、status( Audit flagフィールド) ...(その他の情報フィールド);

回収記録テーブル: tb_pay id (領収書記録 ID)、sid (サービス情報 ID)、ステータス (請求監査フラグ フィールド)... (受取人および支払者の一部の情報フィールドの重複を恐れず、他のテーブルに関連付けないでください)

フロントデスクでサービス情報を表示および検索する場合。 , get tb_ser.status='1' ;
サービステーブルと支払いテーブルのSIDを関連付ける必要がありますか?そして「MC」とはどういう意味ですか？ 。 。サービス情報には、文字による紹介や画像による紹介などのサービス紹介が含まれる場合。覚える必要はなく、スケジュールか何かを見てこの内容をスケジュールに入れていけば大丈夫です。

sid は関連する必要があります。mc は名前です (mc は関連しないように変更される場合があります)。サービス情報テーブルは非常に頻繁にクエリされるため、表示される情報が 1 つのテーブルに含まれることが最適です。テーブル結合クエリを作成するために数回行うと、効率に影響します。
ああ、それでは最後の質問ですが、その関連付けは外部キーですか?
はい

サービス情報テーブルのフィールド: tb_ser sid (サービス情報 ID)、mc、status (監査フラグ フィールド) ... (その他の情報フィールド)
回収レコード テーブル: tb_pay id (領収書レコード ID); 、sid (サービス情報 ID)、status (請求レビュー フラグ フィールド)... (受取人および支払人の一部の情報フィールドは重複を恐れず、他のテーブルに関連付けないでください。請求記録情報はランダムに取得できません)他のテーブルレコードの変更により変更)

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

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

sid は関連する必要があります。mc は名前です (mc は関連しないように変更される場合があります)。サービス情報テーブルは非常に頻繁にクエリされるため、表示される情報が 1 つのテーブルに含まれることが最適です。テーブル結合クエリを作成するために数回行うと、効率に影響します。 ああ、それでは、最後の質問は、関連付けは外部キーを設定するかということです
関連付けは必ずしも外部キーを設定する必要はありません。データベース フィールドのデータを関連付け、データの関連付けを設定するだけで十分です。プログラムによる制約。データ設計のパラダイムを理解する必要があります。

サービス情報テーブルのフィールド: tb_ser sid (サービス情報 ID)、mc、status (監査フラグ フィールド) ... (その他の情報フィールド)
収集レコード テーブル: tb_ pay id(領収書レコード ID)、SID (サービス情報 ID)、ステータス (請求レビュー フラグ フィールド)... (受取人および支払者の一部の情報フィールドは、冗長性を恐れず、他のテーブル、請求レコード情報と関連付けません)他のテーブルレコードの変更では変更できません)

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

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

sid は関連する必要があります。mc は名前です (mc は関連しないように変更される場合があります)。サービス情報テーブルは非常に頻繁にクエリされるため、表示される情報が 1 つのテーブルに含まれることが最適です。テーブル結合クエリを作成するために数回行うと、効率に影響します。 ああ、それでは、最後の質問は、関連付けは外部キーを設定するかということです
関連付けは必ずしも外部キーを設定する必要はありません。データベース フィールドのデータを関連付け、データの関連付けを設定するだけで十分です。プログラムによる制約。データ設計のパラダイムを理解する必要があります。 ああ、わかりました、ありがとうございます