中華電信 iPhone4s 資費

[AnthonySun]

14217...這是真的嗎？
不知有無機會快拿到.....**"

[odin1in]

對於資料庫來說 order_id 就是唯一判斷此訂單的unique 值

所以一定不會重複，而且 你可以試試多新增幾筆 你會發現這個值是auto increment

[lonestar]

如果屬實的話，提供一下我的好了
13:14分是42863
13:15分是72397

當然，如果就iphone4來說
選16gb或是32gb，即便預約時間一樣，拿到的時間差很大！
今年又多了64gb
我想應該會更複雜一點吧…

[leader0099]

我有兩筆預約在13:14及13:17
排序是34xxxx及36xxxx

我的是13:53:46...31979
13:57:42...38703
差了6724號..........真的是這樣排法嗎??怎感覺怪怪的~~!!

[Leif Wang]

我12/2下午1:18簡訊預約.排13萬多.哇嗚~熱血霎時跌到急凍

我也查了一下,我是11:23分,排名7793~ QQ
感動,應該在第一波了～ 開心

[minjoeyi]

對於資料庫來說 order_id 就是唯一判斷此訂單的unique 值

所以一定不會重複，而且 你可以試試多新增幾筆 你會發現這個值是auto increment

對於撰寫過資料庫的人應該都有概念，對於系統來說登入的行為或是 click submit 的action都可能會給一組序號當作number，有可能是給資料庫當作唯一碼(主值判斷)來記錄，但是這組號碼就是等於"iPhone預購的訂單序號"中間有太多的gap...

就如我剛剛問了中華電信的人，目前簡訊加網路預購總共統計才8萬多人，對比data[orders_tmps][orderId] 後value大於此值一個order的比比皆是，這明顯是資料庫用來紀錄網路登入或click submit次數(不一定有按submit就成功喔)的計算編號增值而已...當然不會重複...

目前看起來這方法都傳的很開，很多網站都認為這就是判斷訂單序號的方法，藉以評估預購排不排的到的可能性....這有點太扯了...

[odin1in]

您說click submit 不成功，那資料庫何來新增的值？

[minjoeyi]

您說click submit 不成功，那資料庫何來新增的值？

submit後sql塞值到database，但db在下一步傳值可能因server overloading問題造成value submit到下一個網頁失敗~
不然出現幾十萬的數值如何解釋?

畢竟成功的預訂行為才8萬多筆...表示中間很多無效的value

所以我還是認為這只是各筆data的primary key而已，對使用者沒有特殊意義~

[odin1in]

order_id 不一定代表筆數
但一定是預購者的先後

[minjoeyi]

order_id 不一定代表筆數
但一定是預購者的先後

以成功預購人數當作8萬人為例，如果orderId是九萬多，是要判斷先後呢，還是判定排不到....因為中間有太多無效的PK，造成orderId累增到無法判斷先後...

再者，就如您所言:
"...進入查詢頁 按打開原始碼 搜尋 data[orders_tmps][orderId] 就知道你在"網路預購"排第幾了。"

"排第幾"這判斷法可著實嚇到不少人，因為看到上萬的號碼會以為預購白搭..第一波沒有機會... -_-|||