看板 Soft_Job
作者 mgtsai ()
標題 Re: [請益] 資料庫的參考完整性限制
時間 Sat Feb  9 13:38:51 2013


: --
: ※ 發信站: 批踢踢實業坊(ptt.cc)
: ◆ From: 59.105.83.207
: 推 SansWord:舉例: 身分證字號是我們的PK, (單一欄位 PK)              02/09 11:55

雖然很多系統的實作,會以身分證字號當作 PK
甚至很多資料庫類的書籍,都會以 PK 設為身分證字號當作範例講解

但在實務上,身分證字號其實並不適合當成 PK
真的有心要做一個系統,要避免以身分證字號當作 PK

因為存在極少數的案例,身分證字號有發生重覆的狀況
這是因為在古早以前戶政資料尚未電腦化的時代

在報戶口給身份字號時,全都是以人工作業
這時就難免會產生疏漏,發生重覆給號的狀況
而這種狀況實在難以人工的方式查核
直到戶政資料電腦化後,這種給號重覆的狀況才得以解決

但因之前的已經重覆的身份証字號,由於當事人甚至已使用了數十年之久
也使用在眾多其它的系統
即使電腦可以清查出有哪些重覆的字號
除非當事人自己申請更改,願意跑那些繁複的變更流程
(不只是戶政單位要處理,所有用到身份證字號的單位都要處理
包含與個人財務切身相關的金融相關的資料,各公私立銀行的戶頭等都要一併處理)

所以以戶政事務所的立場,不會主動幫當事人辦理這些手續
而是要當事人自己提出申請,才予以辦理
故直到今日,仍然存在許多身份證字號重覆的案例

因為這是目前實務上的現實狀況
所以,在系統的實作上,最好還是避免將身分證字號作為 PK
無論是身分證字號重覆,就是有其它特殊理由使用者變更身分證字號
亦或是某使用亂填身分證字號,剛好與另一個新註冊的使用者重覆
而新使用者客訴並驗明正身自己才是這個身分證字號的本尊

這些案例都會使以分證字號作為 PK 的系統,變得難以處理

除非你所寫的系統是玩具,不打算讓這些少數個案使用



--
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.32.58.129
※ 編輯: mgtsai          來自: 114.32.58.129        (02/09 13:56)
astt88:在我的經驗中也同樣遇到過這類事情,非常同意同篇1F 02/09 13:59
lance70176:聽過兩次這個案例 在市警局資訊處一次 只能申請變更
而且通常重複的身分證字號 有一個都會是老人2F 02/09 15:28
robler:會重複都是很久以前發生的,不是老人才奇怪吧XD4F 02/09 15:42
mgtsai:其實重覆的事比想像中常發生,畢竟戶政系統電腦化不到三十年換句話說,在三十歲以上的族群,就有存在字號重覆的狀況
而三十歲以上,剛好又是目前的社會中堅,故偶而會聽到案例倒不一定只有老人才會發生
剛查了一下資料,戶政電腦化至1997年才完全推廣至全國
由1993年第一階段至1997年第三階段,花了四年時間
而1985年至1993年只在台北市中山區與台北縣新店市試辦
從開始試辦至今,只有 28 年5F 02/09 16:07
astt88:其實我姊姊就有換過身份證字號
我姊姊發現銀行帳號,明明沒有領錢,錢卻無緣無故的被領走後來銀行查出,原來是因為身份證字號與別人重覆了
後來因為我姊姊較年輕,所以是我姊姊申請換身份證字號
現在我姊姊也才30幾歲
所以我才說身份證字號也是有可能會重覆的,不建議當 PK13F 02/09 16:28
Abbee:以我的經驗是,現在很多外配,當他們拿到身份證後,你就要改
資料,有的人db用id當key,就會改得得辛苦19F 02/09 17:59
andymai:換過身份證字號+1 不過這說來也不合理~本來身份證號碼就該是"唯一"~重覆的話~本來就該進行協調處理~要不然不是會一直有人為了重覆而困擾嗎?當事人應該要有自覺!!!
之前也遇過很多類似的事~本來應該是合理的東西~卻因為"人"而不得不變成special case~甚至當成"本來就這樣"~真是傻眼21F 02/09 18:38
Adonisy:身份證本來就不能當 pk26F 02/09 19:01
astt88:系統真正在跑後,有些理論上不會有問題,
但就是有些見裡的例外情況跑出來
就有是見鬼的例外情況跑出來,客戶說要改資料還是要改給他我只是一個小小的程式打字工,沒有這骨氣說不改
我想這情況在有DBA的地方,應該是由DBA來改吧27F 02/09 19:13
iFEELing:DBA:這是資料面的事 請 programmer 自己想辦法32F 02/11 02:37
f1234518456:DBA:我不就是你嗎?33F 02/11 08:16
astt88:因為我遇到很多SQL下得很普通或很奇怪的PG
有些時候會沒有Update好資料,造成資料錯亂
個人是,凡是直接下SQL的作業,都會很小心
做完都會檢查資料,及測試程式
因為若有錯的話,等發現後再來改,絕對非常麻煩
當然了,還是要視時程規劃來做,若沒有時間也只好賭他沒事或許要賭都有把該做的事都做完且做好,那也OK
客戶跟老闆都要你下好離手,也只好賭了34F 02/11 09:55
FLAMEDDD:推一個,長知識了!42F 02/14 22:30
evenfall:推一個  實用!43F 02/19 14:24

--
--
(mgtsai.): Re: [請益] 資料庫的參考完整性限制 - cukebox板