Re: [討論] 來點勁爆點的好了...

看板consumer作者 (此方不可長)時間15年前 (2009/07/10 21:10), 編輯推噓10(10推 0噓 16→)
留言26則, 9人參與, 最新討論串3/4 (看更多)
: → gorhow:你的推測完全沒道理吧 頂多是單號重覆 資料不會不見 07/10 21:02 編號怎麼來? 肯定有個東西在負責紀錄順序,總不會是隨機產生的 如果已經有個資料庫在紀錄每一筆訂單的資料, 那這個資料庫兼紀錄順序是很合理的對吧? 如果說你要不到紀錄順序而變成TW0000-0000-00100, 推測資料庫掛了也是合理的吧? 那,資料庫如果掛了,那這段期間的訂單沒有寫進去也是有可能的對吧.... 好,就算掛一半, 那是不是也可能通通寫到 00100 這筆? (只剩下最後一筆使用00100的人的紀錄) 最好的狀況是有一堆編號00100的人的單存在資料庫裡面.... 當然不是沒可能....但我懷疑...... ------- 簡單猜測一下: 001xx = 第一筆訂單, xx是一個隨機號之類的 002xx = 第二筆訂單, 類推 所以一個 TW0000-000x 可以紀錄 1000 筆訂單, 而當天大概是從 TW0000-346x 跑到 TW0000-350x 基本上剛好吻合那天跑了四萬多單的紀錄 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.132.126.29
推
07/10 21:11, , 1F
這邊整理一下可以貼去八卦了~哈哈
07/10 21:11, 1F
推
07/10 21:16, , 2F
你到底有沒修過資料庫阿?
07/10 21:16, 2F
你想說什麼就發一篇來看一看好嗎? ※ 編輯: wahaha99 來自: 220.132.126.29 (07/10 21:17)
推
07/10 21:17, , 3F
姑且不論推測正確否~其實00100單號有重複是事實
07/10 21:17, 3F
→
07/10 21:18, , 4F
資料有損失或是重複或許是必然的~
07/10 21:18, 4F
推
07/10 21:22, , 5F
先去唸唸資料庫 了解資料庫functionality T%#$^$%^
07/10 21:22, 5F
呵,唸過資料庫的人卻不願意說說哪邊有問題? 你要是知道哪邊的分析有問題就明說, 不要浪費大家時間 ※ 編輯: wahaha99 來自: 220.132.126.29 (07/10 21:23)
→
07/10 21:23, , 6F
編號也不見得是資料庫給的 可能是前端的程式指定
07/10 21:23, 6F
不見得,是啊,但如果是我寫,我會放在資料庫啊,不然剛好同時有很多request,前端程式 來不及反應造成編號重複怎麼辦? 這可是web app
→
07/10 21:23, , 7F
如果不符合constraint 根本不應該寫入
07/10 21:23, 7F
TW0000-0000-00100 不會不符合啊 ※ 編輯: wahaha99 來自: 220.132.126.29 (07/10 21:27)
推
07/10 21:28, , 8F
既然符合資料就不會不見
07/10 21:28, 8F
我還真不明白為什麼一定不會寫到同一筆TW0000-0000-00100去 如果新的蓋掉舊的,那就是不見啦 這個no.有沒有可能拿來當做 unique ID? 當然有可能, sales查單應該都是用這個來查以外,誰會想到一個no.會有這麼多張單? (恐怕輸入no.,後台系統只能顯示第一張) ===== 也不一定是資料庫掛掉,也可能是中繼程式掛掉,所以才會會去要到00100 (不然一般SQL error message就直接跳出來了) 但結論是一樣的
→
07/10 21:34, , 9F
不是要先看資料庫那一個為主要自動遞增,假如不是停單
07/10 21:34, 9F
※ 編輯: wahaha99 來自: 220.132.126.29 (07/10 21:35)
→
07/10 21:35, , 10F
序號,那麼訂單序號重覆也無關係吧,且假假如是訂單序號
07/10 21:35, 10F
→
07/10 21:35, , 11F
那麼訂單序號跑一圈了,再從0開始,應該會出錯吧~(重覆)
07/10 21:35, 11F
推
07/10 21:36, , 12F
它可以亂數產生再做記錄就好了咩= =
07/10 21:36, 12F
→
07/10 21:37, , 13F
回歸主題..DE//鄉民的LCD及NB呢?
07/10 21:37, 13F
推
07/10 21:42, , 14F
還寄放在呆鵝那!!
07/10 21:42, 14F
→
07/10 21:44, , 15F
感覺從消費者版變成 -> 戴爾版又變成 -> 資料庫版了 ˇˇ
07/10 21:44, 15F
推
07/10 22:09, , 16F
gorhow說不會不見的意思是..新增資料(訂單)是用insert指令
07/10 22:09, 16F
→
07/10 22:10, , 17F
如果要能蓋過舊資料,那要用update去更新舊有的資料..
07/10 22:10, 17F
→
07/10 22:11, , 18F
這兩個是完全不同的東西,正常來說,也不可能那麼無聊,還故
07/10 22:11, 18F
→
07/10 22:12, , 19F
意去用update去蓋舊資料.而且如果訂單號被設成unique的話
07/10 22:12, 19F
→
07/10 22:12, , 20F
那麼直接連寫都寫不進DB,所以重覆訂單的事不會發生..
07/10 22:12, 20F
這是直接從SQL的角度去想,但我就是覺得程式有中繼過啊 如果寫程式的人很偷懶,這樣寫: ==== IF 已存在unique的no, SQL下update , else SQL下insert ==== 然後從web吃到後台都吃這個中繼程式,你覺得會怎樣.... x_x 之前全站折7000都能發生,什麼爛code不會有.... XD
推
07/10 22:14, , 21F
反正如果這個再被挖出來~~肯定又是呆鵝一擊重傷\
07/10 22:14, 21F
※ 編輯: wahaha99 來自: 220.132.126.29 (07/10 22:20)
推
07/10 22:34, , 22F
............ 為什麼你要這樣寫.........
07/10 22:34, 22F
→
07/10 22:35, , 23F
如果是因為偷懶導致寫錯還有可能..為什麼要多費工去寫一個
07/10 22:35, 23F
→
07/10 22:35, , 24F
顯然是錯的程式 orz
07/10 22:35, 24F
→
07/10 22:39, , 25F
不就是在說偷懶寫錯的 XD
07/10 22:39, 25F
→
07/10 22:40, , 26F
也不能說錯,只要產生no.的程式不出錯也沒問題
07/10 22:40, 26F
‣ 更多 wahaha99 的文章
文章代碼(AID): #1ALpspfl (consumer)
‣ 更多 wahaha99 的文章
文章代碼(AID): #1ALpspfl (consumer)