すべてのユーザーがデータベース内の 1 つのテーブルを共有しながら、各ユーザーの注文番号が独立した名前空間を持つにはどうすればよいでしょうか?

1. 実際のシナリオ:
データベース内の注文テーブルは公開されており、すべてのユーザーが 1 つの注文テーブルに属します。
各ユーザーの注文番号を独立した名前空間にする方法は?たとえば、ユーザー A が 2 つの注文を行う場合、その注文番号は C001 と C002 である必要があります。ユーザー B が 3 つの注文を行う場合、その番号の開始位置はすべて C001 である必要があります。 C003.
どうやってやるの？
各ユーザーの下に、現在開いている注文の数を示すフィールドを保存し、最初にそれを読み出し、1 つ追加してから保存し直す必要がありますか?これは良くありません...データベース側でそれを行うより良い方法はありますか?誰かがデータベース関数やトリガーの使用について話しているのを聞いたような気がします。

2. データベースが上記を実行できる場合、この C001 は通常主キー フィールドに存在しますか?それとも、主キーは数値タイプの増分主キーのままで、この C001 を格納するフィールドをテーブルに追加するだけですか?

注: これは Mysql データベースにあります。

返信内容:

1. 実際のシナリオ:
データベース内の注文テーブルは公開されており、すべてのユーザーが 1 つの注文テーブルに属します。
各ユーザーの注文番号を独立した名前空間にする方法は?たとえば、ユーザー A が 2 つの注文を行う場合、その注文番号は C001 と C002 である必要があります。ユーザー B が 3 つの注文を行う場合、番号付けの開始位置は C003 ではなく C001 であり、すべての注文番号は C002、C003 である必要があります。 。
どうやってやるの？
各ユーザーの下に、現在開いている注文の数を示すフィールドを保存し、最初にそれを読み出し、1 つ追加してから保存し直す必要がありますか?これは良くありません...データベース側でそれを行うより良い方法はありますか?誰かがデータベース関数やトリガーの使用について話しているのを聞いたような気がします。

2. データベースが上記を実行できる場合、この C001 は通常主キー フィールドに存在しますか?それとも、主キーは数値タイプの増分主キーのままで、この C001 を格納するフィールドをテーブルに追加するだけですか?

注: これは Mysql データベースにあります。

1: このようにデータベースに保存する必要はありません。すべての注文を走査して順番に表示するだけです。
2: 各ユーザー属性に 静态成员变量 を追加し、それに応じてデータベースにフィールドを追加します。毎回追加されるデータは、指定した内容になります。

投稿者が意味するのは、さまざまな顧客アカウントに対して統合された注文管理ライブラリを確立することです。これは、クラウド ERP に似ています。

注文テーブルは、データストレージの一意性の観点から、重複した主キー ID を持つことができ、注文コード + ユーザー ID として表示され、データを一意に確認できます。

テーブル構造の設計を最適化する必要がある場合は、各ユーザーに応じて注文テーブルを自動的に作成し、対応するテーブル名が見つかるたびに各ユーザーの注文データを分離できます。ユーザーによれば、データは取得されますが、最後にすべてのユーザー注文データの包括的なバックグラウンド統計を取得するのは少し面倒かもしれません。

注文の一意性をどのように確認できますか

タイトルの意味に従ってデータベースが設計されている場合、注文を見つけるの操作のみが例外を引き起こします。注文番号に基づいて 固有の順序 を決定することができないためです。
主キーの値は、テーブル内のレコードを 一意に 識別するために使用されます。

(プロジェクトについて
私がお勧めします:
Orderテーブルの主キーはOrderIdにすることができます
Userテーブルの主キーはUserIdにすることができます
あなたの問題はデータベーステーブルの基本的な理解にあると思います。それをお勧めします。データベース 正規化 関連コンテンツ)

を参照してください。

1. orderid テーブルを使用して、すべてのユーザーの次回の注文の ID を保存するのが面倒な場合は、注文番号の一部として時間を使用することをお勧めします。

2. 主キーとしては使用できません。主キーの設計には原則があり、ビジネスとは無関係である必要があります。したがって、主キーは常に意味のない自動インクリメントIDなどになります。

あなたの質問が解決しようとしている実際のニーズがわかりません

テーブル構造の設計は、3 つの最も基本的なパラダイムの要件に準拠する必要があります。 3 つのパラダイムの目的は、フィールド間に冗長性や依存性がないことを保証することです。上記の問題については繰り返しません。このような設計は、データベース テーブル構造設計の 3 つの主要なパラダイムの原則に違反しています。そのような設計を行うべきではありません。そうでない場合は、私たちがそれを誤解しています。あなたは質問を言い換えます。または、テーブル作成ステートメントを直接投稿します。

結合主キーを使用して uid と cid を組み合わせることができ、これにより一意性が保証されます。ただし、次の 2 つの点に注意してください:
1. mysql ジョイント主キーの自動インクリメントを使用するには、ストレージ エンジンとして MyISAM を使用する必要があります。
2. ユニオンを使用して主キーを自動インクリメントする場合、自動インクリメント キーを主キーの左端のキーにすることはできません。

user_owner_order_key を注文テーブルに追加し、C001 と実際の order_id の間の交換ロジックを処理する独自のコードを記述するだけです。

リーリー

別の話になりますが、一般的に第三方支付对于同一个订单号複数回の支払いはできないので、するかどうかはよく考えた方が良いです。

解決策

---

1. ユーザー テーブルには、注文数量を保存するフィールドを含めることができます。新しい注文があるたびに、この値に 1 を追加して更新します。

新しい注文は、既存の注文の数に 1 を加えたものになります。ただし、注文を削除する場合は、ソフト削除する必要があります

2. 。