作者 主題: 關於一個訂單編號方式  (閱讀 10359 次)

0 會員 與 1 訪客 正在閱讀本文。

godisgood

  • 憂鬱的高中生
  • ***
  • 文章數: 180
    • 檢視個人資料
關於一個訂單編號方式
« 於: 2007-06-01 09:15 »
我有一個訂單編號的方式就是日期加001 002
也就是某一個日期的第001 002,再過一天後又
再從那一天開始的001 002開始推,但我只有日期
timestamp格式,不知道該怎麼處理每天的累加部份
例如981023001 981023002然後過了一天後又重算
981024001 981024002 , 這該怎麼做處理呢

Yamaka

  • 俺是博士!
  • *****
  • 文章數: 4913
    • 檢視個人資料
    • http://www.ecmagic.com
關於一個訂單編號方式
« 回覆 #1 於: 2007-06-01 09:48 »
有好多種方式可用吧~~

例如, 建立一個類似每天歸0的計數器功能,

或是每次要建新的編號前, 都先到資料庫找今天最後一個編號, 如果找不到, 那就由 001 開始...

梁楓

  • 俺是博士!
  • *****
  • 文章數: 6220
    • 檢視個人資料
關於一個訂單編號方式
« 回覆 #2 於: 2007-06-01 10:11 »
或是每天create 一個新的table 來紀錄

ricky

  • 區域板主
  • 鑽研的研究生
  • *****
  • 文章數: 669
    • 檢視個人資料
    • Ricky 碎碎唸
Re: 關於一個訂單編號方式
« 回覆 #3 於: 2007-06-04 09:33 »
引述: "godisgood"
我有一個訂單編號的方式就是日期加001 002
也就是某一個日期的第001 002,再過一天後又
再從那一天開始的001 002開始推,但我只有日期
timestamp格式,不知道該怎麼處理每天的累加部份
例如981023001 981023002然後過了一天後又重算
981024001 981024002 , 這該怎麼做處理呢

既然你都是使用日期當訂單編號
新增訂單時的日期你應該是知道的
例如你要尋找今天最後一筆的訂單號碼
select id from bill where orderid like '981024%' order by id limit 1 desc;
如果傳回null set 就表示這是今天的第一筆訂單
如果有找到符合的set
就只要把後面的序號加1不就搞定了
我的symfony作品:YOMOpets 寵物誌
有興趣可以一起來討論symfony喔
我的部落格:http://ricky.ez2.us/

hoyo

  • 榮譽博士
  • 俺是博士!
  • *****
  • 文章數: 4047
  • 性別: 男
  • 有需要的時候,學習就不會分階段。
    • 檢視個人資料
    • 樂咖黑電腦學習網
關於一個訂單編號方式
« 回覆 #4 於: 2007-06-04 09:48 »
電腦訂單會列印出紙本嗎?
列印出之後會留存嗎?

如果以上皆非,那直接使用流水號就好了。
受人與魚,不如授人與漁
上海自來水來自海上;倫敦好奇人奇好敦倫

shengeih

  • 鑽研的研究生
  • *****
  • 文章數: 970
    • 檢視個人資料
關於一個訂單編號方式
« 回覆 #5 於: 2007-06-04 13:05 »
代碼: [選擇]

$result = mysql_query("SELECT ordserial FROM `order` WHERE ordserial LIKE '%$ordserial%' ORDER BY ordserial DESC");

if(mysql_num_rows($result) == 0) // 重新開始編號
{
    $rows['ordserial'] = "A".$TaiwanYear.date("md")."00000";    // 訂單編號        
}    
$rows = mysql_fetch_assoc($result);


$number = substr($rows['ordserial'],-5);
$Newnumber = substr($rows['ordserial'],-5) + 1;

$k = strlen($Newnumber); // 新數值長度

    $len = 5 - $k;
    for($k=0 ; $k<$len; $k++)
    {
        $counter = "0".$counter;
        $Total = $counter;
    }

$ordserial = $ordserial.$Total.$Newnumber; // new ordserial

shengeih

  • 鑽研的研究生
  • *****
  • 文章數: 970
    • 檢視個人資料
關於一個訂單編號方式
« 回覆 #6 於: 2007-06-04 13:07 »
上述所說的程式碼

用意在於做出 A96060400001 的 serial.

A : 代表號
96 : 民國
06 : 月
04 : day
00001 : Serial Number

$ordserial 就會是新的一個 Serial 可能是 A95060400001 or A95060400002....等等等

micmic3

  • 俺是博士!
  • *****
  • 文章數: 1692
    • 檢視個人資料
關於一個訂單編號方式
« 回覆 #7 於: 2007-06-04 13:49 »
引述: "shengeih"
上述所說的程式碼

用意在於做出 A96060400001 的 serial.

A : 代表號
96 : 民國
06 : 月
04 : day
00001 : Serial Number

$ordserial 就會是新的一個 Serial 可能是 A95060400001 or A95060400002....等等等

很遺憾的~.~ 這一定要做兩次 sql 一次找出 前一筆的 serial
第二次+1寫入

Darkhero

  • 酷!學園 學長們
  • 俺是博士!
  • *****
  • 文章數: 3728
  • 性別: 男
    • 檢視個人資料
    • ㄚ凱隨手紀
關於一個訂單編號方式
« 回覆 #8 於: 2007-06-04 14:00 »
以上,應該別忘了要加上 Lock Tables 的動作...

不然大量處理的時候會有嚴重的問題....

通常作法的流程是在保存訂單的同時,才產生訂單編號,
所以流程應該是
    進行 Lock Tables
    產生訂單編號
    依照訂單編號保存訂單
    進行 Unlock Tables
希望我們的討論是為了把問題解決,而不是爭論誰對誰錯.
『灌水才是重點,發文只是順便』
『我寧可讓不會釣魚的工程師餓死,也不想讓會餓死的工程師去攪沉公司....』
Blog: http://blog.darkhero.net/
秘密基地: http://www.darkhero.net/comic/
目前服務的網站: http://www.libook.com.tw/

micmic3

  • 俺是博士!
  • *****
  • 文章數: 1692
    • 檢視個人資料
關於一個訂單編號方式
« 回覆 #9 於: 2007-06-04 15:27 »
引述: "Darkhero"
以上,應該別忘了要加上 Lock Tables 的動作...

嗯...用 innodb 的 transaction  :lol:

Yamaka

  • 俺是博士!
  • *****
  • 文章數: 4913
    • 檢視個人資料
    • http://www.ecmagic.com
關於一個訂單編號方式
« 回覆 #10 於: 2007-06-05 11:30 »
引述: "micmic3"
引述: "Darkhero"
以上,應該別忘了要加上 Lock Tables 的動作...

嗯...用 innodb 的 transaction  :lol:



 :o  :o

樓主應先評估一下每天訂單產生的量吧!!

Darkhero

  • 酷!學園 學長們
  • 俺是博士!
  • *****
  • 文章數: 3728
  • 性別: 男
    • 檢視個人資料
    • ㄚ凱隨手紀
關於一個訂單編號方式
« 回覆 #11 於: 2007-06-05 13:54 »
引述: "yamaka"
引述: "micmic3"
引述: "Darkhero"
以上,應該別忘了要加上 Lock Tables 的動作...

嗯...用 innodb 的 transaction  :lol:



 :o  :o

樓主應先評估一下每天訂單產生的量吧!!


我想不管每天訂單量多少,都應該要注意這問題。

就算一天訂單只有24件... 平均一小時一件,但是也難保這24件不是在同一個10分鐘內進來的...

畢竟現在網站的流量都是隨著一天的時間而有明顯的不同,評估一天的量有時候並不能反應顛峰那一小時時所需的系統負載力跟頻寬。
希望我們的討論是為了把問題解決,而不是爭論誰對誰錯.
『灌水才是重點,發文只是順便』
『我寧可讓不會釣魚的工程師餓死,也不想讓會餓死的工程師去攪沉公司....』
Blog: http://blog.darkhero.net/
秘密基地: http://www.darkhero.net/comic/
目前服務的網站: http://www.libook.com.tw/

Yamaka

  • 俺是博士!
  • *****
  • 文章數: 4913
    • 檢視個人資料
    • http://www.ecmagic.com
關於一個訂單編號方式
« 回覆 #12 於: 2007-06-05 18:13 »
引述: "Darkhero"
引述: "yamaka"
引述: "micmic3"
引述: "Darkhero"
以上,應該別忘了要加上 Lock Tables 的動作...

嗯...用 innodb 的 transaction  :lol:



 :o  :o

樓主應先評估一下每天訂單產生的量吧!!


我想不管每天訂單量多少,都應該要注意這問題。

就算一天訂單只有24件... 平均一小時一件,但是也難保這24件不是在同一個10分鐘內進來的...

畢竟現在網站的流量都是隨著一天的時間而有明顯的不同,評估一天的量有時候並不能反應顛峰那一小時時所需的系統負載力跟頻寬。


那是當然的,

不過用  Lock Tables 應該就能夠應付了,

不需要用到 transaction 吧!!

micmic3

  • 俺是博士!
  • *****
  • 文章數: 1692
    • 檢視個人資料
關於一個訂單編號方式
« 回覆 #13 於: 2007-06-05 18:28 »
引述: "yamaka"


那是當然的,

不過用  Lock Tables 應該就能夠應付了,

不需要用到 transaction 吧!!

Lock table 有 dead lock 的風險.....

Yamaka

  • 俺是博士!
  • *****
  • 文章數: 4913
    • 檢視個人資料
    • http://www.ecmagic.com
關於一個訂單編號方式
« 回覆 #14 於: 2007-06-06 09:30 »
引述: "micmic3"
引述: "yamaka"


那是當然的,

不過用  Lock Tables 應該就能夠應付了,

不需要用到 transaction 吧!!

Lock table 有 dead lock 的風險.....



所以說要看樓主自己評估的結果了...

要不然, 就如 hoyo 大大的建議, 直接使用流水號就好了..