合法的にはどう持てば、削除しても大丈夫なのか？」
と聞かれたので、こんな風に答えました。
■マイナンバーは原則別テーブル、他テーブルでは主キーにできない
マイナンバーは、目的外には使えません。
ということは、従業員マスターの主キーなどにしてしまうと（一意で便利なんだけど・・・）
従業員マスターを税務・年金以外の他の目的（人事評価や飲み会の参加者名簿など）に使うことが出来ません。
ということは、マイナンバーは原則別テーブルで持ち、必要時に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
