最近関わっているシステムのDB設計があまりにもレガシー過ぎて困っている今日この頃、みなさんいかがお過ごしでしょうか。
世の中のトレンドがちょっと知りたくなったので、コメントを残してくれるとありがたいです。コメントをいただけたら、下の表にまとめようと思います。(敬称略)
追記)独断と偏見でまとめているので、勘違いとかあったらごめんなさい。直しますんで。
カラム名 |
短縮する派 |
短縮しない派 |
大文字 区切りなし派 |
Chuki |
|
小文字 区切りなし派 |
|
|
大文字アンダースコア 区切り派 |
シャノン |
|
小文字アンダースコア 区切り派 |
|
かつのり、Ognac、けろ、tgk |
キャメルケース派 |
片桐 |
かつのり、けろ、むら |
日本語派 |
|
、はつね、Ognac、凪瀬、、えムナウ、けろ、NAL-6295、ひろえむ |
テーブル名 |
短縮する派 |
短縮しない派 |
大文字 区切りなし派 |
Chuki |
|
小文字 区切りなし派 |
|
|
大文字アンダースコア 区切り派 |
シャノン |
|
小文字アンダースコア 区切り派 |
|
かつのり、tgk |
キャメルケース派 |
片桐 |
かつのり、けろ、むら |
日本語派 |
|
、はつね、凪瀬、、えムナウ、けろ、NAL-6295、ひろえむ |
主キー |
業務上必要なだけ |
片桐、はつね、えムナウ、シャノン、NAL-6295、ひろえむ |
2~3までなら許せるけど、 それ以上ならサロゲートキーを採用する派 |
片桐、Ognac、 |
何が何でもサロゲートキー派(関連テーブルの主キーの有無は問わず) |
かつのり、Ognac、、Chuki、むら、tgk |
その他 |
、、けろ |
ちなみに、自分の場合は主キーに関しては何が何でもサロゲートキー派。関連テーブルにもサロゲートキーをつけます。論理的な一意性はユニーク制約にて示し、物理的な一意性を主キーによって示します。したがって、業務上の主キーは物理的な主キーにはしません。これには強いこだわりがあって、
- 業務は常に変化し続けるものである
- 現在の業務上の主キーが将来的に主キーではない
という考えからです。現在の業務ルールでは伝票番号が主キーであっても、他社との統合によって伝票番号が主キーにならなくなるケースも考えられるのです。属性の変更に比べてIDの変更はかなりなインパクトがあります。そこで安全性や拡張性を考えて、必ずサロゲートキーを採用するようにしています。
カラム名やテーブル名は大文字小文字の区別のサポートによって変わりますが、PostgreSQLのように大文字小文字を区別しないものでは小文字のアンダースコア区切りですが、基本的にはJavaのクラス名、プロパティ名と同じになるようにキャメルケースを採用する事が多いです。
これは単純にフレームワークのサポートが受けられやすいというところが大きいですが、プログラム上の識別子とカラム名が同じだとSQLが組みやすいっていうのもあります。