注文を処理するためにデータベースを構築する 2 つの方法の間で迷っています。ある方法が別の方法よりも速いかどうかはわかりません。それらが等しくなる場合は、おそらく問題にならないはずですよね?
これがオプション＃1です。
orders
-------
id
timestamp
userID
cartID
reviewed
approved
reviewBy
reviewTimestamp
reviewDetails
processed
processedBy
processedTimestamp
processedDetails
オプション #2:
orders
-------
id
timestamp
userID
cartID
reviewID
processID
reviews
-------
id
timestamp
status
reviewerID
details
processing
----------
id
timestamp
processorID
details
みんなありがとう！
スピードだけでなく、機能性も重視します。それがあなたを制限しすぎて役に立たないのであれば、それが速いかどうかは誰が気にします. たとえば、注文を 2 回確認したい場合 (最初に何かを拒否した場合) はどうでしょうか。または、注文を 2 つの部分に分けて処理するとどうなりますか? これらのいずれかの倍数を本当に決して持たないビジネスケースがない限り、2番目のオプションをお勧めします.
また、逆もまた真である可能性があることを忘れないでください。たとえば、1 人の担当者が一度に 3 つの注文を処理する場合があります。または、一度に 3 つの注文を承認する場合もあります。これらは現在起こっていないかもしれませんが、将来を評価する必要があります。データベース モデルが自分と自分のユース ケースで機能することを確認してください。
最後に、疑問がある場合は、通常、拡張可能なモデルを選択します。データベース構造が正規化されすぎていると自問自答することはめったにありません (やり過ぎではありません)。 （現在は変更されています）サポートするはずのユースケース。
速度に関する限り、結合が多いほど遅くなります。ただし、データベースが非常に大きい場合を除き、大規模な速度の問題について話しているわけではありません。インデックスを適切に作成すれば、ほとんどの場合、違いに気付かないでしょう。
複数のテーブルを使用する場合、適切なインデックスを作成する限り、パフォーマンスの違いはごくわずかです。
正規化されたモデルを使用します。レビューと処理が注文で多対 1 の場合は、オプション 2 を使用します。レビューと処理が注文で 1 対 1 の場合、データの読み取りと書き込みの両方でオプション 1 を使用する方が簡単な場合があります (例: 1 回の挿入と 3 回の挿入)。