お行儀のよいDB設計とか

「よくあるよくある」というか、なんとなくどっかで見かけたような「お行儀のよいDB設計」というのがあって、それについてのメモ。
ちなみに想定しているのはmysql。

会員の名前や住所、職業、電話番号もフィールドの長さを個別設定

varchar(100)とかちゃんと適切な長さを設定してたり。
お行儀がいいと言えばいいのだけど、
そういった長さで悩む時間が勿体ないので、僕はtext型にしてしまうことが多い。
別に検索対象となるわけでなし、リアルタイムでサマリをかけることも殆どないし。
レコード数が膨大になればこれは真面目にやらんといかんのかな。
ってか、個人的な業務の範囲内だと、
一昔前のサーバークライアントシステムっぽいのならともかく、レコード数の数がサーバ容量を逼迫する状況って、アクセスレコードぐらいしかないかも。

主キーとは別に外部キーとなるコードがある

シーケンシャルなIDはあるのだけど、それとは別のコード体系があるとか。
そもそもこのDBとは別のところによりマスタなDBが存在して、そことの整合性を保つ為にあるんだろうな、と想像することにする。
・・・それも考えにくいか。
論理削除を採用した場合、シーケンシャルなIDをそのまま採用できない、とか？
でも自分自身、論理削除ってあまり使わないので、これは憶測。

主キーの名称が「テーブル名 + ID」になっている

たまに見かける。
RailsとかCakePHPとか昨今のフレームワークだと標準で「ID」決め打ちだったような。

僕自身は「アプリケーション側にリスクをもたせる」発想みたいなので、DBに対する考え方はなんかゴワゴワに。
でも怒られそうだな。

ただ「お行儀のよいDB設計」って本当によく見かけるというか、
どっかのベンダーが当初作った物を皆が参考にしてしまった（或いは仕様として渡されたから）こういう似たような形式になっているとか。
UTとかPTとかテストフェーズの呼称は系列ごとに方言化している、という話を聞いたことあるんだけど、それに似たような状況なのかな。

「お行儀がよい」というのは「品質が高い」ということかもしれんが、
それはそれだけでコストに跳ね返ってくるもの。
設計段階で過剰品質を発生させてしまうと、コーディング時には数倍〜数十倍の余計な手間隙を生んでしまうものだし、
だから設計を行う人が凝り始めるとそれはそれでよくないかな、と。

まぁでもテーブル設計のシートに「データ型」「データ長」ってカラムがあったら、
どちらも適切な値を埋めたくなるよね。