更に一週間早まったiPhone 16 Proの納期。

　予想通り更にiPhone 16 Proの納期が一週間早まり、明日配達予定（ヤマト）。

　そんな気がして一昨日ケースとフィルム、デュアル充電器等を注文しておき今日届いた。

　ちなみに「配送準備中」のステップでは納期に変化はなかった。

　これだけ繰り上がるということはキャンセルまたは変更等が相当な数いるんだろう。

　思いの外「再注文したら納期が早くなった」を信じる人が（SNS上に）多い様子で驚いた。

　注文データベースの処理を図示化すると下記のような感じ。

　データベースがSQLである前提で書くと、注文データベースは、基本的にレコード（行）のdeleteは行わず、ステータスカラム（列）の値をupdateする。

　1:注文確定、2:決済エラー、3:不正注文、4:重複注文、5:キャンセル、6:保留（要対応）、7:処理中、8:配送準備中、9:配送済み

といった具合に。

　deleteを行わない理由は、注文した事実を消し去ってしまうと、「なぜキャンセルされたのか」という問い合わせに対応できなくなるから。「注文番号NNNNNの●●です」と言われても「そんな注文は存在しません」となってしまうとまずい。

　だからなぜ注文が無効化されたのかがわかるよう、「2:決済エラー」などのステータスカラムをupdateするのが基本。

　そうすることで、注文全体に占める不正注文率、重複注文率、決済エラー率、キャンセル率などの統計データを得ることができる。

　deleteがないので、よって「欠番」というものが存在しない。すなわち後から入った注文が前方の欠番を埋めるということはない。

　そこで新規注文と既に注文完了済みの人に表示される「状態」に差異（時差）がなぜ生じるのかというと、全ての顧客の問い合わせ（ステータス参照）に対し毎回データベースを読み（select）に行き全体（有効注文数）をカウント（count）してしまうと負荷がかかるため、イベント（ステップ）毎に一括更新することが多い。

　イベントとは、アップルストアでのiPhoneの注文の場合「注文確定」→「処理中」などの状態の変化を言う。まさしくステータスの更新。

　一方、新規注文に対しては、あまりにも遠い納期が表示されると注文を躊躇わせてしまい機会損失が生じるので、可能な限り最新の納期情報を表示していると思われる。

　どっちを一括、どっちを随時更新にするかは、新規注文とステータスの確認アクセスのどちらが多いかの兼ね合いで決めるのが合理的。

　といった感じ。

　小学校でエクセル、中学校でSQLを取り入れると人生とても役に立つと思うんだが。データベースとはもはや道路や水道・電気・ガス並みに社会のインフラとして稼働・活躍している。