Re: [請益] 資料庫的參考完整性限制

看板Soft_Job作者時間13年前 (2013/02/09 13:38), 編輯推噓13(13推 0噓 30→)
留言43則, 11人參與, 最新討論串6/7 (看更多)
: -- : ※ 發信站: 批踢踢實業坊(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)
推
02/09 13:59, , 1F
在我的經驗中也同樣遇到過這類事情，非常同意同篇
02/09 13:59, 1F
推
02/09 15:28, , 2F
聽過兩次這個案例 在市警局資訊處一次 只能申請變更
02/09 15:28, 2F
→
02/09 15:28, , 3F
而且通常重複的身分證字號 有一個都會是老人
02/09 15:28, 3F
→
02/09 15:42, , 4F
會重複都是很久以前發生的，不是老人才奇怪吧XD
02/09 15:42, 4F
→
02/09 16:07, , 5F
其實重覆的事比想像中常發生,畢竟戶政系統電腦化不到三十年
02/09 16:07, 5F
→
02/09 16:08, , 6F
換句話說，在三十歲以上的族群，就有存在字號重覆的狀況
02/09 16:08, 6F
→
02/09 16:10, , 7F
而三十歲以上，剛好又是目前的社會中堅，故偶而會聽到案例
02/09 16:10, 7F
→
02/09 16:10, , 8F
倒不一定只有老人才會發生
02/09 16:10, 8F
→
02/09 16:20, , 9F
剛查了一下資料，戶政電腦化至1997年才完全推廣至全國
02/09 16:20, 9F
→
02/09 16:21, , 10F
由1993年第一階段至1997年第三階段，花了四年時間
02/09 16:21, 10F
→
02/09 16:23, , 11F
而1985年至1993年只在台北市中山區與台北縣新店市試辦
02/09 16:23, 11F
→
02/09 16:23, , 12F
從開始試辦至今，只有 28 年
02/09 16:23, 12F
推
02/09 16:28, , 13F
其實我姊姊就有換過身份證字號
02/09 16:28, 13F
→
02/09 16:28, , 14F
我姊姊發現銀行帳號，明明沒有領錢，錢卻無緣無故的被領走
02/09 16:28, 14F
→
02/09 16:28, , 15F
後來銀行查出，原來是因為身份證字號與別人重覆了
02/09 16:28, 15F
→
02/09 16:29, , 16F
後來因為我姊姊較年輕，所以是我姊姊申請換身份證字號
02/09 16:29, 16F
→
02/09 16:29, , 17F
現在我姊姊也才30幾歲
02/09 16:29, 17F
→
02/09 16:32, , 18F
所以我才說身份證字號也是有可能會重覆的，不建議當 PK
02/09 16:32, 18F
→
02/09 17:59, , 19F
以我的經驗是,現在很多外配,當他們拿到身份證後,你就要改
02/09 17:59, 19F
→
02/09 18:00, , 20F
資料,有的人db用id當key,就會改得得辛苦
02/09 18:00, 20F
→
02/09 18:38, , 21F
換過身份證字號+1 不過這說來也不合理~本來身份證號碼就該
02/09 18:38, 21F
→
02/09 18:39, , 22F
是"唯一"~重覆的話~本來就該進行協調處理~要不然不是會一
02/09 18:39, 22F
→
02/09 18:40, , 23F
直有人為了重覆而困擾嗎?當事人應該要有自覺!!!
02/09 18:40, 23F
→
02/09 18:42, , 24F
之前也遇過很多類似的事~本來應該是合理的東西~卻因為"人"
02/09 18:42, 24F
→
02/09 18:44, , 25F
而不得不變成special case~甚至當成"本來就這樣"~真是傻眼
02/09 18:44, 25F
推
02/09 19:01, , 26F
身份證本來就不能當 pk
02/09 19:01, 26F
推
02/09 19:13, , 27F
系統真正在跑後，有些理論上不會有問題，
02/09 19:13, 27F
→
02/09 19:14, , 28F
但就是有些見裡的例外情況跑出來
02/09 19:14, 28F
→
02/09 19:16, , 29F
就有是見鬼的例外情況跑出來，客戶說要改資料還是要改給他
02/09 19:16, 29F
推
02/09 19:39, , 30F
我只是一個小小的程式打字工，沒有這骨氣說不改
02/09 19:39, 30F
推
02/09 19:43, , 31F
我想這情況在有DBA的地方，應該是由DBA來改吧
02/09 19:43, 31F
→
02/11 02:37, , 32F
DBA:這是資料面的事 請 programmer 自己想辦法
02/11 02:37, 32F
推
02/11 08:16, , 33F
DBA:我不就是你嗎?
02/11 08:16, 33F
→
02/11 09:55, , 34F
因為我遇到很多SQL下得很普通或很奇怪的PG
02/11 09:55, 34F
→
02/11 09:56, , 35F
有些時候會沒有Update好資料，造成資料錯亂
02/11 09:56, 35F
推
02/11 09:58, , 36F
個人是，凡是直接下SQL的作業，都會很小心
02/11 09:58, 36F
→
02/11 09:59, , 37F
做完都會檢查資料，及測試程式
02/11 09:59, 37F
→
02/11 10:00, , 38F
因為若有錯的話，等發現後再來改，絕對非常麻煩
02/11 10:00, 38F
→
02/11 10:01, , 39F
當然了，還是要視時程規劃來做，若沒有時間也只好賭他沒事
02/11 10:01, 39F
推
02/11 10:05, , 40F
或許要賭都有把該做的事都做完且做好，那也OK
02/11 10:05, 40F
推
02/11 10:47, , 41F
客戶跟老闆都要你下好離手，也只好賭了
02/11 10:47, 41F
推
02/14 22:30, , 42F
推一個，長知識了！
02/14 22:30, 42F
推
02/19 14:24, , 43F
推一個 實用!
02/19 14:24, 43F
‣ 更多 mgtsai 的文章
文章代碼(AID): #1H5U3jRo (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 6 之 7 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共7篇)
‣ 更多 mgtsai 的文章
文章代碼(AID): #1H5U3jRo (Soft_Job)