Re: [SQL ] 關於UPDATE大量資料
: 同狀況的另一個痛是顯示地址…目前都是在存的時候順便存一個兜起來的地址。
: : 前端的部分不是問題 jsp+js都能克服
: : 現在卡在SQL的UPDATE不確定怎麼做才是最好的
: : 我有個想法是 當程式偵測到消費者資料有需要更新的時候
: : 先將地址資料刪除(除了消費者資料是用UPDATE)
: : 然後再新增新地址的資料
: : 例如:
: : 舊消費者資料 舊消費者地址 ->偵測到異動消費者資料 ->
: : UPDATE 消費者TABLE ,DELETE 舊消費者地址 ,INSERT新消費者地址。
: : 簡單說每次異動地址都會刪除再新增。
: : 想請問一下這樣做會有缺點嗎?
: : 還是真的完全不建議這麼做?
: update本來就等於 delete再 insert；
: 真要說缺點…只想到沒有包交易，可能刪了沒新增，效率不會差太多
: 不過，感覺就是怪怪的 囧a
: 我只有匯資料才會用這種作法，省掉判斷該 insert還是 update，
: 一般維護程式很容易可以區分該新增還是修改…
: : 如果真的不建議這樣的方式 就只能花苦功慢慢update
: 能解決問題的方式都好，有多種方式再來研究哪個好。
: 這個狀況我想不到用 delete..insert能省到什麼工？
: 欄位不都要一個一個 key嗎？請指教。
: : 感謝
如果使用TRANSACTION這是沒什麼大缺點
就程式看起來迂迴
如果說這樣有什麼好處 我猜可能是Insert SQL已經寫過一次
直接拿來套用就好 省了一些工
其實UPDATE SQL長長的一串 是很常見的事
建議可以寫一個SQL語法的產生器 產生的SQL不一定要完整
能達到省力的效果就好
寫程式苦工本來就很多
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.133.52.38
→
06/21 00:34, , 1F
06/21 00:34, 1F
推
06/21 01:43, , 2F
06/21 01:43, 2F
推
06/21 02:09, , 3F
06/21 02:09, 3F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 3 之 4 篇)：