以前にお話したプログラミングの話の中で「シンプル　イズ　ザ　ベスト」と言ったことを述べましたが、
器の話を「データを格納する何か」にまで広げると同じ話です。
つまり、「単一の目的の器を、必要最小限の数だけ、必要最短期間だけ保持する。」
ということを意識しなければなりません。

システム内部設計のレベルで加えて意識しないといけないのは、
器といっても階層があるということぐらいです。
つまり汎用的なリレーショナルデータベースであれば、
カラムのレベルでの器があり、
テーブルのレベルでの器があり、
データベースのレベルでの器があというようなことです。
どのレベルでも同じことを意識しなければなりません。
（まあこれはＤＢの正規化と同じ話ですが。）

良くカラムのレベルでは意識されるのですが、
テーブルのレベルでは意識が薄いことが多いように思います。
コツはプログラミングの場合と同じなのですが「口に出して一言で言えるかどうか」をチェックすることです。

「口に出して一言で言えるかどうか」をチェックする際、
その中に２つ以上のものが入っていたり、
一言で言えたとしても他にも同じものが存在してたりしたら
（当然ながら）ダメです。

まあ言えたとしても、つまるところ、
それは自分の頭の中を整理しただけかもしれません。
しかし、そのこと自体が大事で、
「問題領域のデータをどう捉えるか」自体がポイントなんだと思います。

器の次に意識すべきは手続きですが、
こちらも器の話と同じで階層が深いことを意識する以外ではプログラミングと同様です。
こちらも「口に出して一言で言えるかどうか」をチェックすることは有効だと思います。