私の考えでは、shop shop はショップ情報を保存するために使用されるテーブルです。 次に、フィールド shop_id を持つトランザクション テーブルがあり、すべてのショップのトランザクション レコード情報が保存されます。
このようなテーブル設計は、データ量が多い場合に影響しますか? もっと良い方法はありますか? 例えば、各店舗の取引記録はテーブルですが、動的に店舗を追加できるため実装が難しく感じます。
Mysql は、数千のレコードでも同様に実行できますが、ストアに平均 10 件の注文がある場合、ストアと注文のデータは 10 回マッピングされ、注文数が非常に多い場合はパフォーマンスに影響します。 。データベース テーブルを動的に追加することもできます。したがって、注文レコードに対してサブテーブル処理を実行できます。ただし、自動インクリメントされた shop_id を外部キーとして使用することはできません。テーブルを分割すると、自動インクリメントされた ID ベースが 0 に戻るためです。たとえ手動で設定できたとしても、非常に不便なので、そうするのが最善です。外部キーを自分で生成して、テーブルの分割を容易にします。一意の ID を生成するにはさまざまな方法があり、自分で設計することもできます。
上で述べたことを訂正します。実際、私は開発中に外部キーをほとんど使用しません。なぜ開発中に外部キーの使用を避けるべきなのかを考えてみることをお勧めします。
Mysql は、数千のレコードでも同様に実行できますが、ストアに平均 10 件の注文がある場合、ストアと注文のデータは 10 回マッピングされ、注文数が非常に多い場合はパフォーマンスに影響します。 。データベース テーブルを動的に追加することもできます。したがって、注文レコードに対してサブテーブル処理を実行できます。ただし、自動インクリメントされた shop_id を外部キーとして使用することはできません。テーブルを分割すると、自動インクリメントされた ID ベースが 0 に戻るためです。たとえ手動で設定できたとしても、非常に不便なので、そうするのが最善です。外部キーを自分で生成して、テーブルの分割を容易にします。一意の ID を生成するにはさまざまな方法があり、自分で設計することもできます。
私の理解では、ショップ テーブルとトランザクション テーブルを設計するということです。トランザクション テーブルの外部キーはショップ テーブルの主キーです。一般に、MySQL は多くの負荷に耐えることができ、一部のオープンソースを使用できます。解決策、つまり順序テーブルが通常のテーブルに分割され、キーは実装方法によって異なります。
上で述べたことを訂正します。実際、私は開発中に外部キーをほとんど使用しません。なぜ開発中に外部キーの使用を避けるべきなのかを考えてみることをお勧めします。