0

カート購入データモデルを作成しようとしています。クレジットや製品など、ユーザーが購入できるものはさまざまです (それぞれに個別の属性セットがあります)。トランザクションが正常に完了すると、各アイテムの購入がテーブルに保存されます (それぞれクレジットと購入など)。

私が知りたかったのは、ユーザーがトランザクション中にどのアプローチに従うべきかということです (アプローチには長所と短所が記載されています)

ユーザーが項目に対して選択した属性を一時テーブル (temp_credit_purchases や temp_product_purchases など) に保存し、そのレコードを実際のテーブル (クレジットと購入) に挿入します。

長所

  • 失敗したすべてのトランザクションを削除することができ、実際のテーブルに自動インクリメントされた ID が欠落することはほとんどありません。

短所

  • 2 回の挿入と 1 回の選択 - 挿入は更新よりも重い (これは 2 番目のケースで発生する)

一時的な状態で実際のテーブルにデータを挿入します

長所

  • より最適 (1 回の挿入と 1 回の更新のみ)

短所

  • テーブルには、他のユーザー向けモジュールでクエリを実行するために使用される不要な行が大量に存在します (これにより、クエリが遅くなる可能性があります)。

各アプローチの長所と短所を列挙することはできますが、決定的な決定を下すことはできません。これについて考えるのを手伝ってください。

4

1 に答える 1

1

一時的な状態を持つ注文にリンクされた実際のテーブルにデータを保存します。定期的に、注文とリンクされた購入が X 時間以上経過しており、注文が完了していない場合、これらは消去される可能性があります。

インデックス付きテーブルに余分な行があっても、クエリが大幅に遅くなることはありません。とにかく定期的にそれらをクリーンアップします。もちろん、注文が完了しなかったという事実が重要であり、これらの行を保持して、「人々が最も頻繁に気が変わった製品」などの指標を提供したい場合を除きます。

心に留めておいてください：

  • 自動インクリメント ID のギャップは、行が一意であり、実際にはデータではないことを確認するためだけに設計されているため、心配する必要はありません。
  • 一般に、エンティティの品質 (注文が完了したかどうか) を、似たようなもののテーブルを 2 つに分割することによって表現したくはありませんが、代わりにフィールドをどこかに追加することができます。
于 2012-07-25T15:02:25.340 に答える