テーブル設計その３？

http://remindbook.blogspot.com/2009/10/blog-post_3083.html
で、コメントをいただいたので、もうちょっとだけ考えてみました。

とその前に、最初に言い訳。
昔、以下の記事で、テーブル設計をした際、
http://remindbook.blogspot.com/2008/06/blog-post.html
やっちゃ駄目といったIdや、Nameなど、バリバリに使っていますが、あれはすごく小さなデータベースなので、本当にあれで業務アプリを作ってはいけないと思ってます。
あんなのは説明するために作ったテーブルに過ぎません。まあ何とか外部キー定義しているので、クエリビルダ(Accessや SQL Server ManagementStudioのView作成や、Visual Studio のテーブルアダプタ作成などで出てくるもの)にProjectとTaskをおいたときにそれぞれIdで自動で連結されるということは無いのですが、外部キーが張ってなかったら、テーブルをおいた直後にId列同士でJoinされます。

で、本題。１人で作る業務データベースなら、列名はPersonIdなど一般的なものではなく、業務で意味ある名前AuthorIdとするべきだと思います。
列がカードだと思うと、カードを束ねるクリップのようなものがテーブル名で、クリップを外してバラバラにした後に、別のクリップでカードを束ねたときにも、なんとなく分るような列名にしたほうがいいんじゃないかな？と思っています。
列名を一般名にして、テーブル結合の際に列名変更を強制するというSQL作成ルールを作っても、きっと誰も守ってくれないと思うので、そんなルールは作るべきではないと思うし。。

まぁ、業務なんてどんどん変わっていくものなので、時には列名が決めにくいということはあるとは思いますが、データは、処理ほど頻繁に変わるわけではないし、ある程度変更を許容できるように設計するはずなのでなんとなくうまくいくんじゃないかなあ？


ただ、テーブル設計をする人が複数人になった場合は、列名など些細なことにこだわってられません。(テーブル数が数百～数千となり、列数が一万を超えたりしますから。)
そうなった場合は、各テーブルの管理はそれぞれのチームが管理することとして、DB共通ルールは、ドメインとキーのみ見ることになると思います。ドメインでは、ユーザー名は○桁の文字列/性別は1が男,2が女のtinyintなど/のルールに従った設計になっているかというドメインチェックと、主キーと外部キーが正しいか？という寒天だけになると思います。
ただ、ドメイン設計をしても、ユーザ定義型(create type)は絶対に作るべきではないと思ってます。そんなに人は賢くないので、ユーザ定義型を導入すると、ユーザ定義型を使っている部分/使っていない部分が混在するか、同じようなユーザ定義型ができるに決まってるから。
同じ意味でスキーマ名をつけることはないんじゃないかなと思います。今まで携わったプロジェクトでは、すべて、すべてdbo.テーブル名にしちゃってました。