マイナンバーは原則別テーブル、他テーブルでは主キーにできず、JOIN注意

「マイナンバーのテーブルでの持ち方がわからない。
　合法的にはどう持てば、削除しても大丈夫なのか？」

と聞かれたので、こんな風に答えました。

---

■マイナンバーは原則別テーブル、他テーブルでは主キーにできない

マイナンバーは、目的外には使えません。
ということは、従業員マスターの主キーなどにしてしまうと（一意で便利なんだけど・・・）
従業員マスターを税務・年金以外の他の目的（人事評価や飲み会の参加者名簿など）に使うことが出来ません。

ということは、マイナンバーは原則別テーブルで持ち、必要時にJOINすることになります。

---

■外部キーにする場合JOIN注意

ということは、実際にJOINする場合

従業員マスタ　　　　　従業員ID、従業員氏名・・・
マイナンバーマスター　マイナンバー、従業員IDとなり、

SELECT 従業員マスタ.*,マイナンバーマスター.マイナンバー
FROM 従業員マスタ
LEFT JOIN マイナンバーマスター
　　　　ON 従業員マスタ.従業員ID=マイナンバーマスター.マイナンバー

と（この場合）LEFT JOINにすることが基本だと思います。

というのも、マイナンバーは、退職した場合、削除しなければなりません。
従業員マスターは、過去データを扱う
（例えば、２０１０年度～２０１４年度の新入社員一覧を出すなどという場合）
こともあるので、データは削除していないかもしれません。

ここで、INNER JOINをしてしまうと、マイナンバーマスタに無い人が消えて
しまいます（例えば、２０１１年度入社、２０１３年退社の人は、そもそも
マイナンバーテーブルに登録されていないので、INNER JOINしてしまうと、
２０１１年度の新入社員から、この人は抜けてしまう）。

その場合、NULL値はどうするかは・・・時々で考えるということですね
(ケースバイケース）
・・・ということは、マイナンバーが必要な場合は、そのSQLは、一応考えないと
いけないということですね（というか、SQLを作成するときは、本やWebから
切り貼りするのではなく、一応、考えてくださいね。マイナンバーの場合に限らず！）

---

■扶養家族まで考えると・・・NoSQL?正規化くずし？別テーブル？

マイナンバーは、扶養家族まで必要になります。

http://www.nta.go.jp/mynumberinfo/pdf/gaiyo.pdfより引用
ということは、扶養家族のデータをもたないといけない・・・のですが、
扶養家族は何人いるかわかりません。

正規化する場合、マイナンバーテーブルとは別テーブルになります。

それがめんどくさければ、マイナンバーテーブルに、扶養家族リストというのをもって、
（扶養家族マイナンバー，扶養家族名）・・・繰り返し・・・
というデータ項目を持つか、いっそのこと、KVSなどのNoSQLにするか・・
（これらのばあい、途中の扶養家族を削除、修正する場合大変かも？）

ということになります。

---

じつは、このあと、「複数の顧客がクラウド（Amazon VPC）にマイナンバーテーブルを持った場合、税理士さんは・・・」ということで、とんでもない！話になったんだけど、その話は長くなるので、ここできる。

P.S
【参考】

マイナンバーにおける帳票変更のための参考サイト

●国税庁関係
社会保障・税番号制度＜マイナンバー＞
http://www.nta.go.jp/mynumberinfo/index.htm

●厚生労働省関係
事業主の皆さまへ
http://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000063273.html