Re: [SQL ] 邏輯上的問題 請不吝賜教

看板Database (資料庫)作者 (格物致知 溫故知新)時間12年前 (2013/01/09 23:53), 編輯推噓8(8016)
留言24則, 3人參與, 最新討論串3/3 (看更多)
如果有重複資料 你該做的是正規化才對,設計就有問題了 或者在使用到外鍵的table的定義加入更新異常的處理方式 我記得是有預設值、null值、禁止、連動修改 ※ 引述《horcy (HC)》之銘言: : 小弟與同事再編寫SQL的update時,會有兩種寫法。 : 但對我的程式而言,因為只需要更新姓名及地址, : 所以常常都沒有注意到會不會有邏輯上的錯誤, : 今天跟同事討論,才聽同事說我的寫法1, : 有邏輯上的問題,許多地方不能這樣用。 : 以下是兩個範例表格(環境為MsSQL server) : EmpSal 員工薪資 有可能位有重複資料。 : name 姓名 : address 地址 : idno 身分證號 : recoid 流水號(key) 與Emp_Old無關 : Emp_Old 員工資料 是Views,經過設計,絕對不會有重複。 : name 姓名 : address 地址 : idno 身分證號 : recoid 流水號(key) 與EmpSal無關 : 以下是我說的兩種寫法 : 寫法1. : update EmpSal set address=a.address, name=a.name : from Emp_Old a : where Emp.idno=a.idno : 寫法2. : update update EmpSal set address=a.address, name=a.name : from EmpSal e inner join Emp_Old a on e.idno=a.idno : 同事的說法是,只要寫法1產生出兩個表格都會有重複值的情況,就有可能會出錯。 : 比方說,某個職員有兩個身分,需要兩筆資料,就有可能寫出錯誤的結果。 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 多值屬性照理說要分割成另一個表格。 不然一定會有參考完整性的問題.. 感覺上這麼會開出怎麼特殊的table,這樣設計是有特別的作用嗎?@@ : 可是我的觀念是,怎麼join就怎麼where不就好了? : 因為實際經驗只限於常操作的幾個表格, : 所以常常會有盲點,希望各位能夠幫我指出盲點。 : ps.我很對不起我以前的老師,我上課都在打混.. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 203.70.75.157

01/10 02:57, , 1F
這種表,出去工作之後就會看多了.... orz
01/10 02:57, 1F

01/10 02:58, , 2F
總覺得教科書上的講的設計方法..... 像理想鄉一樣....
01/10 02:58, 2F

01/10 03:18, , 3F
並不是理想...
01/10 03:18, 3F

01/10 09:16, , 4F
原本是職員一個代號 老師一個代號 職員下班兼課 就兩個代號
01/10 09:16, 4F

01/10 09:17, , 5F
原本系統的規劃就是一個人一個身分 職務代號也沒有規劃到這
01/10 09:17, 5F

01/10 09:18, , 6F
對系統而言 這是兩個人 功能有所區隔 但實際上是同一人
01/10 09:18, 6F

01/10 09:18, , 7F
就像遊戲公司的GM也會有兩個帳號一樣 身分功能不同所致
01/10 09:18, 7F

01/10 09:20, , 8F
或者說 一個老師退休後回來兼課 會出現一帳號停用 一兼任
01/10 09:20, 8F

01/10 09:21, , 9F
因為最初建置系統的人員 不是資訊背景 所以資料庫沒規劃完整
01/10 09:21, 9F

01/10 09:23, , 10F
幾十萬筆資料 沒人敢說重建資DB 重新正規化 何況還有程式端
01/10 09:23, 10F

01/10 09:24, , 11F
現在是一邊要改舊的程式 還要一邊開發新的程式
01/10 09:24, 11F

01/10 09:26, , 12F
甚至有人在肖想要我們開發新系統 殺了我比較快...
01/10 09:26, 12F

01/10 09:26, , 13F
我竟然在這裡抱怨 真是不好意思.....
01/10 09:26, 13F

01/10 09:30, , 14F
因稅務轉出資料要保留當年度資料完整 這種時候真的挺尷尬的
01/10 09:30, 14F

01/10 09:44, , 15F
推樓上.....
01/10 09:44, 15F

01/10 09:55, , 16F
你樓上我 就是原原PO
01/10 09:55, 16F

01/10 10:31, , 17F
這不就只是緩時變維度的其中一型而以啊....
01/10 10:31, 17F

01/10 10:59, , 18F
查了一下 差不多吧 但因為我很對不起我的老師及我的父母
01/10 10:59, 18F

01/10 11:00, , 19F
所以我不會用 現在了解一點 下次有機會來嘗試看看
01/10 11:00, 19F

01/10 11:01, , 20F
我們的做法是用其他欄位來做相同的結果 比較土法煉鋼一點
01/10 11:01, 20F

01/10 11:03, , 21F
像yrmon做年月戳記 以idno作為商業索引鍵
01/10 11:03, 21F

01/10 11:04, , 22F
可能是我給的例子太爛 才會給大家一種誤會 其實還有其他欄位
01/10 11:04, 22F

01/10 11:06, , 23F
其實我有點混亂了 回A版友是指原案例有更多其他欄位
01/10 11:06, 23F

01/10 11:07, , 24F
回i版友是指 我們會重複資料的原因
01/10 11:07, 24F
文章代碼(AID): #1GxP9W0- (Database)
文章代碼(AID): #1GxP9W0- (Database)