テーブル設計について

DBの話。
かなり昔、テーブル設計を出したときに先輩に、テーブル名が短くて列名が長いんですね、って言われてしまった。
具体的な例を挙げると、私が、Author(AuthorId,AuthorName,...)と作ったらところ、TechnicalAuthor(Id,Name)にするような感じで指摘受けたような感じ。

「そんな構造体みたいな考え方はだめに決まっているじゃん」と思ったけど、議論しても疲れそうなので、そのときは、「そうですね。でもつくっちゃったからこれでいきましょう」といっちゃいました。


構造体と違って、テーブルは、複数のテーブルを連結して利用することをするので、同じ意味のものは同じ列名にして、違う意味のものは違う列名にしなきゃいけないと思っています。
そこで、列名がId。これってBook.IdとAuthor.Idをリンクしてしまうと大変なことになってしまうし、SQLにおける自然結合は、列名の一致が前提条件になっています。この点から問題だと思うのですが。
（自然結合を実装したDBMSを見たことはありませんが、書き方は、「Table1 natural join Table2 on AuthorId」）
また、連結した時点でテーブル名の別名をつけることはよくある話で、テーブル名が分らなくなるとデータの意味が分らないのであれば、あんまりよくないテーブル設計と思うんだけど。
最後に、テーブルを連結して取得した値の列名(Name)に意味ある名前にするために、別名を使うより最初から意味ある名前にしておけばいい話だと思う。


最近も、外部キーは避けたいなんていっている人が居る。外部キー制約が気になるときには外部キー制約を無効にして、終わったら外部キー制約を有効にしたほうが、ずっと便利なのに。（たとえ投入データに制約違反がでて制約の有効化に時間がかかっても不整合データが居残るよりよっぽどまし。）
ま、なかなか思うようにはならないですね。