アプリケーションで登場する項目名は種種多々でばらばらのように見えても公約数はあるものです。
特定の人(法人含む)を扱う時は名称/住所/連絡先(ここでは単純におのおの1つのみ持つことにします)が必然項目になります。
一般的な商流アプリとしては仕入先/外注先/得意先が存在します。
ある汎用機開発の項目命名標準に
・名称はユニークな名称をつけて混乱を避けるべし
というのがあり、それに従ったシステムが結構あったりします。
【得意先TABLE】 得意先コード、得意先名称、得意先住所、得意先連絡先
【外注先TABLE】 外注先コード、外注先名称、外注先住所、外注先連絡先
【得意先TABLE】 得意先コード、得意先名称、得意先住所、得意先連絡先
など...となっています。これが私には扱い難いのです。
【連絡先クラス】コード、名称、住所、連絡先
のインスタンスで包括処理したいのに DBの定義が個々違う項目名だと、項目の数だけコードを書かないといけない。
「コードを書くとバグが増える」というスタンスから見ても好ましくありません。
【得意先TABLE】 コード、名称、住所、連絡先
【外注先TABLE】 コード、名称、住所、連絡先
【得意先TABLE】 コード、名称、住所、連絡先
と定義してくれていたら、インスタンス生成のコードもシンプルにできます。
他のテーブルでも別の切り口で抽象名称(汎用名称?)を考えたらシンプルになると思います
預かり消費税,仮払い消費税...一方にしか登場しないので..Table上は消費税でOK
口座1種類、口座1番号、口座1名義、口座2種類、口座2番号、口座2名義、...これは口座でくくって正規化すべきと....ここでの例にはならないか...www.
実装時にコードの記述やインスタンス生成の継承関係も考えてDB設計すればモットスムーズに開発が進むと思うのです。
ところがばってん、旧思想の設計者には馴染めないそうです。
異なるテーブルに同じ名称の項目が登場するのが許せないそうです。
解らなくはないのですが、確かにコードはテーブル毎にサイズが異なるので長さ属性文字属性が異なるので除外したほうがいいかも知れません
しかし、名称、住所、連絡先の項目は 属性は統一できるはずです。同一属性ならば異なるテーブルに登場してもいい筈でしょう。
事実、更新日付、更新者、更新ProgramIDの項目はどのテーブルにも登場しているだから。
(追記)非IT関係者に見せる書類はユニーク名称のほうが良いとおもうので使い分けはいりますね。